Welcome to the third page of a handbook on self-hosting. Begin here. On this page, we'll be using docker-compose to add web apps and containers to our self-hosting stack.
Topics covered on this page
- A recap of environment variables and ports
- Example: Adding Gitea to your self-hosting stack
- Example: Adding FreshRSS to your self-hosting stack
- How does this actually work?
[cta_inline]
A recap of environment variables and ports
On the previous page of this self-hosting handbook, we walked through your docker-compose.yml file and I tried to explain how to specify different environment variables that will both allow our orchestration containers to grab SSL certificates from Let's Encrypt, and allow all the containers to communicate with each other as needed.
I have a feeling some of these variables and configurations might still be a little confusing, so let's take a moment to recap the important ones and how to set them up correctly in the future. Throughout the remainder of this handbook, I will include docker-compose service blocks that I've tested to work with this self-hosting stack, but there are likely other containers you will want to add to your stack, and you'll only be able to do that if you understand how these environment variables work.
As I mentioned on the previous page, there are three critical environment variables: VIRTUAL_HOST, LETSENCRYPT_HOST, and LETSENCRYPT_EMAIL. Let me quote myself from that page.
There are three essential environment variables to set here: the VIRTUAL_HOST, the LETSENCRYPT_HOST, and the LETSENCRYPT_EMAIL.
The LETSENCRYPT_EMAIL variable is simplest to explain: Replace the EMAIL variable with your email.
The VIRTUAL_HOST and LETSENCRYPT_HOST both reference the domain at which you'll access the Portainer service using your browser. Both these variables must be set on every Docker container you want to access via the reverse proxy.
There are a few other environment variables that you may need to employ.
VIRTUAL_PORT
To get started, here's what the nginx-proxy documentation says about VIRTUAL_PORT:
If your container exposes multiple ports, nginx-proxy will default to the service running on port 80. If you need to specify a different port, you can set a VIRTUAL_PORT env var to select a different one. If your container only exposes one port and it has a VIRTUAL_HOST env var set, that port will be selected.
By default, nginx-proxy will assume that your container will be listening for traffic on port 80. If the ports section in the docker-compose configuration reads something like - "667:80", then you don't need to use VIRTUAL_PORT. In that case, the Docker containing will be listening to traffic on port 80, and nginx-proxy will
by subscribing to our newsletter.
