Does it Make Sense to Run WordPress in Docker?

I've had my ups and downs with WordPress, I'm not a hardcore fan to be honest, but you can't deny it's popularity.

You can use Docker to spin up an instance of WordPress on your local computer and in the cloud. But does it make sense to use WordPress in Docker?

When it doesn't make sense to run Wordpress in Docker

For non technical users, running Docker locally is usually too much overhead. It comes with a learning curve and there are other tools that make getting started much easier:

• Local development tools like XAMPP, MAMP, or Local
• Managed hosting - ditch the local setup and go straight to a managed WordPress platform like WordPress.com, WP Engine, or Kinsta
• Traditional shared hosting: still the cheapest option for basic WordPress sites

You can still use Docker of course, there is nothing inherently wrong with a WordPress in Docker setup. In fact, there are some good reasons to...

When it makes sense to run WordPress in Docker

If you are a developer on the other hand and maybe even work in a team with frequent WordPress deployments, running WordPress in Docker makes a lot of sense. It is really useful to mirror the production environment on your own machine for development and easily share it with the team so all developers have consistent environments, especially if you work on multiple sites with different PHP versions, databases, or OS plugins.

In combination with Sliplane, you can easily deploy your containerized apps and share progress internally and with clients, integrate the deployment into a QA pipeline or run it in production.

I know a lot of developers who don't want to deal with Docker at all and I used to be that guy as well. In the beginning it can feel like a lot of painful overhead to get the setup going. However, there will be a turning point, after you got your head wrapped around some basic Docker concepts and at that point you don't want to go back!

Can you run WordPress in Docker in production?

Absolutely. Running WordPress in Docker is possible in a production setting as well.

If you are familiar with Docker, it's fairly easy to spin up small to medium sized WordPress-in-Docker setups, the harder thing is keeping it secure and performing consistent maintenance. If you don't want to deal with that it's probably a good idea to go with a managed Docker hosting solution.

Some benefits of running WordPress in Docker:

• very flexible, you can add and install anything
• affordable: you get big compute for little money
• portable, you can easily move to a different host
• it's widely adopted

Running WordPress in Docker can get challenging, once you reach a certain size with tens of thousands of pages, millions of monthly active users and hundreds of Gigabytes of file storage. But even then, with a few tweaks the setup can scale very large. Here are some things to think about, although I usually recommend to only add these components, once you really need them (and you can feel that: slow site, storage full, crashes, ...)

• Persistent storage, it's okay to store themes on your server, however when it comes to media, you're better of with choosing an object storage provider. There are plugins like Media Cloud that make the switch very easy.
• Caching, at a certain scale it makes sense to add caching to speed up requests, for example use Redis via the Redis Cache plugin
• Separate Database: move the database to a separate machine. It makes sense to keep the database in the same network though and use private connections if possible.
• Load Balancing: If vertical scaling does not do the trick any more, you can add a load balancer in front of your WordPress instance and spread the load to multiple instances. This requires your WordPress containers to be stateless though

How to Run WordPress in Docker

We need to setup two containers:

1. Database container (MySQL/MariaDB) - stores your WordPress content, users, settings, etc.
2. WordPress container - runs the PHP application and serves your website

Using Docker CLI

Let's start by creating a network, so the containers can communicate with each other:

# Create a network
docker network create wordpress-network

Next, spin up the database container, we'll use MySQL:

# Run MySQL
docker run -d \
  --name wordpress-db \
  --network wordpress-network \
  -e MYSQL_DATABASE=wordpress \
  -e MYSQL_USER=wp_user \
  -e MYSQL_PASSWORD=wp_pass \
  -e MYSQL_ROOT_PASSWORD=root_password \
  -v mysql_data:/var/lib/mysql \
  mysql:9.4

Breaking down this command:

