How to Manually Build Docker Containers for WordPress

In my previous article, we covered what Docker is and how to get up and running with a few commands. However, we haven’t done anything useful just yet. There are numerous ways to get a WordPress environment using Docker, in this article, I’ll show you how to manually setup Docker containers to work with WordPress. If you’d like a quick intro into Docker, you can jump back to the first article here.

Setting up MySQL

Every WordPress installation needs a MySQL database. To do this, we head over to Docker Hub and find a MySQL image.

The Docker team already has a MySQL image ready for us to use. Before running any commands on the terminal, make sure to read the documentation for this image. The latest version at the time of writing is 5.7. However, the latest tag name is 5.6. The latest version of an image can be for any previous version, but one in its stable state.

Docker Image

The basic command to setup a container using this image is:

docker run --name wordpressdb -d mysql:5.7

MySQL docker image

If you don’t already have a copy of the image locally, Docker will pull that for you from the Docker Hub. We know so far that --name gives our container a name, -d makes sure that our container runs in the background.

If you run docker ps you will see that wordpressdb container is not running. It should be running though. Run docker logs wordpressdb and you will see a message like this:

error: database is uninitialized and MYSQL_ROOT_PASSWORD not set
  Did you forget to add -e MYSQL_ROOT_PASSWORD=... ?

Why is that? It’s because we didn’t pass a root password as an argument when we first built the container. So let’s do just that. First, we need to delete the container that we created with the name wordpressdb using docker rm wordpressdb. This is because the new container will use the same name and there can’t be two containers with the same name.

So let’s create our container again. We need to pass an environmental variable when we first create the container. It should look something like this:

docker run --name wordpressdb -e MYSQL_ROOT_PASSWORD=password -d mysql:5.7

-e MYSQL_ROOT_PASSWORD=password is an environmental variable. When the container is being built from the image, it reads this variable and sets the password for the root user to the specified value, which in this case is password.

If you now check docker logs wordpressdb, you’ll see a very long message, but don’t worry about this, it’s working. Again, run docker ps and you’ll see a container with the name wordpressdb that is active and running.

You can also pass other environmental variables to your container, you can find a complete list on the MySQL image documentation. Here’s another example:

docker run --name wordpressdb -e MYSQL_ROOT_PASSWORD=password -e MYSQL_DATABASE=wordpress -d mysql:5.7

If you tried to remove the previous container with the name wordpressdb, it probably failed. That’s because the container was still running in the background. You could first stop the running container and then remove it or just force remove it:

docker rm -f wordpressdb

If we use MYSQL_DATABASE, it makes sure that a database with that name is created. This way, we know for sure what the name of the database and roots password is. You can also create another user with a password and database. Here’s a quick test for you, look at their docs and try to do this yourself.

If you’d like to know more how this container is built, look at the Dockerfile. It uses debian wheezy and builds the container using bash commands. It pulls it from the repository and then starts mysqld. When building your container from this image, the first time it will execute the commands of the build file. When using the container, it will only exec mysqld.

Docker - MySQL buildfile

Now that we have a running MySQL container, we can run a container that runs WordPress.

Building a WordPress Container

For this container we’ll use the PHP image. There are three types of PHP images, we only need the PHP image that comes with Apache.

docker run --name wordpress php:5.6-apache

Without -d option, it wont run in background, instead it will show you everything the container is outputting (the same way that docker logs [container_name] does).

From the output you can see that it has automatically assigned an IP to that container. In my case it’s If you visit this address using your browser, you’ll get a forbidden error. Why is that? It’s because there is nothing in the /var/www/html folder (on the containers filesystem), it’s empty.

So how we can put files in that folder? By default, that folder stays inside the container, and it’s invisible. However, not for long (don’t forget to docker rm wordpress). First, create a folder and navigate inside it (don’t forget to remove the old wordpress container).

docker run --name wordpress -v "$PWD/":/var/www/html php:5.6-apache

-v is used for mapping two folders. The first part is the folder on your OS and the second is the folder in the containers filesystem. On Unix-like systems, the "$PWD" returns the location where the terminal is when the command runs. When you first start a terminal, you’ll be in your home directory. The equivalent on Windows is cd.More about PWD can be found here.

So in our example, the first part is “$PWD/”, which is the local directory and the second part is /var/www/html/. -v requires both to be full paths. However, if we look in our working directory, we can see that no files exist there. Create a file called index.php that contains the following:




Check this again in your browser. This time you’ll notice that the IP address has changed because we created a new container. Every time we create a new container, it changes its IP. If you see that message in your browser then you have done everything right.

Let’s see what it happens if we put the WordPress files there. Stop the container by using docker stop wordpress. Grab the latest copy of WordPress from and drop the files inside the project folder. Start the container again using docker start wordpress. Also, make note that you’ll initially need to make the files readable. You can run chmod -R 777 projectfolder on *nix systems. If you reload the page, your browser will tell you that:

Your PHP installation appears to be missing the MySQL extension which is required by WordPress.

By default, the PHP image doesn’t have the MySQL extension installed, but we can fix that. This time we’ll build a container via a Dockerfile. We’ve already seen how Dockerfiles work. They are built from a base image, do some processing, then execute one command in the end.

Create a new file named Dockerfile:

We want to use the php:5.6-apache image.

FROM php:5.6-apache

Then we’ll install the mysqli extension.

RUN docker-php-ext-install mysqli

Next, we need to execute apache2-foreground as the PHP image does (we only needed to install the MySQL extension after all).

CMD ["apache2-foreground"]

Using build files we can build images. Using this image, we build the container.

docker build -t phpwithmysql .

The -t is used to give a repository name. The . tells to Docker where the Dockerfile is located. As the Dockerfile is located in the working directory, . tells docker that it is in the working directory.

If you check the images with docker images, you’ll now see a new image with tag latest (because we didn’t specify a tag for this image). Now build container this container with this image like we did with php5.6-apache image.

docker run --name wordpress -v "$PWD/":/var/www/html phpwithmysql

Check your browser for the containers IP and you will see something like this:

Welcome WordPress Screen

If you got this far, then you have done everything right. Now we have to link WordPress with a database. This is far from the famous 5 minutes install of WordPress and more complex, but you will get to see the benefits of Docker in the long run.

So how do we link WordPress with the database? First we need to link the wordpress container with a database container (wordpressdb). This can be done via linking two containers. More on linking can be found here.

docker run --name wordpress --link wordpressdb:mysql -v "$PWD/":/var/www/html phpwithmysql

The new arguments is --link. The first part wordpressdb is the name of the container that we want to link, and the second part mysql is the alias. Docker modifies the host of the wordpress container and sets the IP of the wordpressdb to mysql. So when we fill the information for the database on WordPress configuration, we will set the host to ‘mysql’.

Now go to your browser using IP of the container (the new IP). Fill the information for the database and login to the administrator panel. If you try to install a new theme (which will try to make changes on filesystem), you will see something like this:

WordPress not writable access on filesystem

Why is that? It is because the user that runs Apache doesn’t have write access on the filesystem. This is where things get a little difficult. We need to build a new version of the phpwithmysql image. Go to your Dockerfile and modify it to look like this:

FROM php:5.6-apache

RUN docker-php-ext-install mysqli


RUN chmod 777 /


CMD ["apache2-foreground"]

We haven’t created file yet, but we will do this shortly. COPY copies to / inside the container. chmod 777 / makes that file executable. And finally ENTRYPOINT executes that file. Now create the file in the same directory as the Dockerfile.


chown -R www-data:www-data .

exec "$@"

This is the simplified workaround of the official WordPress image, but will make sure we have write access to the containers filesystem. We can now build the new image:

docker build -t phpwithmysql:v2 .

Make sure to remove the old containers and create the new containers:

docker rm -f wordpress
docker rm -f wordpressdb

docker run --name wordpressdb -e MYSQL_ROOT_PASSWORD=password -e MYSQL_DATABASE=wordpress -d mysql:5.7

docker run --name wordpress --link wordpressdb:mysql -v "$PWD/":/var/www/html phpwithmysql:v2

Also, remove the old wp-config.php file.

Now check the IP for your wordpress container in your browser. This time you can install themes and plugins, and make changes on the containers filesystem.

Some of the steps above might seem quite cryptic and complex. That’s why there are official images for many different frameworks and languages. Every framework or language has different specifications on how they work. By default, Docker doesn’t allow the application to write on the filesystem. Is this a bad or good thing? I think it’s a good thing. We could create a third container that only holds files. There the application could write files. This way we would have a more modular architecture. But for those frameworks that can’t be changed (like WordPress), there are workarounds.

