Hi! We're Dan and Jay. We're a two person team with a passion for open source products. We created Server Side Up to help share what we learn.

• 📖 Blog - get the latest guides and free courses on all things web/mobile development.
• 🙋 Community - get friendly help from our community members.
• 🤵‍♂️ Get Professional Help - get guaranteed responses within next business day.
• 💻 GitHub - check out our other open source projects
• 📫 Newsletter - skip the algorithms and get quality content right to your inbox
• 🐥 Twitter - you can also follow Dan and Jay
• ❤️ Sponsor Us - please consider sponsoring us so we can create more helpful resources

All of our software is free an open to the world. None of this can be brought to you without the financial backing of our sponsors.

This is a list of the docker images this repository creates:

⚙️ Variation	🚀 Version
cli
fpm
fpm-apache
fpm-nginx

PHP 8.2 is still considered a "pre-release" by the official PHP team. Learn more here →

Simply use this image name pattern in any of your projects:

serversideup/php:{{version}}-{{variation-name}}

For example... If I wanted to run PHP 8.0 with FPM + NGINX, I would use this image:

serversideup/php:8.0-fpm-nginx

You can see a bigger picture on how these images are used from Development to Production by viewing this video that shows a high level overview how we deploy "ROAST" which is a demo production app for our book.

Click the image below to view the video:

✅ The image builds automatically run weekly (Tuesday at 0800 UTC) for latest security updates.

All images are built off of the official Ubuntu 22.04 docker image. We first build our CLI image, then our FPM, etc. Here is what this looks like:

graph TD;
    A[Ubuntu 22.04 + S6 Overlay] --> C[CLI];
    C[CLI] --> D[FPM];
    D[FPM] --> E[FPM-NIGNX];
    D[FPM] --> F[FPM-APACHE];

We get this question often. Our biggest principle is: your infrastructure should be able to run anywhere.

We believe privacy and control is the #1 priority when it comes to hosting infrastructure. We try to avoid the "big clouds" as much as possible because we're not comfortable that all 3 major players practice data mining of users and their products usually contain some sort of "vendor-lock".

We run all of our production servers on the latest LTS release of Ubuntu Server. The hosts we use are below. Some may be affiliate links that kick a few bucks at no extra cost to you, but they do not affect our recommendations at all.

Our current favorite. Excellent performance and value. Lots of datacenter options too.

Lots of developer love here. Not the best performing servers, but they do have a lot of awesome products!

Great performance and great support. These guys have really enhanced their offering over the last few years.

If you're shopping for a host, check out the benchmarks we've ran →

Sure! It all depends what platform you want to use, but if it supports Docker images, you likely can run it. These images are designed to give you freedom no matter where you want to run them.

We're taking the extra effort to open source as much as we can. Not only could this potentially help someone learn a little bit of Docker, but it makes it a heck of a lot easier for us to work with you on new open source ideas.

Majority of our knowledge came from Chris' course, Shipping Docker. If you have yet to discover his content, you will be very satisfied with every course he has to offer. He's a great human being and excellent educator.

This team has an excellent repository and millions of pulls per month. We really like how they structured their code.

These guys are absolute aces when it comes to Docker development. They are a great resource for tons of open source Docker images.

These images have a few key differences. These images are:

Our philosophy is: What you run in production is what you should be running in development.

You'd be shocked how many people create a Docker image and use it in the local development only. These images are designed with the intention of being deployed to the open and wild Internet.

We have a ton of helpful scripts and security settings configured for managing Laravel and WordPress.

We automatically detect if Laravel is installed and give you the option to enable automatic migrations and apply storage linking.

php artisan migrate --force

Automatic migrations are DISABLED by default. To enable, set an environment variable of AUTORUN_LARAVEL_MIGRATION=true on your container. We do not recommend enabling this on large or distributed applications. You should run your migrations manually for larger apps.

php artisan storage:link

Storage linking is ENABLED by default. You can disable this behavior by setting AUTORUN_LARAVEL_STORAGE_LINK=false.

We need to run the schedule:work command from Laravel. Although the docs say "Running the scheduler locally", this is what we want in production. It will run the scheduler in the foreground and execute it every minute. You can configure your Laravel app for the exact time that a command should run through a scheduled task.

Task Scheduler Command:

php artisan schedule:work

Example Docker Compose File:

version: '3'
services:
  php:
    image: my/laravel-app
    environment:
      PHP_POOL_NAME: "my-app_php"

  task:
    image: my/laravel-app
    # Switch to "webuser" before running `php artisan`
    # Declare command in list manner for environment variable expansion
    command: ["su", "webuser", "-c", "php artisan schedule:work"]
    environment:
      PHP_POOL_NAME: "my-app_task"

All you need to do is pass the Laravel Queue command to the container and S6 will automatically monitor it for you.

Task Command:

php artisan queue:work --tries=3

Example Docker Compose File:

