The idea sounds contradictory: take a full virtualization platform designed to run directly on hardware and stuff it inside a Docker container. Yet a community project called Dockermox does exactly that, packaging Proxmox VE into a privileged Docker image. The result is a surprisingly functional lab environment that boots a complete Proxmox web interface and can host virtual machines and LXC containers – but the compromises required make it strictly a tinkering tool, not anything you should trust for real workloads.

This article distills the how-to from both the Dockermox maintainers and a hands-on test by an XDA Developers writer, cross-references the necessary workarounds against Proxmox documentation, and provides a practical security and stability analysis. The bottom line: Dockermox is a clever hack for learning, demos, and throwaway testing, but bare-metal or full VM installs remain the only safe paths for production.

What Is Dockermox?

Dockermox is a community-maintained Docker image (rtedpro-cpu/dockermox) that bundles a Debian-based installation of Proxmox VE. It is not an official Proxmox project and receives no support from Proxmox Server Solutions. The repository provides a one-liner docker run command, helper scripts for network bridges, and explicit notes about limitations.

The image runs Proxmox’s management stack – including the web UI on port 8006 – inside a container. To work properly, the container demands elevated privileges on the host. The canonical command is intentionally permissive:

docker run -itd --name proxmoxve --hostname pve -p 8006:8006 --privileged rtedpro/proxmox:<tag>

The <tag> varies; in the XDA test, for instance, 8.4.9 was used. The repository’s README warns that vmbr0 (the default Proxmox bridge) is not created automatically. Users must manually set up networking and handle several Proxmox-in-container quirks.

How Dockermox Works Under the Hood

Running a hypervisor inside a container conflicts with Docker’s security model. Proxmox expects low-level kernel access: it needs /dev/fuse for file system operations, wants /dev/kvm for nested virtualization, and requires the ability to manage cgroups, namespaces, and devices. The --privileged flag gives the container almost unrestricted host access, essentially turning it into a lightweight “host-in-a-container” rather than an isolated microservice.

Because of this, Dockermox sidesteps many container security benefits. The container’s root user can interact with host devices and kernel modules, which is why the setup is considered risky. The community image also ships with a pre‑configured root/root password pair – a fact that demands immediate change if you plan to reuse the container beyond a test session.

Step‑by‑Step: Setting Up Dockermox

Here is a distilled reproduction of the steps documented in the Dockermox repo and confirmed in the XDA hands‑on article. Use these as a lab blueprint, not a production recipe.

Prerequisites

  • Docker Engine installed and functional.
  • Kernel modules: /dev/fuse must be present. If you need KVM‑based guests, /dev/kvm must be available and virtualization enabled in the BIOS.
  • Familiarity with Docker basics and Linux networking.

1. Pull and Start the Image 

docker run -itd --name proxmoxve --hostname pve -p 8006:8006 --privileged rtedpro/proxmox:8.4.9

Adjust the tag to the latest available from the Dockermox repository. The container exposes the Proxmox web UI on host port 8006.

2. Verify Device Nodes

Inside the container (or on the host), check that /dev/fuse and optionally /dev/kvm exist. If they are missing, load the required kernel modules on the host with modprobe.

3. Provide a Network Bridge

Dockermox lacks a default bridge. Create a Docker network and connect the container:

sudo docker network create --driver bridge --subnet=192.168.1.0/24 eth2
sudo docker network connect eth2 proxmoxve

Then, inside the Proxmox web UI, create a Linux bridge (e.g., vmbr0) that uses the Docker-provided network interface. Without this step, guest VMs and containers will lack connectivity.

4. Log Into the Web UI

Browse to https://localhost:8006. The default credentials are root / root. Change the password immediately if the container will persist.

5. Create and Test Virtual Machines

VMs can be spun up using the standard Proxmox wizard. QEMU/KVM runs inside the containerized environment, so performance is acceptable for light workloads and learning tasks. The XDA author reported running three VMs concurrently without crashes. However, disk and I/O performance lags behind bare‑metal, and hardware passthrough (GPU, PCIe) is essentially impossible unless the host explicitly exposes those devices and supports nested passthrough patterns.

6. Tackle LXC Hurdles

LXCs are the trickiest part. Two well-documented issues arise, and both require configuration changes that erode security.

LXCs: The Awkward Child of Containerized Proxmox

LXC containers run inside the Proxmox instance, which is itself a container. This nesting causes two predictable problems.

lxcfs.service Is Disabled by ConditionVirtualization

Systemd detects that it is running inside a container and disables lxcfs.service. The fix, documented in both the Dockermox notes and community threads, is to edit the service file:

vi /lib/systemd/system/lxcfs.service

Comment out the line:

ConditionVirtualization=…

systemctl daemon-reload systemctl restart lxcfs

This allows lxcfs to start, providing the necessary virtual file systems for LXC guests.

AppArmor Blocks LXC Operations

Modern Linux distributions enforce AppArmor on containers. LXC inside Proxmox often fails because AppArmor denies needed capabilities. The Proxmox documentation suggests setting lxc.apparmor.profile = unconfined in the LXC configuration file (/var/lib/lxc/<CTID>/config). Doing so disables AppArmor isolation for that container entirely. You can also relax AppArmor at the Docker level by adding --security-opt apparmor:unconfined when starting the Dockermox container, but this weakens host‑level protection.

Once these edits are made, LXCs start and run with decent performance. The XDA writer noted that LXCs still had to be booted manually via lxc-start -n <containerID> each time, and that the overall experience was smooth but clearly not beginner‑friendly.

Virtual Machine Performance: Surprisingly Competent

Community reports and hands‑on tests agree: VMs inside Dockermox are functional. Simple Linux guests boot and run with acceptable responsiveness for testing and light duties. The XDA author’s three‑VM test demonstrated that the containerized hypervisor can handle concurrent workloads without catastrophic failure.

