Should You Run Traefik in Docker, LXC or a VM on Proxmox?

Traefik can run in several ways on Proxmox. You can deploy it as a Docker container, install the Traefik binary inside an LXC container, or place it inside a dedicated virtual machine.

These options are not completely separate. Docker describes how Traefik is packaged, while LXC and virtual machines describe where it runs. The most common designs are Docker inside a virtual machine, Docker inside an LXC container, or a native Traefik installation inside LXC.

For most Proxmox users, the best default is Traefik in Docker inside a small dedicated virtual machine. It provides straightforward Docker integration, stronger isolation and simpler troubleshooting. A native LXC installation can be more efficient, but it requires more manual configuration. Docker inside LXC works, although it adds complexity that many environments do not need.

Why Run Traefik on Proxmox?

Traefik receives requests for internal applications and forwards them to the correct service. It can provide domain based routing, HTTPS certificates, redirects, authentication middleware and load balancing.

A single Traefik instance can route traffic to applications running in multiple Proxmox virtual machines, LXC containers, Docker hosts and physical servers. The destination only needs to be reachable across the network.

Traefik is especially effective with Docker because its Docker provider can discover containers and build routing rules from labels. When a labelled application starts, Traefik can automatically create its route. When the application is removed, the route disappears. citeturn907813search3turn907813search7

The server hosting Traefik becomes an important infrastructure component. If it stops working, applications behind it may remain operational but users will no longer be able to reach them through their normal domain names.

That makes isolation, backup and recovery more important than saving a small amount of memory.

Should You Run Traefik in Docker?

Docker is the most convenient deployment method when Traefik will proxy other Docker applications.

Traefik provides an official Docker image and documents Docker as a primary installation method. A basic deployment can be defined in Docker Compose, including ports, networks, configuration files, certificate storage and access to the Docker provider. citeturn907813search7turn907813search25

Docker Compose also makes the installation portable. The Compose file can be stored in version control, copied to a replacement server and used to recreate the Traefik container.

Application routes can be placed in Docker labels alongside each service. This keeps the application and its routing requirements together. An Immich deployment, for example, can declare its domain, internal port and HTTPS settings in the same Compose project.

The main concern is Docker API access. Traefik commonly reads container information through the Docker socket. Traefik’s documentation warns that unrestricted Docker API access is a security concern because compromising Traefik could expose the underlying Docker host. Docker also describes the Docker daemon as a sensitive attack surface that should only be controlled by trusted users. citeturn907813search13turn907813search4

Mounting the socket as read only limits ordinary file operations but does not remove every API related risk. A stronger design can use a restricted socket proxy or a protected remote Docker endpoint.

Docker is therefore an excellent packaging method, but the Docker host still needs an appropriate isolation boundary.

Should Docker Run Inside a Proxmox VM?

Running Docker and Traefik inside a dedicated virtual machine is the safest general recommendation.

Proxmox virtual machines use KVM and provide a separate guest kernel. LXC containers share the Proxmox host kernel. This means a virtual machine creates a stronger boundary between the internet facing reverse proxy and the Proxmox host. citeturn907813search0turn907813search39

Proxmox documentation has historically recommended running application container platforms such as Docker inside a QEMU virtual machine. This provides a complete kernel environment and avoids the additional nesting requirements involved when Docker operates inside LXC. citeturn907813search22turn907813search29

A Traefik VM does not need many resources. A modest Linux guest with limited processor capacity and memory can handle many homelab or small business services, although traffic volume, access logs and middleware will affect the final requirements.

The virtual machine can have a reserved IP address and direct access to ports 80 and 443. Docker Compose can then run Traefik and any supporting tools inside it.

A VM is also easy to move between Proxmox nodes. It can participate in normal Proxmox migration, backup and high availability workflows. Recovery can involve restoring the complete guest or rebuilding it from the saved Compose and configuration files.

The disadvantage is overhead. A virtual machine runs a full guest operating system and uses more memory and storage than a minimal LXC container.

In practice, that overhead is usually small compared with the isolation and operational simplicity it provides.

Should You Install Traefik Directly in LXC?

Installing the Traefik binary directly inside an LXC container is the lightest clean deployment.

Proxmox uses LXC for operating system containers. An LXC guest shares the host kernel while maintaining its own filesystem, processes, network configuration and resource limits. Proxmox supports unprivileged containers, where root inside the container is mapped to an unprivileged user outside it. citeturn907813search1turn907813search6

A native LXC deployment avoids Docker completely. You can download the Traefik binary, create a system service and store the static and dynamic configuration inside the container.

This approach uses few resources and reduces the number of software layers. It can work well when Traefik routes mainly to external virtual machines, LXC applications or physical servers.

The tradeoff is manual management. You must handle binary updates, service files, permissions, certificate storage and configuration paths yourself. You also lose automatic Docker discovery unless Traefik connects remotely to a separate Docker host.

Native LXC is a sensible option for experienced Linux administrators who want a small, dedicated proxy appliance. It is less convenient for teams that want Docker Compose based deployment and automatic container labels.

Should You Run Docker Inside LXC?

Docker can run inside LXC, but it is the most complicated of the three common designs.

Proxmox provides container features such as nesting and keyctl that may be required for Docker workloads. Proxmox documentation notes that enabling nesting exposes some host process and system information to the container. Its current configuration documentation also states that keyctl is required to use Docker inside an unprivileged container. citeturn907813search23turn907813search18

Docker inside LXC can be attractive because it uses fewer resources than a full virtual machine. Many homelab users run it successfully.

Problems can appear around filesystem drivers, user mappings, kernel features, backup behaviour and security permissions. Troubleshooting may require understanding Docker, LXC and the Proxmox host at the same time.

This arrangement also places a container platform inside another container boundary. That can be acceptable in a lab, but it provides fewer isolation benefits than a dedicated VM while remaining more complicated than a native LXC installation.

For an internet facing service, the small efficiency gain rarely justifies the additional operational complexity.

Should Traefik Run on the Proxmox Host?

Traefik should not normally be installed directly on the Proxmox host.

The Proxmox host is responsible for virtualization, storage, networking and cluster management. Adding an internet facing reverse proxy introduces packages, ports, configuration files and update requirements that are unrelated to the hypervisor.

A proxy configuration mistake could also interfere with the Proxmox management interface or expose services that should remain private.

Keeping Traefik inside a guest makes the design easier to document, migrate, back up and replace. It also reduces the consequences of an application level compromise.

The Proxmox host should remain focused on running and protecting workloads.

Which Deployment Is Best?

Choose Docker inside a dedicated virtual machine when you want the strongest balance of simplicity, isolation and Docker integration. This is the best default for most production, small business and serious homelab environments.

Choose native Traefik inside an unprivileged LXC container when resource efficiency matters and you are comfortable managing the binary and service configuration manually.

Choose Docker inside LXC only when you understand Proxmox nesting, container permissions and the security tradeoffs. It can work, but it is rarely the simplest design.

Whichever option you select, place Traefik on a trusted network, expose only the required ports and restrict access to its dashboard. Store configuration in version control, back up certificate data and test recovery before relying on the proxy for important services.

For most Proxmox deployments, a small Linux VM running Docker Compose and Traefik provides the cleanest long term solution. It uses slightly more resources, but it is easier to secure, move, rebuild and troubleshoot.