Introduction

When you run WordPress in Docker, volume mounts are what keep your site data and uploaded files from disappearing when containers are recreated. The usual design is to persist the WordPress application files separately from the database data, and to be deliberate about whether you want a Docker-managed named volume or a bind mount to a host directory you can inspect directly.

Basic Compose Setup

A common docker-compose.yml layout looks like this:

1services:
2  db:
3    image: mysql:8.0
4    environment:
5      MYSQL_DATABASE: wordpress
6      MYSQL_USER: wordpress
7      MYSQL_PASSWORD: wordpress
8      MYSQL_ROOT_PASSWORD: rootpass
9    volumes:
10      - db_data:/var/lib/mysql
11
12  wordpress:
13    image: wordpress:latest
14    ports:
15      - "8080:80"
16    environment:
17      WORDPRESS_DB_HOST: db:3306
18      WORDPRESS_DB_NAME: wordpress
19      WORDPRESS_DB_USER: wordpress
20      WORDPRESS_DB_PASSWORD: wordpress
21    depends_on:
22      - db
23    volumes:
24      - wordpress_data:/var/www/html
25
26volumes:
27  db_data:
28  wordpress_data:

This gives WordPress and MySQL their own persistent storage locations.

What the WordPress Mount Actually Stores

The WordPress container's important path is usually:

/var/www/html

That directory contains:

• WordPress core files
• plugins
• themes
• uploads
• generated configuration such as wp-config.php in many setups

Mounting that path means container recreation will not wipe those files.

Named Volume Versus Bind Mount

Named volume example:

volumes:
  - wordpress_data:/var/www/html

Bind mount example:

volumes:
  - ./wordpress:/var/www/html

Choose based on your goal:

• named volume is simpler for persistence
• bind mount is convenient if you want to inspect or edit files from the host directly

For development themes or plugins, bind mounts are often useful. For simple local persistence, named volumes are usually easier.

Be Careful About Masking Container Files

One subtle issue with bind mounts is that they replace the container path view with the host path. If your host directory starts empty and you mount it over /var/www/html, you can mask the files that the image expected to provide there.

That is why a naive bind mount sometimes makes the container look broken on first startup.

Named volumes usually behave more smoothly for the initial WordPress bootstrap because Docker manages the target storage lifecycle more predictably.

Database Volume Is Not Optional

People often focus on the WordPress files and forget the database. But the MySQL volume is what keeps:

• posts
• pages
• users
• settings
• plugin data stored in MySQL

If you persist /var/www/html but not /var/lib/mysql, the site will still lose its real content when the database container is recreated.

Common Pitfalls

The most common mistake is mounting only the WordPress container and forgetting the database volume. WordPress depends on both filesystem state and database state.

Another issue is using an empty host bind mount over /var/www/html and unintentionally hiding the container's preloaded files. This often looks like a broken image, but it is really a mount-overlay problem.

A third pitfall is mixing production persistence and development convenience without deciding which matters more. Bind mounts are convenient for local editing, while named volumes are often cleaner for ordinary persistence.

Finally, do not assume recreating containers is harmless unless the volumes are correct. Docker makes containers easy to replace, but that only helps if the right directories are persisted outside the container lifecycle.

Summary

• WordPress in Docker needs persistent storage for both WordPress files and the database.
• '/var/www/html is the usual WordPress filesystem mount point.'
• '/var/lib/mysql is the usual MySQL persistence path.'
• Named volumes are simpler for persistence, while bind mounts are useful for direct host-side editing.
• Be careful not to hide the image's expected files with an empty bind mount.