version: '3'
services:
  php:
    image: my/laravel-app
    environment:
      PHP_POOL_NAME: "my-app_php"

  queue:
    image: my/laravel-app
    # Switch to "webuser" before running `php artisan`
    # Declare command in list manner for environment variable expansion
    command: ["su", "webuser", "-c", "php artisan queue:work --tries=3"]
    environment:
      PHP_POOL_NAME: "my-app_queue"

By passing Laravel Horizon to our container, S6 will automatically monitor it.

Horizon Command:

php artisan horizon

Example Docker Compose File:

version: '3'
services:
  php:
    image: my/laravel-app
    environment:
      PHP_POOL_NAME: "my-app_php"

  redis:
    image: redis:6
    command: "redis-server --appendonly yes --requirepass redispassword"

  horizon:
    image: my/laravel-app
    # Switch to "webuser" before running `php artisan`
    # Declare command in list manner for environment variable expansion
    command: ["su", "webuser", "-c", "php artisan horizon"]
    environment:
      PHP_POOL_NAME: "my-app_horizon"

• Hardening of Apache & NGINX included
• Disabling of XML-RPC
• Preventative access to sensitive version control or CI files
• Protection against other common attacks

See our Apache security.conf and NGINX security.conf for more detail.

If you're looking for a deeper example on how we run our WordPress blog, Server Side Up, check out this repository for a boilerplate example: https://github.com/serversideup/docker-wordpress

S6 Overlay is very helpful in managing a container's lifecycle that has multiple processes.

Wait... Isn't Docker supposed to be a "single process per container"? Yes, that's what it's like in a perfect world. Unfortunately PHP isn't like that. You need both a web server and a PHP-FPM server to see your files in order for your application to load.

We follow the S6 Overlay Philosophy on how we can still get a single, disposable, and repeatable image of our application out to our servers.

We like to customize our images on a per app basis using environment variables. Look below to see what variables are available and what their defaults are. You can easily override them in your own docker environments (see Docker's documentation).

Let's say that we have a basic Docker compose image working in development:

version: '3.7'
services:
  php:
    image: serversideup/php:8.0-fpm-nginx
    volumes:
      - .:/var/www/html/:cached

Now let's say we want to add the PHP ImageMagick extension. To do this, we will use the docker compose build option in our YAML file.

This means we would need to change our file above to look like:

version: '3.7'
services:
  php:
    build:
      context: .
      dockerfile: Dockerfile
    volumes:
      - .:/var/www/html/:cached

Notice the services.php.build options. We set a . to look for a dockerfile called Dockerfile within the same directory as our docker-compose.yml file.

For extra clarity, my project directory would look like this:

.
├── Dockerfile
├── docker-compose.yml
└── public
    └── index.php

The Dockerfile is where all the magic will happen. This is where we pull the Server Side Up image as a dependency, then run standard Ubuntu commands to add the extension that we need.

Dockerfile:

# Set our base image
FROM serversideup/php:8.0-fpm-nginx

# Install PHP Imagemagick using regular Ubuntu commands
RUN apt-get update \
    && apt-get install -y --no-install-recommends php8.0-imagick \
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/* /usr/share/doc/*

The next time you run docker compose up, Docker will build and cache the image for you automatically.

You can verify the CLI option installed correctly by echoing out the installed modules. Run this command in a new window while your containers are running via Docker Compose:

docker compose exec php php -m

To check that PHP-FPM loaded everything properly, use the phpinfo() functionally.

• You'll notice Docker likes to cache image builds (which is great for most functions)
• If you make changes to your Dockerfile, you may need to include --build with your Docker compose command (read more here)

If you want to rebuild, then you would run this:

docker compose up --build

Refer to the official instructions of the extension that you are trying to install. We use Ondrej's PHP repository, so chances are you might be able to find in in here: https://launchpad.net/~ondrej/+archive/ubuntu/php/+packages

Make sure to use the same version number as well. For example... If you are using 8.0 and want to install the php-imagick package, use the name php8.0-imagick during install (see my examples above).

By default, we generate a self-signed certificate for simple local development. For production use, we recommend using as a proxy to your actual container.

You have a few options for using SSL in production. These configurations are only supported in the php-apache and php-nginx configurations.

If you use mixed or full for your "SSL_MODE", we will check for certificate pairs at the following locations:

1. /etc/ssl/web/ssl.crt
2. /etc/ssl/web/ssl.key

Simply use Docker Volumes and mount the /etc/ssl/web folder with these two files in that directory.

If we do not find a certificate pair, we will generate a self-signed certificate pair for you.

1. Use a proxy that supports Let's Encrypt (like Traefik or Caddy)
2. Make sure you allow your proxy to direct traffic encrypted with self-signed certificates (if you're proxying to the container with a self-signed certificate)

This is what we do and it's really nice to use the automatic Let's Encrypt SSL management with these products.

Since there are a lot of dependencies on these images, please understand that it can make it complicated on merging your pull request.

We'd love to have your help, but it might be best to explain your intentions first before contributing.

If you find a critical security flaw, please open an issue or learn more about our responsible disclosure policy.