This configuration was meant to be used in my (Ludovic) personal homelab and I wanted to share my findings with you if you are interested in doing something similar.
Therefore, this example is optional to follow. It is here to show you how to use Traefik in a more advanced way and for your own culture.
For more information about my modest setup, please refer to the Personal notes section.
This configuration is an improvement of the
traefik-secure
example. It adds the following
features:
- Make use of the DNS challenge to generate HTTPS certificates, even if Traefik is not publicly accessible
- Enable HTTPS globally for all services (entrypoint level)
- HTTP is not accessible anymore
- Generate a common HTTPS certificate for all the services (wildcard certificate)
- Redirect all HTTP requests to HTTPS at the entrypoint level instead of using
the
http-to-https-redirect
middleware (cleaner configuration)
As you will be using the DNS challenge with a new configuration, you must rename
or remove the letsencrypt
folder from the previous example.
# Rename the folder
mv letsencrypt letsencrypt.old
You must have a domain name ready.
Your DNS provider must support the ACME DNS challenge. You can find a list of supported DNS providers at https://doc.traefik.io/traefik/https/acme/#providers.
For this example, we will use deSEC as our DNS provider.
You must create the API key(s) for the DNS provider. For deSEC, you can follow the instructions at https://desec.io/api/v1/docs/.
Update the .env
file with your own values:
TRAEFIK_ACME_EMAIL
: your email addressTRAEFIK_ACME_DNS_PROVIDER
: the name of your DNS provider - check the list of supported DNS providers at https://doc.traefik.io/traefik/https/acme/#providersTRAEFIK_ROOT_FULLY_QUALIFIED_DOMAIN_NAME
: the root fully qualified domain name to access all your services - for example, if you want to access your services with thehttps://whoami.my-domain-name.dedyn.io
URL, you must setTRAEFIK_ROOT_FULLY_QUALIFIED_DOMAIN_NAME=my-domain-name.dedyn.io
TRAEFIK_FULLY_QUALIFIED_DOMAIN_NAME
: the fully qualified domain name to access Traefik - by default, Traefik will be accessible athttps://traefik.TRAEFIK_ROOT_FULLY_QUALIFIED_DOMAIN_NAME
Update the dns-challenge.env
file with the values
needed by your DNS provider based on the
list of supported DNS providers.
For deSEC, you must set the following environment variables:
DESEC_TOKEN
: the token to access the deSEC API
Add two A
records to the DNS zone of your domain name provider to point to the
IP address of the virtual machine:
my-domain-name.dedyn.io
-> to the IP address of the virtual machine: this will allow access to a service hosted under the root of your domain name (https://my-domain-name.dedyn.io
)*.my-domain-name.dedyn.io
-> to the IP address of the virtual machine: this will allow access to all your services hosted under a subdomain of your domain name (https://whoami.my-domain-name.dedyn.io
orhttps://my-awesome-service.my-domain-name.dedyn.io
)
Test the DNS resolution of the fully qualified domain names:
# Test the DNS resolution for the root fully qualified domain name
dig my-domain-name.dedyn.io
# Test the DNS resolution for the wildcard fully qualified domain name
dig "*.my-domain-name.dedyn.io"
You could even try any domain name as you have a wildcard DNS entry:
# Test the DNS resolution for the wildcard fully qualified domain name
dig a-dummy-placeholder.my-domain-name.dedyn.io
You might have to wait a few minutes for the DNS record to be propagated.
Start the containers on the virtual machine:
# Start the containers
docker compose up -d
Open your browser and go to the fully qualified domain name of the Traefik
service you defined in the .env
file with the http
protocol, for example
http://TRAEFIK_FULLY_QUALIFIED_DOMAIN_NAME
.
You should now be able to access the Traefik dashboard just like in the previous example.
The advantages of this configuration reside in the configuration of the Docker Compose files.
If you compare both solutions, you will notice that the docker-compose.yml
files are cleaner and easier to read in the current example.
Only two Let's Encrypt certificates are generated over the N number of services you have. This is because we are using a root + wildcard certificates and not a certificate per service.
You can now add as many services as you want without having to worry about generating a new certificate for each service.
Using the wildcard certificate, you can even use the same certificate for services that are not publicly accessible and still use HTTPS on your local network. Check the Personal notes section for more information.
My personal homelab consists of a NAS running Proxmox VE with a few LXC containers running under Debian 12.
I do not expose all my services publicly. To access my private services, I use WireGuard to connect to my home network.
I have a domain name registered with Infomaniak
under the name ld0.ch
that I use for my homelab (the shorter the DNS name, the
less I have to type 😉).
I have a DNS server running AdGuard Home that is used as the DNS server for my local network.
Using Traefik, I can access all my services with a common fully qualified domain name.
In my DNS server, I have some DNS entries that points to the IP address of my
homelab (*.lan.ld0.ch
).
This allows me to access all my services with a subdomain such as
traefik.lan.ld0.ch
for when I am connected to my home network or
whoami.ld0.ch
for the public services.
All this setup works quite well for me, but I was interested in having HTTPS certificates for all my services, even locally. I wanted to keep things simple without having to manually generate certificates and/or using other tools such as mkcert or moving my homelab to the cloud or Kubernetes.