Docker-based hosting on your own VPS

First start with what are our main objectives:

• All domains served from the VPS should automatically receive an SSL certificate, without human intervention.
• The newly deployed sites and domains should be available right after they are deployed and the domains are routed to the VPS.
• The projects should have environments completely separated each other.
• Version control the project configurations.
• The projects should have separately configurable stacks. This means one project could run on specific versions of PHP, MySQL, Apache, Nginx or whatever, another project could run a completely different version of the same (or on a completely different stack).
• Keep the VPS configuration on the bare minimum, in order to have a fast escape plan to another VPS if something goes bad.

The requirements above can be achieved by an infrastructure based on Docker:

• Every project contains its own production configuration. This means they have to "ship" a complete service set (web server, database, PHP) in their e.g. docker-compose.yml file.
• The project will have its own stand-alone web server, with a specific set of domains defined in its section of docker-compose.yml. The reverse proxy will route the requests to this web server if the domain matches one of the domains specified in that set.
• Only the reverse proxy is available from the Internet.
• The reverse proxy listens on ports 80 and 443, but every request is automatically redirected to HTTPS.
• The certificates needed for HTTPS are automatically generated by its companion container via Let's Encrypt.

Below is an illustration of this infrastructure:

NB: The article assumes you have a preconfigured VPS with Docker and Docker Compose installed. If you don't have one yet, spin up one before continuing.

Reverse proxy

The files needed for our reverse proxy are available in this GitLab repository. Clone the repo and enter the newly created folder.

Here you can find a docker-compose.yml file with the content below:

It is not that complicated: we mount the host folders where they should be mounted (^.^) and set up some defaults. For details head to the documentation of the reverse proxy, the companion image, and the Nginx documentation.

Important: this configuration works only with browsers supporting SNI (so a combination of Windows XP + Internet Explorer 8 is out of the question), but in return, it will score an A+ on the test of Qualys SSL Labs.

Project configuration

To have our reverse proxy route the traffic properly, each project should indicate which requests belong to it. This is done via the VIRTUAL_HOST and LETSENCRYPT_HOST environment variables of the web server of the project: the first contains the set of domains which should be routed to the web server, and the second one indicates for which domains should the companion container acquire an SSL certificate. These two sets overlap completely in almost every case, so we could use a .env file next to our docker-compose.yml in our project defining these variables. Moreover, we have to connect our project web server (blue discs in our illustration above) to the network of the reverse proxy (in this case the name of the network is nginx_reverse_proxy).

.env:

docker-compose.yml:

As you can see, we use far more variables than those two I wrote about: this way we can reuse our docker-compose.yml file in all of our projects: Docker (as well as Craft - you see where we are heading? :) ) can use the .env file, so we only need to change the content of the .env file in our projects, the rest is handled by the variables and the docker-compose.yml.

You might consider using an additional build step to not use .env in production, but inject these variables through server configuration.

More noteworthy bits:

• we don't map the containers ports to any "real" ports on the host: they are only available through the Docker network,
• we set log rotation (max 3 files) and small file size (max. 1 MB each),
• the containers are restarted no matter what happens (this is important... :P)

Let's spin up our project (docker-compose up -d)! The letsencrypt_nginx_proxy_companion container will be triggered by the event emitted by the containers starting up, so it will initiate the certificate generation process (if it can't find a suitable certificate already present) - you can check it with docker logs letsencrypt_nginx_proxy_companion. I couldn't figure out yet why I ended up in a redirect loop if the cloud icon in Cloudflare is orange (=the additional CF features, including the free SSL certificates, are active), so if you know what causes this, please, ping me and I will update this article. Update: Matt Stein advised me to set Crypto -> SSL from Flexible to Full. It seems that solved the issue - thanks Matt! If your non-www or www subdomain suffers from a redirect loop, set up a redirect rule from that subdomain to the other one (e.g.: non-www stuck in redirect loop: set up a redirect rule from non-www to www).

If you (and I) did everything right, you now have a server with an A+ HTTPS connection, your projects can run on it completely separated and you can host your clients' project on it until it can handle the traffic. Yay!

You can find more details about the images used in the project example here:

• Craft CMS Nginx
• Craft CMS PHP

PS: on DigitalOcean you still get credits worth $100 for new registrations - I don't know if this is a permanent or a temporary promotion, but if you want to give the world of VPS a try, this a good opportunity. The credits are valid for 60 days.

If you have any question or you have found an error/bug, please get in touch!