Absolutely—this is a critical, easy-to-overstep step that’s essential for keeping your WordPress site’s content safe through container restarts, updates, or recreates.

Why this volume is non-negotiable #

While your posts and core site settings live in the MySQL database (which you’re already persisting with db_data), all user-generated and custom content is stored directly in the WordPress container by default:

• Uploaded images, videos, and media files (housed in wp-content/uploads)
• Custom themes, plugins, and child themes (stored in wp-content/themes and wp-content/plugins)
• Modified configuration files like wp-config.php
• Any custom code snippets or third-party assets you add to your site

Skip this volume, and all of this content will be wiped clean the second your WordPress container stops, gets deleted, or is updated to a new image.

Which path to target #

The entire WordPress site root in the container lives at /var/www/html—this single directory covers everything you need to persist. Mounting this path to a volume ensures all your site’s editable content stays intact across container changes.

Updated docker-compose.yml example #

Here’s how to adjust the official quickstart file to add the WordPress volume:

version: '3.8'

services:
  db:
    image: mysql:8.0
    volumes:
      - db_data:/var/lib/mysql
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: somewordpress
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wordpress
      MYSQL_PASSWORD: wordpress

  wordpress:
    depends_on:
      - db
    image: wordpress:latest
    volumes:
      # Add this line to persist WordPress content
      - wordpress_data:/var/www/html
    ports:
      - "8000:80"
    restart: always
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: wordpress
      WORDPRESS_DB_PASSWORD: wordpress
      WORDPRESS_DB_NAME: wordpress

volumes:
  db_data:
  # Add this volume definition for WordPress
  wordpress_data:

Quick notes #

• Using a Docker volume (like wordpress_data here) is preferred over a local bind mount because Docker automatically handles file permissions for the container’s www-data user, avoiding common permission headaches.
• If you want direct access to your site files on your host machine, you can replace - wordpress_data:/var/www/html with - ./wordpress-local-content:/var/www/html—just make sure to set correct permissions first (e.g., sudo chown -R www-data:www-data ./wordpress-local-content on Linux systems).

内容的提问来源于stack exchange，提问作者tgogos