Yet the limitations are real:

  • No hardware passthrough (GPUs, USB controllers) unless you explicitly map host devices and the host supports nesting with IOMMU – a fragile setup.
  • Manual network configuration: guests typically need static IPs; DHCP can be set up, but the absence of a proper bridge by default adds friction.
  • Performance is consistently worse than a native Proxmox install. Expect slower disk I/O and higher latency.

These shortcomings make Dockermox unsuitable for any workload that demands reliability or consistent performance.

Security, Stability, and Upgrade Concerns

The convenience of a one‑command Proxmox lab comes at a steep cost in security and maintainability.

Elevated Privileges Expose the Host

The --privileged flag strips away the container’s isolation boundaries. A compromise of the Proxmox stack inside the container could potentially threaten the host. The XDA test and the Dockermox documentation both acknowledge this risk. In a production context, granting a container such broad access is unacceptable.

Weakened Security Profiles

Disabling AppArmor for LXCs or for the entire Dockermox container eliminates a key defense layer. The Proxmox wiki explicitly warns that setting lxc.apparmor.profile = unconfined is “not recommended for production.” Combined with the container’s own privileged status, the attack surface is significantly larger than a standard Proxmox deployment.

Upgrades Are Fragile

Proxmox expects a full Debian host layout. Inside a container, package upgrades may fail or leave the system in an inconsistent state. The Dockermox repository cautions against automatic updates, and community experience confirms that kernel‑dependent changes or major version upgrades can break the container entirely.

Completely Unsupported

Proxmox Server Solutions does not test or endorse running PVE inside a Docker container. If you encounter an issue, you are on your own. This is a DIY project maintained by a single developer (rtedpro‑cpu) whose image tags may change, and whose availability is not guaranteed.

When Does Dockermox Make Sense?

Despite the warnings, there are legitimate short‑term use cases:

  • Learning the Proxmox UI: Get hands‑on with storage configuration, VM creation, and cluster concepts without dedicating hardware.
  • Testing configuration changes: Validate scripts, backup routines, or new Proxmox features in an isolated sandbox before applying them to a production node.
  • Workshop and demo environments: Spin up a transient, shareable Proxmox node for training sessions or presentations.
  • Lightweight self‑hosing experiments: If you accept the security and reliability trade‑offs, you can run low‑risk services in a persistent Dockermox instance – but only for experimentation.

For any permanent or production‑bound workload, the consensus from both community forums and official guidance remains clear: install Proxmox on bare metal or inside a full VM with nested virtualization enabled. These methods provide the full feature set, vendor support, and security that Dockermox cannot offer.

Troubleshooting Checklist

  • Missing /dev/fuse or /dev/kvm: Run modprobe fuse or modprobe kvm on the host, then restart the container.
  • LXC fails to start with “ConditionVirtualization” error: Edit /lib/systemd/system/lxcfs.service, comment the ConditionVirtualization line, reload systemd, and restart lxcfs.
  • AppArmor denials: Add lxc.apparmor.profile = unconfined to the LXC config, or start the Dockermox container with --security-opt apparmor:unconfined.
  • Networking broken: Create a Docker bridge (e.g., eth2) and connect the container, then define a corresponding Linux bridge in the Proxmox GUI.
  • Upgrade gone wrong: Before attempting any apt upgrade inside the container, back up critical VM configs and data. Rollbacks are often impossible.

Alternative Approaches

If your goal is to learn Proxmox without a dedicated machine, safer alternatives exist:

  1. Install Proxmox on bare metal – even an old desktop PC will give you the genuine experience and full performance.
  2. Run Proxmox in a full VM (using VirtualBox, VMware Workstation, or another Proxmox node) with nested virtualization turned on. This isolates the hypervisor far better than a privileged container.
  3. Use cloud‑based labs or Proxmox’s own live demo for a zero‑footprint preview.

For Docker‑centric workflows, it is generally better to run Docker on a dedicated VM hosted by Proxmox, not the other way around. The Proxmox community strongly advises against installing Docker directly on the PVE host; the inverse – Proxmox inside Docker – is an even larger deviation from best practices.

Quick‑Reference Commands and Edits

Start Dockermox:

docker run -itd --name proxmoxve --hostname pve -p 8006:8006 --privileged rtedpro/proxmox:8.4.9

Create a Docker bridge and attach the container:

sudo docker network create --driver bridge --subnet=192.168.1.0/24 eth2
sudo docker network connect eth2 proxmoxve

Fix lxcfs if disabled:

  • Edit /lib/systemd/system/lxcfs.service and comment ConditionVirtualization
  • Run systemctl daemon-reload && systemctl restart lxcfs

Disable AppArmor for an LXC:

  • Add lxc.apparmor.profile = unconfined to /var/lib/lxc/<CTID>/config (or /etc/pve/lxc/<CTID>.conf)

Start an LXC manually (if auto‑start fails):

lxc-start -n <containerID>

Caution: All of the above reduce security boundaries. Only apply on isolated test hosts.

The Verdict: Ingenious but Unsafe for Real Work

Dockermox is a testament to Docker’s flexibility and the Proxmox community’s creativity. In minutes, you can have a working Proxmox web UI, spin up test VMs, and explore the platform’s capabilities – all without dedicating a whole machine. But that speed comes at the price of shattered container isolation, fragile networking, and unsupported, hard‑to‑maintain internals.

If you accept those risks for a learning lab, the experiment has value. For anything that stores important data, faces the internet, or must run 24/7, the only responsible choice is a proper Proxmox installation. Use Dockermox to scratch a curiosity itch, then move on to the real thing.