Reverse proxy used to expose FSFE services
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
This repo is archived. You can view files and clone it, but cannot push or open issues/pull-requests.
Max Mehl 501c72b179
download from dockerhub instead of build from github
1 year ago
errorpage Correct missing word on 3 years ago
rp Add default vhost config regardless of whether there are specific vhost settings 2 years ago
.drone.yml Specify the docker-compose project name (#5) 3 years ago
.gitignore Initial commit 4 years ago
LICENSE Initial commit 4 years ago Document the rp/extra-conf/ folder 2 years ago
docker-compose.yml download from dockerhub instead of build from github 1 year ago

fsfe-reverse proxy

This is the reverse proxy which exposes FSFE services and handles SSL termination (including Docker services).

How to use this?

To be included in the reverse proxy, a Docker container should be started with the environment variable VIRTUAL_HOST, for instance:

docker run -e "" ...

Let's Encrypt

To expose the service through HTTPS, use the following env variables when running you docker container:

LETSENCRYPt_emaIL: <email>

Please make sure that resolves to the public IP address of the server where the reverse proxy is.

Per virtual host configuration

If you want to customize the nginx configuration for a virtual host, add or modify rp/extra-conf/

External Services

Services which run externally to the Docker host can be included in the proxy by including a relevant configuration for them in the sites-enabled/ directory. Please note that any configuration files must match *.conf

How does it work?

The reverse proxy automatically adds SSL certificates (via LetsEncrypt) and sets up the reverse proxy for any Docker containers running locally.

It does that by monitoring container creation and deletion and updating its configuration accordingly. Here is an example of the generated configuration for our discourse installation:

upstream {
server {
    listen 80 ;
    access_log /var/log/nginx/access.log vhost;
    return 301 https://$host$request_uri;
server {
    listen 443 ssl http2 ;
    include /etc/nginx/vhost.d/default;
    location / {

Building and deploying the reverse proxy

The reverse proxy itself is composed of three docker containers.


In the rp folder, there is the Dockerfile used to build the nginx-based reverse proxy. It is build on top of that image.

There are three modifications:

  • it includes the site-enabled folder in the nginx configuration, so it's easy to use this reverse proxy with non-dockerised services.

  • The rp/nginx.tmpl file (original version here) has been modified to use a redirect instead of a 503 HTTP error in case nginx can't find the requested virtual host.

  • The rp/nginx.tmpl file (original version here) has been modified to use a redirect if a container is down (and has the VIRTUAL_HOST environment variable).


The rple container is the let's encrypt companion. It is responsible for issuing and managing the TLS certificates used by the reverse proxy. More info in the official repository.


The errorpage folder contains a simple container that displays an error page if the reverse proxy can't find the requested VIRTUAL_HOST.

Deployment with the ansible playbook

The ansible playbook builds the two docker images mentioned above, and run the containers with the right parameters. Here is a list of the non-self-explanatory ones:

  • The labels com.github.jrcs.letsencrypt_nginx_proxy_companion.nginx_proxy is needed by the rple container so it knows for which nginx container it should manage certificates.
  • volumnes_from tell docker to use the same volumes for both containers. We still need to specify the volumes instruction for both containers because they don't have the same rights over the volumes.