• docker run -d - Runs the container in detached mode (in the background)
• --name wordpress-db - Gives the container a friendly name we can reference
• --network wordpress-network - Connects the container to our custom network
• -e MYSQL_DATABASE=wordpress - Creates a database called "wordpress"
• -e MYSQL_USER=wp_user - Creates a MySQL user for WordPress to use
• -e MYSQL_PASSWORD=wp_pass - Sets the password for that user
• -e MYSQL_ROOT_PASSWORD=root_password - Sets the MySQL root password
• -v mysql_data:/var/lib/mysql - Creates a persistent volume to store database data
• mysql:9.4 - Uses the official MySQL 9.4 Docker image

Now that our database is running, we can deploy the WordPress container:

# Run WordPress
docker run -d \
  --name wordpress-site \
  --network wordpress-network \
  -p 8080:80 \
  -e WORDPRESS_DB_HOST=wordpress-db:3306 \
  -e WORDPRESS_DB_NAME=wordpress \
  -e WORDPRESS_DB_USER=wp_user \
  -e WORDPRESS_DB_PASSWORD=wp_pass \
  -v wordpress_data:/var/www/html \
  wordpress:latest

Breaking down this command:

• docker run -d - Runs in detached mode
• --name wordpress-site - Names the container for easy reference
• --network wordpress-network - Connects to the same network as our database
• -p 8080:80 - Maps port 8080 on your computer to port 80 in the container
• -e WORDPRESS_DB_HOST=wordpress-db:3306 - Tells WordPress where to find the database (using the container name)
• -e WORDPRESS_DB_NAME=wordpress - Specifies which database to use
• -e WORDPRESS_DB_USER=wp_user - Database username (must match what we set in MySQL)
• -e WORDPRESS_DB_PASSWORD=wp_pass - Database password (must match what we set in MySQL)
• -v wordpress_data:/var/www/html - Persists WordPress files and uploads
• wordpress:latest - Uses the official WordPress Docker image

Your WordPress site will be available at http://localhost:8080.

Using Docker Compose

You can also use Docker Compose to simplify the process:

Create a docker-compose.yml file:

services:
  wordpress:
    image: wordpress:latest
    ports:
      - "8080:80"
    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_NAME: wordpress
      WORDPRESS_DB_USER: wp_user
      WORDPRESS_DB_PASSWORD: wp_pass
    volumes:
      - wordpress_data:/var/www/html
    depends_on:
      - db

  db:
    image: mysql:9.4
    environment:
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wp_user
      MYSQL_PASSWORD: wp_pass
      MYSQL_ROOT_PASSWORD: root_password
    volumes:
      - db_data:/var/lib/mysql

volumes:
  wordpress_data:
  db_data:

Then run:

docker-compose up -d

Deploy WordPress in Docker

There are a few providers that you can deploy your containers to. If you are looking for a solution with minimum overhead, I recommend Sliplane.

Step 1: Create a New Project

1. Visit Sliplane and sign in with your GitHub account.
2. Click "Create Project" and give your project a name (e.g., WordPress). This project will serve as the container environment where you’ll deploy two services: one for MySQL and one for WordPress.

Step 2: Deploy a MySQL Service

1. Inside the project dashboard, click "Deploy Service."
2. Create a new server to host your MySQL service. You can select the location and server type, the base server should be strong enough to get started.
3. Choose the "MySQL" preset from the available services. This preset uses the bitnami/mysql image under the hood and comes with sensible default configurations. You can also use other database containers like MariaDB, which work similarly with WordPress.
4. Review Configuration: The MySQL preset comes preconfigured and can be deployed as is, but you can customize it further if needed. I recommend turning off public access to the database for security reasons.
5. Click "Deploy Service" and wait a few seconds for the deploy to finish.

Step 3: Deploy a WordPress Service

After your MySQL service is successfully deployed and running, the next step is to deploy the WordPress CMS container. This container will connect to your MySQL database to store and retrieve data.

1. Inside your "WordPress" project, click "Deploy Service" again.
2. Select the server that your MySQL service is running on.
3. Select "Registry" as the deploy source
4. In the "Image URL" field, type "wordpress" and choose the official WordPress image from the dropdown. We go with latest version, but you can choose a specific tag if wantet.
5. In the Environment Variables section, configure the following:

   WORDPRESS_DB_HOST=internal-mysql-hostname
   WORDPRESS_DB_NAME=wordpress
   WORDPRESS_DB_USER=wp_user
   WORDPRESS_DB_PASSWORD=wp_pass