Final Tweaks

The last thing we have to do is to work around a problem that occurs when you stop the wordpress container, and start it again. The problem is that WordPress saves the last IP as its ‘Home’ and ‘Site’ URL. Stop wordpress container and start it again. This time it will have a new IP. If you try that in your browser, you will see that images, css and javascript files are not included properly. The solution is simple, just modify the wp-config.php by adding this lines:


Note that if you define these values in your wp-config.php file, you can’t change them later on in General Settings.


In this article, we covered how we can build containers for WordPress. We did it in a rather cryptic way, with long commands that can be hard to remember. There should be an easier way, and there is! The Docker team has built a WordPress image that you can easily setup in minutes. After all, who wants to remember every command to setup WordPress?

In the next article in this series, I” show you how use the official WordPress image, and we’ll also learn how to use Docker Compose to make things even easier.

So why did I write this article if there’s an easier way? Essentially, it was to get a better understanding of how Docker works, to do this you have to get your hands dirty with the underlying complexities. It’s more of a personal rule, so when I get to use Docker tomorrow, I’ll know more about how it works and how to tweak it for my needs. I hope you also now have a deeper understanding of how Docker works behind the scenes. Stay tuned for the third article on this series where we’ll have even more fun with Docker and WordPress.

What do you think about Docker so far? Would you consider it on your next project? Let me know in the comments below.


  1. Hi @oddz . Glad to see that you are following these articles. Yes I agree that Docker is a bit complex
    . But in the next article things will get very easy. I did this complex article to show how Docker works underlying. But there are tools (Docker-Compose) that makes things very easy. Also not to mention official images. More on this in the next article. There is also one last article on how to deploy this on DigitalOcean so stay tuned if you haven’t gave up already :smile: .

    If you are using Vagrant than it is a good thing because Vagrant (PuPHPet) are not very used on PHP community. Community is adopting Vagrant but there is more road ahead. Docker is a new cool tool and yet complex. But will be a lot easier when it evolves more.

  2. oddz says:

    I would agree that without vagrant would be just as complex. However, until there is a tool like for docker it just seems like a lot of work that could be eliminated using Establishing a proficient workflow to run ANY site on a local environment is something I have heavy interest in. However, I haven’t found much wrong with the puphpet one. I hear amazon will also be releasing a “container” service so I wonder how that will compare to docker.

  3. oddz says:

    It seems like if you’re afraid of the command line you’re afraid of the command line and that is it. Anyone who is afraid of the command line just reverts back to *amp. Which is all fine and dandy until you need ALL the other things a larger enterprise level ecosystem requires in terms of dependencies and dev tools.

  4. I’m really glad you mentioned the “fear from command line” syndrome (that’s how I call it). I think it is a real syndrome. After all it is on the hands of the developer if he/she wants to use it. There are a lot of things that can be done a lot faster via terminal (CMD) than GUI based tools. Knowing terminal (*nix systems), makes everyone a better developer because that way, you will know better how things work.

    For example, today I was working with a package for PHP that can make testing cookies with PhpUnit a reality and had to install a bunch of PECL packages. And it was a very very messed up job with terminal. I took some hours off because I got stucked on terminal without finding a way out. Will get again back to find a solution. I learned a lot even from failures on terminal. Things that I wouldn’t learn normally.

    A couple of months ago I wrote an article about Vagrant VVV (wordpress configuration) and It got really crazy on the comments. Now 52 comments and growing every month. The disquisition wasn’t for VVV although. It was a huge debate on why using terminal was wrong and good. Take a few minutes and read the comments on this article: . I guaranty that you will enjoy it :smile: .

  5. I have also that problem with WordPress. It is old architecture. I prefer more to code with Laravel because it promotes good code and architecture. A group of developers released also a CMS based on Laravel (October CMS). I saw it a bit today and I found that coding for CMS is a bit pain. Even a CMS backed by Laravel gets really messy. There are developers that like to work with CMS and other that don’t. It’s preference after all.

    But let’s agree that WordPress also does it job very well for most people. The real pain is for developers. As a developer you would want to start a theme from scratch. Dealing with others code (themes) is a pain because everyone does it in different way.

    I also wasn’t surprised a lot with the topic, but some responses really got my attention. Like that one for example. Not just from non terminal guys, but from terminal guys also.

9 more replies