This guide outlines a highly secure method for managing your Docker daemon API, especially when you have containers (like Traefik) needing access on the same host. This approach leverages Docker's built-in security features and standard Linux networking tools to create a robust and isolated environment.
This setup combines:
- User Namespace Remapping (
userns-remap): To isolate container processes from host root privileges. - Dummy Network Interface: To create a dedicated, isolated network endpoint for the Docker API on the local host.
- Mutual TLS (mTLS): To ensure strong authentication and encryption for Docker API communication.
- UFW (Uncomplicated Firewall): To enforce strict network access rules, explicitly blocking external connections to the Docker API.
By default, directly exposing the Docker API over TCP is unsecure. While userns-remap significantly enhances host security by remapping container root to an unprivileged user, it doesn't inherently secure the Docker API access point itself from other containers on the same host.
Directly mounting /var/run/docker.sock into containers (e.g., for Traefik to interact with the Docker daemon) can also be risky. If a container with docker.sock access is compromised, an attacker could potentially control your entire Docker daemon, launching malicious containers or impacting others.
This solution addresses these concerns by:
- Eliminating Direct
docker.sockMounting: Your Traefik container will connect to a TCP endpoint, not directly mount the Unix socket. - Isolating API Access: The Docker API is bound to an isolated dummy interface, preventing external network exposure.
- Enforcing Strict Authentication: mTLS ensures only trusted clients (like Traefik, with its specific client certificate) can communicate with the Docker daemon.
- Layered Defense: Combining
userns-remap, network isolation, mTLS, and firewall rules creates a robust security posture.
These steps guide you through installing Docker Engine on Ubuntu, following the official Docker documentation.
Remove any existing Docker-related packages that might conflict with the new installation.
for pkg in docker.io docker-doc docker-compose docker-compose-v2 podman-docker containerd runc; do sudo apt-get remove $pkg; doneExplanation: This command iterates through common package names for Docker and related tools, ensuring any older or conflicting installations are removed to prevent issues during the new installation.
Set up Docker's APT repository to ensure you install the latest official packages.
# Add Docker's official GPG key:
sudo apt-get update
sudo apt-get install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc
# Add the repository to Apt sources:
echo \
"deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
$(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}") stable" | \
sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt-get updateExplanation: These commands first install necessary utilities (ca-certificates, curl), create a directory for APT keyrings, download Docker's GPG key, set appropriate permissions for the key, and then add the Docker APT repository to your system's sources list. Finally, sudo apt-get update refreshes your package list to include Docker packages.
Install the core Docker components.
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-pluginExplanation: This command installs docker-ce (Docker Community Edition daemon), docker-ce-cli (the command-line client), containerd.io (the container runtime), docker-buildx-plugin (for enhanced build capabilities), and docker-compose-plugin (for managing multi-container Docker applications).
Test your Docker installation to ensure it's working correctly.
sudo docker run hello-worldExplanation: This command pulls and runs the hello-world Docker image. If successful, it prints a message confirming Docker is installed and running correctly, then exits.
This section details how to secure your Docker environment using userns-remap for host isolation and mTLS for API access control.
This configuration prevents privilege-escalation attacks by remapping the container's root user to a less-privileged user on the host.
đź’ˇ Why?
The best way to prevent privilege-escalation attacks from within a container is to configure your container's applications to run as unprivileged users. For containers whose processes must run as the root user within the container, you can re-map this user to a less-privileged user on the Docker host. The mapped user is assigned a range of UIDs which function within the namespace as normal UIDs from 0 to 65536, but have no privileges on the host machine itself.
See related Docker documentation on User Namespace Remap.
Before configuring, you can check if any subuid or subgid mappings already exist.
grep -E '^(root|dockremap)' /etc/subuid /etc/subgid
cat /etc/subuidExample Output:
myUser:100000:65536
Explanation: These commands display entries in /etc/subuid and /etc/subgid which define ranges of UIDs and GIDs available for user namespaces. After userns-remap is enabled, Docker will typically add an entry for a dockremap user.
Edit or create the Docker daemon configuration file.
sudo nano /etc/docker/daemon.jsonPaste the following content:
{
"userns-remap": "default",
"experimental": false,
"storage-driver": "overlay2"
}Explanation:
"userns-remap": "default": Instructs Docker to automatically create adockremapuser and manage the UID/GID remapping ranges."experimental": false: Disables experimental Docker features."storage-driver": "overlay2": Specifies OverlayFS as the storage driver, which is the recommended and most efficient driver for most Linux distributions. See Docker's OverlayFS documentation for more info.- Optional: You can add
"log-driver": "journald"for centralized logging withsystemd-journald.
Apply the userns-remap configuration by restarting the Docker daemon.
sudo systemctl daemon-reload
sudo systemctl restart dockerExplanation: daemon-reload reloads the systemd manager configuration. restart docker stops and then starts the Docker daemon, applying the new daemon.json settings. Be aware that enabling userns-remap will cause all existing containers and images to become inaccessible and require rebuilding/re-pulling.
Verify that the dockremap user has been created and its details.
getent passwd dockremapExample Output: dockremap:x:997:985::/home/dockremap:/bin/sh
id dockremapExample Output: uid=997(dockremap) gid=985(dockremap) grupos=985(dockremap)
Explanation: These commands confirm the creation and details of the dockremap user, which Docker uses internally for user remapping. The UIDs and GIDs for dockremap might vary on your system.
This section sets up secure, mutually authenticated communication for the Docker API using custom scripts and OpenSSL configuration files available in your repository.
First, clone the docker_conf_m8 repository to /opt/docker_conf_m8 to get the necessary scripts and configuration templates.
# Define the IP for your dummy interface (e.g., 10.254.254.1)
export DOCKER_HOST_IP="YOUR_DOCKER_HOST_IP_HERE" # <<< IMPORTANT: SET THIS!
BASE_DIR="/opt/docker_conf_m8"
# Clone the repository
sudo git clone https://github.com/mano8/docker_conf_m8.git "${BASE_DIR}"
sudo chmod 700 "${BASE_DIR}" # Secure base directoryExplanation: This sets up your base directory and clones the docker_conf_m8 repository containing the necessary files. Remember to replace "YOUR_DOCKER_HOST_IP_HERE" with the actual IP you intend to use for your Docker dummy interface (e.g., 10.254.254.1). This IP will be embedded in the certificates.
The repository contains:
-
scripts/validate_docker_host_ip.sh:- Purpose: This script ensures that the
DOCKER_HOST_IPenvironment variable is set and contains a valid IPv4 address. It's a crucial prerequisite for generating correct certificates. - Location: https://github.com/mano8/docker_conf_m8/blob/main/scripts/validate_docker_host_ip.sh
- Purpose: This script ensures that the
-
ssl_conf/ssl_docker_server.conf:- Purpose: This is a template for the Docker daemon's server certificate. It defines default OpenSSL settings, organizational details, and placeholder
alt_names(Subject Alternative Names). TheIP.2entry will be dynamically updated by the certificate generation script to ensure it matches yourDOCKER_HOST_IP. - Location: https://github.com/mano8/docker_conf_m8/blob/main/ssl_conf/ssl_docker_server.conf
- Purpose: This is a template for the Docker daemon's server certificate. It defines default OpenSSL settings, organizational details, and placeholder
-
ssl_conf/ssl_docker_client.conf:- Purpose: This is a template for the client certificate used by applications like Traefik. Similar to the server config, it defines details and placeholder
alt_namesthat will be dynamically updated. - Location: https://github.com/mano8/docker_conf_m8/blob/main/ssl_conf/ssl_docker_client.conf
- Purpose: This is a template for the client certificate used by applications like Traefik. Similar to the server config, it defines details and placeholder
-
scripts/manage_docker_certs.sh:- Purpose: This is the core script that automates the entire certificate management process. It generates the Certificate Authority (CA) key and certificate, the Docker daemon's server key and certificate, and the client key and certificate (for Traefik). It also handles permissions and ownership, including setting correct ownership for client certificates for
userns-remapenvironments. It can also remove all generated certificates. - Location: https://github.com/mano8/docker_conf_m8/blob/main/scripts/manage_docker_certs.sh
- Purpose: This is the core script that automates the entire certificate management process. It generates the Certificate Authority (CA) key and certificate, the Docker daemon's server key and certificate, and the client key and certificate (for Traefik). It also handles permissions and ownership, including setting correct ownership for client certificates for
Execute the manage_docker_certs.sh script to generate all necessary mTLS certificates and keys. This script uses the templates and validates the DOCKER_HOST_IP you set earlier.
sudo "${BASE_DIR}/scripts/manage_docker_certs.sh" generateExplanation: This command runs the certificate management script in generate mode. It will create:
- Server Certificates:
ca.pem,server-key.pem,server-cert.pemin/etc/docker/certs/(for the Docker daemon). - Client Certificates:
ca.pem,client-key.pem,client-cert.pemin/opt/docker_conf_m8/certs/(for client applications like Traefik). The client certificates directory will be chowned to thedockremapUID to ensure proper permissions when mounted into remapped containers.
To properly configure the docker0 dummy interface, you need to identify which network management system your Linux distribution uses. This typically depends on whether you're running a server or a desktop environment, and the specific distribution (e.g., Debian, Ubuntu).
Crucial Note: You must select only one of the following methods to set up the docker0 interface. Applying multiple configurations for the same interface will lead to conflicts and unpredictable network behavior.
Here are the common scenarios to help you determine the correct approach:
- Netplan: This is the default on Ubuntu servers and most recent Ubuntu Desktop installations. Netplan acts as an abstraction layer, generating configurations for either
systemd-networkd(its default backend) orNetworkManager.- Quick Check: Look for a YAML file within
/etc/netplan/(e.g.,00-installer-config.yaml).
- Quick Check: Look for a YAML file within
- NetworkManager: Commonly used on most desktop environments (Ubuntu Desktop, Linux Mint, Debian Desktop). It provides dynamic network management, often with a graphical user interface.
- Quick Check: Execute
systemctl is-active NetworkManager(it should showactive) andnmcli general status.
- Quick Check: Execute
ifupdown: This is the traditional method, primarily found on Debian Server installations and some older Ubuntu versions, where network settings are configured directly in/etc/network/interfaces.- Quick Check: Inspect the contents of
/etc/network/interfacesfor specific interface definitions.
- Quick Check: Inspect the contents of
Once you've identified your system's network manager, proceed with the steps in the corresponding section below.
If your system relies on Netplan, follow these instructions. If you've previously created direct systemd-networkd configuration files (e.g., in /etc/systemd/network/) for docker0, remove them before proceeding to avoid conflicts.
Create a new Netplan YAML configuration file.
sudo nano /etc/netplan/99-docker-dummy-interface.yamlInsert the following configuration. Adjust 10.254.254.1/24 if your chosen DOCKER_HOST_IP differs.
network:
version: 2
renderer: networkd # For server setups, 'networkd' is generally preferred. On desktops where NetworkManager manages all interfaces, 'NetworkManager' might be more appropriate.
netdevs:
docker0:
kind: dummy
ethernets:
docker0:
addresses: [10.254.254.1/24]
nameservers:
addresses: [1.1.1.1, 8.8.8.8] # Optional: specify DNS serversExplanation: This configuration designates docker0 as a virtual dummy network device. It then assigns a static IP address (10.254.254.1/24) to this interface. Make sure this IP aligns with the DOCKER_HOST_IP used during certificate generation.
First, validate the syntax of your new Netplan configuration.
sudo netplan tryIf netplan try reports no errors, permanently apply the configuration.
sudo netplan applyExplanation: netplan try performs a syntax check and attempts a temporary application. If successful, netplan apply writes the necessary backend configurations and restarts the relevant network services to make the changes permanent.
If NetworkManager is your system's primary network management tool (common on Linux Mint, Ubuntu Desktop, Debian Desktop), use these steps.
Utilize nmcli to create a new "dummy" type connection named docker0 and assign its IP address.
# Create the dummy interface connection
sudo nmcli connection add type dummy con-name docker0 ifname docker0
# Assign the static IP address to the docker0 connection
sudo nmcli connection modify docker0 ipv4.addresses 10.254.254.1/24 ipv4.method manual
# Optional: Set DNS servers for this interface
sudo nmcli connection modify docker0 ipv4.dns "1.1.1.1 8.8.8.8"
# Activate the connection
sudo nmcli connection up docker0Explanation: These commands instruct NetworkManager to create a new dummy interface, configure it with the specified static IPv4 address (10.254.254.1/24), and then bring the interface online. NetworkManager will automatically persist this configuration.
For systems managing network configurations via ifupdown (typical for traditional Debian server setups not using Netplan or NetworkManager as primary managers), follow these steps.
Since ifupdown cannot directly create "dummy" type interfaces through its configuration file alone, you'll first create it manually, then ensure its persistence.
# Create the docker0 dummy interface (temporary until configured for persistence)
sudo ip link add docker0 type dummy
sudo ip link set docker0 upExplanation: These commands create and activate a new virtual network interface of type "dummy" named docker0.
Edit your system's main network configuration file to ensure docker0 is created and configured at boot time.
sudo nano /etc/network/interfacesAppend the following lines to the file. Confirm that the IP 10.254.254.1 matches your DOCKER_HOST_IP.
# Configuration for the Docker API dummy interface
auto docker0
iface docker0 inet static
pre-up ip link add docker0 type dummy || true
address 10.254.254.1
netmask 255.255.255.0
post-down ip link del docker0 || trueExplanation: These entries ensure the docker0 interface is automatically brought up (auto docker0) with a static IP configuration (iface docker0 inet static). The pre-up and post-down commands handle the creation and deletion of the dummy device itself during interface activation/deactivation.
To apply these changes without a full system reboot (often required for ifupdown changes), try bringing the interface down and then up.
sudo ifdown docker0
sudo ifup docker0Note: Depending on your specific system and its network setup, a complete restart of the networking service (sudo systemctl restart networking) or a server reboot might still be necessary for the changes to fully take effect.
Important: If you're using ifupdown, verify that NetworkManager is not actively managing docker0 and that Netplan does not have a conflicting configuration for it, to prevent network issues.
Regardless of the method you used to set up the dummy interface, confirm that docker0 is active and has the correct IP address.
ip addr show docker0Expected Output: Similar to the example provided in the original section, showing docker0 with an inet 10.254.254.1/24 entry.
Now, instruct the Docker daemon to listen on the secure dummy interface using mTLS.
Open the Docker daemon configuration file again.
sudo nano /etc/docker/daemon.jsonModify its content to include the hosts and tls* settings. The userns-remap, experimental, and storage-driver settings should remain.
{
"userns-remap": "default",
"experimental": false,
"storage-driver": "overlay2",
"hosts": ["unix:///var/run/docker.sock", "tcp://10.254.254.1:2376"],
"tlsverify": true,
"tlscacert": "/etc/docker/certs/ca.pem",
"tlscert": "/etc/docker/certs/server-cert.pem",
"tlskey": "/etc/docker/certs/server-key.pem"
}Explanation:
"hosts": ["unix:///var/run/docker.sock", "tcp://10.254.254.1:2376"]: This tells Docker to listen on both the local Unix socket (for local CLI access) and the secure TCP port 2376 on thedocker0interface (for remote/container access)."tlsverify": true: Enforces mutual TLS, meaning both the client and server must present valid certificates."tlscacert","tlscert","tlskey": Specify the paths to the CA certificate, the Docker daemon's server certificate, and its private key, respectively. These were generated in the previous steps.
Restart Docker to apply the new API and TLS configurations.
sudo systemctl daemon-reload
sudo systemctl restart dockerExplanation: Similar to before, this reloads systemd configurations and restarts Docker to pick up the changes in daemon.json.
Test the mTLS connection from your host using the client certificates.
Define environment variables that point to your client certificates and the secure Docker API endpoint.
export DOCKER_TLS_VERIFY="1"
export DOCKER_CERT_PATH="/opt/docker_conf_m8/certs"
export DOCKER_HOST="tcp://10.254.254.1:2376"Explanation:
DOCKER_TLS_VERIFY="1": Tells the Docker CLI to verify the server's certificate against the CA and ensure mutual authentication.DOCKER_CERT_PATH: Points to the directory containing your client'sca.pem,client-cert.pem, andclient-key.pem.DOCKER_HOST: Specifies the IP address and port of the Docker daemon's secure TLS endpoint.
Now, try a Docker command using these secure settings.
docker psExpected Output: You should see an empty list of running containers or any containers you might have started, without any TLS handshake errors. Explanation: If this command runs successfully, it confirms that your Docker CLI can securely communicate with the Docker daemon over the mTLS-secured TCP endpoint.
Secure your host by ensuring only necessary traffic can reach the Docker API.
IMPORTANT SECURITY NOTE: When enabling UFW, ensure you allow SSH traffic first, otherwise you might lose connectivity to your server!
Allow your SSH port (default is 22) before enabling UFW.
sudo ufw allow ssh comment 'Allow SSH access'
# If SSH runs on a non-standard port, e.g., 2222:
# sudo ufw allow 2222/tcp comment 'Allow SSH on custom port'Explanation: This rule explicitly permits incoming SSH connections, preventing you from being locked out when the firewall is activated.
Set the default UFW policies and enable the firewall.
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enableExplanation: These commands set the default policy to deny all incoming connections and allow all outgoing connections. sudo ufw enable activates the firewall. You will be prompted to confirm; type y and press Enter.
The docker0 dummy interface is for internal host communication. Your Traefik container, running on a Docker bridge network (traefik_proxy), will communicate with the Docker daemon via Docker's internal networking. UFW needs a rule to allow this specific internal traffic.
First, identify the subnet of your traefik_proxy network:
docker network inspect traefik_proxy | grep -A 3 'IPAM' | grep 'Subnet'Example Output: "Subnet": "172.18.0.0/16",
Explanation: This command inspects your traefik_proxy network and extracts its IP subnet. You will use this subnet in the UFW rule.
Now, add the UFW rule:
# REPLACE <TRAEFIK_NETWORK_SUBNET> with the actual subnet from the command above (e.g., 172.18.0.0/16)
sudo ufw allow in on docker0 from <TRAEFIK_NETWORK_SUBNET> to 10.254.254.1 port 2376 proto tcp comment 'Allow Traefik container to access Docker API'Explanation: This rule explicitly allows incoming TCP traffic on the docker0 dummy interface, originating from any IP within your traefik_proxy Docker network's subnet, destined for the 10.254.254.1 IP on port 2376. This ensures Traefik can connect while external access remains blocked by the default deny policy.
Check the active UFW rules.
sudo ufw status verboseExplanation: This command displays all active UFW rules and their status, confirming your configurations are applied.
Finally, configure Traefik to connect to the Docker daemon using the mTLS client certificates over the dummy interface.
Create a docker-compose.yml file for your Traefik service.
nano docker-compose.ymlPaste the following content:
version: '3.8'
services:
traefik:
image: traefik:v3.4.0 # Updated to the latest stable version
container_name: traefik
restart: unless-stopped
security_opt:
- no-new-privileges:true
networks:
- traefik_proxy
ports:
- "80:80" # The HTTP port
- "443:443" # The HTTPS port
# - "8080:8080" # The Dashboard (optional)
volumes:
- /etc/localtime:/etc/localtime:ro
- /var/run/docker.sock:/var/run/docker.sock:ro # Used only for Docker provider to listen for events, NOT for API access
- /etc/traefik:/etc/traefik:ro # Configuration directory
- /opt/docker_conf_m8/certs:/etc/traefik/certs:ro # Mount client certificates from the host
environment:
# Docker Host configuration for mTLS
- DOCKER_HOST=tcp://10.254.254.1:2376
- DOCKER_TLS_VERIFY=1
- DOCKER_CERT_PATH=/etc/traefik/certs # Path to client certs INSIDE the container
# Basic Traefik configuration
- TZ=Europe/Madrid # Set your timezone
labels:
- "traefik.enable=true"
- "traefik.http.routers.api.rule=Host(`traefik.example.com`)" # Change to your domain
- "traefik.http.routers.api.entrypoints=websecure"
- "traefik.http.routers.api.service=api@internal"
- "traefik.http.routers.api.middlewares=auth"
- "traefik.http.middlewares.auth.basicauth.users=youruser:$$apr1$$YOURHASHEDPASSWORDHERE" # Generate with 'echo $(htpasswd -nb youruser yourpassword)'
- "traefik.http.routers.api.tls.certresolver=myresolver" # If using HTTPS
# Global Redirect HTTP to HTTPS (optional)
- "traefik.http.middlewares.redirect-https.redirectscheme.scheme=https"
- "traefik.http.routers.web-http.rule=HostRegexp(`{host:.+}`)"
- "traefik.http.routers.web-http.entrypoints=web"
- "traefik.http.routers.web-http.middlewares=redirect-https"
networks:
traefik_proxy:
external: true # Assumes you have a bridge network named traefik_proxyExplanation:
image: traefik:v3.4.0: Specifies the Traefik image version, now updated.security_opt: - no-new-privileges:true: Enhances container security by preventing privilege escalation.volumes:/var/run/docker.sock:/var/run/docker.sock:ro: Crucial point: Traefik's Docker provider needs access todocker.sockto listen for Docker events (container starts/stops, label changes). However, it will not use this socket for API communication whenDOCKER_HOSTis set to a TCP endpoint. This is a common pattern for Traefik and ensures it can dynamically configure itself based on your Docker setup. The:romakes it read-only./opt/docker_conf_m8/certs:/etc/traefik/certs:ro: This mounts the client certificates generated earlier from your host into the Traefik container. The certificates will be available inside the container at/etc/traefik/certs.
environment:DOCKER_HOST=tcp://10.254.254.1:2376: Instructs Traefik to connect to the Docker daemon via the secure TCP endpoint on your dummy interface.DOCKER_TLS_VERIFY=1: Tells Traefik's Docker client to verify the Docker daemon's certificate.DOCKER_CERT_PATH=/etc/traefik/certs: Specifies the path inside the container where the client certificates are mounted.
labels: Standard Traefik labels for routing and services. Remember to adjustHost(traefik.example.com)to your actual domain.networks: Connects Traefik to an external network, typically used for other containers Traefik manages. Create this network if it doesn't exist:docker network create traefik_proxy.
Create a basic Traefik configuration file to enable the Docker provider and define entrypoints.
sudo nano /etc/traefik/traefik.ymlPaste the following content (adjust as needed for your specific Traefik setup):
api:
dashboard: true
insecure: false # Set to true if you expose dashboard on 8080 without auth/TLS
entryPoints:
web:
address: ":80"
http:
redirections:
entryPoint:
to: "websecure"
scheme: "https"
websecure:
address: ":443"
providers:
docker:
endpoint: "tcp://10.254.254.1:2376" # Point to the secure Docker API
tls:
ca: "/etc/traefik/certs/ca.pem"
cert: "/etc/traefik/certs/client-cert.pem"
key: "/etc/traefik/certs/client-key.pem"
insecureSkipVerify: false
exposedByDefault: false # Only expose containers with traefik.enable=true label
certificatesResolvers:
myresolver:
acme:
email: your-email@example.com # Change to your email
storage: "/etc/traefik/acme.json" # Ensure this path is mounted as a volume
httpChallenge:
entryPoint: webExplanation:
api.dashboard: Enables the Traefik dashboard.entryPoints: Defines HTTP (web) and HTTPS (websecure) entry points.providers.docker:endpoint: "tcp://10.254.254.1:2376": This is the critical part, instructing Traefik to connect to the Docker API at the mTLS-secured dummy interface IP and port.tls: Configures Traefik's TLS client.ca: Path to the CA certificate inside the container.cert: Path to the client's public certificate inside the container.key: Path to the client's private key inside the container.insecureSkipVerify: false: Ensures Traefik verifies the Docker daemon's certificate.
exposedByDefault: false: Best practice to only route traffic to containers explicitly enabled with Traefik labels.
certificatesResolvers.myresolver: Configures ACME (Let's Encrypt) for automatic SSL certificate management. Remember to set your correct email address.
Finally, start your Traefik service using Docker Compose.
docker compose up -dExplanation: This command starts the Traefik container in detached mode, applying all the configurations. Traefik should now be securely connected to your Docker daemon via mTLS over the dummy interface.
This complete setup provides a highly secure and isolated Docker environment, especially beneficial for configurations involving self-hosting applications with tools like Traefik.
AI Assisted Content: This article was generated with the help of an artificial intelligence.