Important: Make sure these values match exactly with what you configured in your MySQL service. The WORDPRESS_DB_HOST should use the internal host name of your MySQL container.

6. Add a new volume with a name of your choice and set the mount path to "/var/www/html". This is where your WordPress files and uploads will be stored.
7. Finally, give the service a name and hit "Deploy Service".

After the deploy is finished, you can access your WordPress site at the URL that has been assigned and continue with the installation.

Summary

For non-technical users, traditional hosting is easier, however, for developers who want to maintain consistent environments and work as close to production as possible, using WordPress in Docker is a great choice.

You can also run WordPress-Docker setups in production, but it requires some technical knowledge and if you don't want to deal with deal with the overhead, a managed solution like Sliplane is the way to go.

Comments

[Ingo Steinke, web developer]

It makes sense, especially for development, when you have several different customer setups. What doesn't make sense is copy-and-pasting outdated code into a current post. Just why? If you'd taken two minutes to read the manual or open your code in any IDE, you'd know what's wrong with version: '3.8' and docker-compose.

But that's how clickbait posts (don't) work.

[Jonas Scholz]

Calling something clickbait because it uses backwards compatible (!) things is slightly insane, but ok. We still see people use outdated docker compose versions everyday, would you prefer if they had a broken tutorial?

[Ingo Steinke, web developer]

Backward compatibility is one thing. Okay, docker compose (v2) was released in 2020, docker-compose (v1) stopped being maintained in 2023, but v2 offers an optional hyphen syntax, so you have a point here.

Docker wasn't the reason for me to point out clickbait, but linking Sliplane in every other post was.

[david duymelinck]

I'm sure Lukas and Jonas can defend themselves, but as an outside voice I think their promotion is tasteful.

They provide posts with information that is useful. That is why I read their posts and react.
I know there will be a shameless plug for their product, but I think they do it in way it feels more like a gentle push than a slap in the face.

[Jonas Scholz]

Appreciate it :D If you ever think its a slap in the face pls let us know! I also really appreciate Ingos feedback here:)

[Ingo Steinke, web developer]

You all are right! I already thought about deleting my critical comment, but then again, it's good to discuss what is decent marketing combined with providing value and what isn't. Lukas' post surely is a legitimate post that adds more value to DEV than many other posts do these days.

[Lukas Mauser]

Good catch 🤝

[Jonas Scholz]

I usually ask the "does it make sense" question after spending 20 hours trying to dockerize something 😎

[Lukas Mauser]

That's the natural way to do it :-D

[david duymelinck]

As a PHP developer I refuse to touch Wordpress. The architecture still has solid roots in their blog beginnings. The PHP code only is made compatible with new versions, no new code practices are being adopted. The guidelines are just outdated.

If you want to run an easy PHP CMS use Craft CMS or Statamic. If you want more modularity use Drupal or Sulu.

[Lukas Mauser]

I accepted a few WordPress jobs when I was young and innocent that still haunt me to this day :D

As CMS I liked working with Directus.

[david duymelinck]

I think at this point ninety procent of all the CMS solutions are better than Wordpress. But their marketing is still strong.

I cringe when I see people build e-commerce, woocommerce.com/, solutions with Wordpress as the base framework.

[Ingo Steinke, web developer]

You'll love WordPress after trying to use Webflow! And after using both, you'll never hold a grudge against React or any other framework that at least lets us write code than can be linted, versioned, and run in development and staging environments.

[Anik Sikder]

I’ve had similar experiences Docker felt overwhelming at first, but once I understood the networking and volume parts, I realized how powerful and repeatable it makes WP setups. Totally agree: for local dev or team-based environments, Dockerized WordPress is a game changer. Still, for clients who just want something that works, managed hosting wins every time. Appreciate the balanced view here!

[Dag-Roger]

For local development of PHP check out DDEV