Proxmox 9.1 Can 'Run Docker Containers'… but Not the Way You Think

On the morning the feature landed, a cluster admin somewhere probably leaned back in his chair, squinted at the Proxmox 9.1 changelog, and muttered, "No way they actually did it." For years, running Docker on Proxmox in any "native" capacity has been a kind of homelab daydream. Sure, people wrapped Docker inside LXCs, others tucked it inside lightweight VMs, and a few adventurous souls pretended everything was fine while ignoring the occasional kernel complaint. Everyone had their hack. Everyone had their scars. But Proxmox 9.1 rolled out a new trick: OCI-based containers that look like lightweight LXC guests spun directly from Docker images. Overnight, a corner of the infrastructure world lit up with posts, comments, and YouTube explainers—some excited, some confused, and some warning others to please, for the love of uptime, take a breath before diving in. And the best way to understand how this feature really landed is by listening to the people who hammered on it during those first few hours. The takeaway? Proxmox technically gave users a way to "run Docker containers," but what they actually got is a very Proxmox-shaped hybrid—clever, promising, a little strange, and absolutely not a Docker replacement. Not yet, anyway. ## The Initial Reaction: Hopeful, but Cautious One early response nailed the vibe: "I guess I won't replace my VMs just yet, but I like the idea and the direction." A lot of folks run containers using Portainer inside a dedicated VM because it gives them clean isolation, namespacing, and familiar Docker semantics. Those users aren't rushing to tear down that setup overnight. Another admitted they liked Docker's namespace handling far too much to give it up. For them, stacking containers with neat network boundaries and ports grouped under a single IP wasn't just a convenience—it's how their entire self-hosted design works. And on that note, multiple people were disappointed that Proxmox's OCI containers behave like LXCs: each gets its own IP. That's the whole deal. Want a dozen services hanging off one IP with different ports? Too bad. A reverse proxy could help, but that wasn't the point. Still, the crowd who struggles with limited resources saw real promise. Running full VMs for tiny services feels wasteful, and LXCs hosting Docker can get weird depending on kernel features. Having Proxmox deploy a container-like workload without needing Docker, Podman, or an OS layer of any kind—that's massive for small machines. But then came the question that set the tone for the rest of the thread: "What's the actual use case?" Turns out people had plenty of answers. And plenty of caveats. ## The First Wave of Confusion: Wait, How Does This Actually Work? The most common misconception that spread like a breeze through the thread? The idea that Proxmox was running "Docker inside containers." Several people tried to correct that—some gently, some less so. Multiple commenters emphasized the same core point: Proxmox converts an OCI image into an LXC. That means the container contents from the image become a lightweight filesystem for a privileged LXC guest. There is no Docker engine. No Podman. No Docker daemon. You're not calling docker ps. You're not watching the Docker socket. You're not doing multi-container stacks. It's closer to: 1. Download a Docker image 2. Unpack its filesystem 3. Use that as the root FS of an LXC 4. Start it as a system service Which is clever, but also invites trouble if the image expects behavior only a Docker runtime provides—things like ephemeral resets, consistent mounts, networking assumptions, or overlay filesystem behavior. Put bluntly: Docker images were not built to be full root filesystems. And that can bite you. That's why one commenter simply wrote: "Most docker containers don't work for me. That's why it's a technology review." Yep. There it is. ## The Updates Problem Almost everyone agreed on the biggest headache: updating OCI containers on Proxmox is awkward right now. If you rebuild an OCI container in Docker, you just pull and restart. The runtime sweeps in the new layers. The container's ephemeral design helps you avoid worrying about what happened to the root FS underneath. On Proxmox? Your OCI-derived LXC behaves like any other LXC: it has state. Unless you're careful with mounted storage, updating means: 1. Rebuilding a new instance 2. Re-attaching mounts 3. Copying config 4. Replacing the old container It's not elegant. One YouTuber recommended that approach for now, and honestly, that's how things have to be until Proxmox adds a true update workflow. One user summed it up nicely: "Maybe I'll use SMB instead of volumes—if that even works, idk." That's where we are. ## Mounting, Networking, and the Weird Edges Several users bumped into early limitations: ### Shared mounts aren't obvious Someone tried mounting SMB shares and hit a wall. Others pointed out LXCs do support local bind mounts—just not in a way that imitates docker volume behavior cleanly. ### Networking behaves like LXC, not Docker If you're used to Docker's "one IP, many ports" model, the switch to "every container has a full IP stack" feels harsh. Proxmox automatically assigns its OCI containers network configs like LXCs, including MAC addresses, bridges, and firewall rules. A reverse proxy fixes this, but that's extra plumbing people weren't expecting. ### No multi-container setups Compose? Stacks? Immich fans asked about it. The answer was consistent: nope, not right now. No Docker daemon means no orchestration layer. Every OCI container is a single runtime environment: one app, one root FS, one start command. Great for small services. Terrible for anything requiring complex orchestration. ## The YouTube Chaos: People Trying to Explain… and Arguing About It Naturally, the moment the feature dropped, YouTubers rushed to cover it. Some folks liked Techno Tim's overview. Others said the video caused confusion by implying containers were running inside containers. He later clarified, but the damage was done—many viewers walked away with the wrong mental model. Others pointed people to a more technical breakdown, insisting it explained the architecture better. That was the pattern across the thread: every excited explanation was matched by someone running in behind them with a fire extinguisher, shouting "NO! That's not how it works!" That's what happens when a feature is early, unusual, and poorly documented. ## Practical Use Cases: Where OCI Containers Actually Shine Beyond the debate, several real-world use cases emerged. ### 1. Replacing lightweight LXCs meant for single apps Plenty of folks run apps in LXCs even though those apps were really built for containers. Think AdGuard, Unifi, small network tools, or service managers. But LXCs still require patching, package management, and OS upkeep. One person summed it up: "I don't want to cosplay as a 2000s sysadmin dealing with dependencies every update." With OCI containers, you can run an app using its Docker image—without using Docker—while skipping the OS maintenance tax. ### 2. Resource-constrained hardware People running Proxmox on NUCs, mini PCs, or small home servers sometimes can't spare the RAM overhead of a VM just to hold a Docker daemon. OCI containers give them barebones overhead with service-specific isolation. ### 3. Cluster networking use cases One user explained they have a dedicated SDN network isolated from their main LAN. They run a VM purely to host a reverse proxy. That's overkill. They tried Docker inside an LXC, but couldn't get it working cleanly. An OCI container, built from the Traefik image, solves the exact problem with minimal overhead. That's a niche use case, sure. But these are homelabbers. Everyone's use case is niche. ## The Dealbreakers: Where It Falls Apart Today Even the optimists admitted some pain points. ### 1. Docker semantics just aren't there People who track updates via the Docker socket? Sorry. The socket doesn't exist. Projects that expect a Docker environment? Nope. Tools that rely on Docker events? Not happening. ### 2. Many container images simply don't run The more an image depends on Docker runtime features rather than just filesystem contents, the more likely it is to break. ### 3. Stateful LXCs behave differently than ephemeral Docker containers Someone asked: "Wait, does the filesystem reset like Docker?" The answer: no. Anything that writes to the root FS stays there unless you rebuild or clean manually. That's not necessarily bad, but it's fundamentally different behavior. ### 4. Multi-container workflows are off the table Compose-based apps—Immich, Home Assistant + add-ons, databases paired with frontends—are not going to be clean to manage. ## The LXC Crowd: "We've Been Doing This for Years" Some readers were almost amused. People have run Docker inside LXCs for a long time. It works reasonably well, especially for non-critical homelab setups. A few mentioned small patches needed after certain updates, but overall the setup has been stable. So to them, Proxmox's OCI containers feel like a sideways version of what they already do—nice, but not a revolution. They want true Docker or true Podman integrated at the host level. That's not what this feature is. ## Where This Feature Actually Stands Taken together, the discussion paints a picture of a feature that's: - New - Weird - Powerful - Misunderstood - Not production-ready - And definitely not "Docker on Proxmox" Not yet. What Proxmox actually built is a way to take OCI images—one of the most widespread packaging formats in the tech world—and boot them as lightweight system containers without installing a container runtime. It's clever. It's useful. And it's absolutely going to evolve. For now, it sits in a curious middle lane: too powerful to ignore, too unfinished to rely on, and too confusing to explain without starting an argument. ## The Future: When Proxmox Might Truly Replace Docker Hosts Will this feature eventually grow into a real Docker replacement for homelab users? Maybe. But based on the conversation, it needs: - Real update workflows - Better image compatibility layers - Multi-container orchestration - Cleaner networking options - More stable filesystem behavior - Better documentation - And less confusion in general If Proxmox can pull that off, it would become a one-stop shop for virtualization, lightweight app hosting, and container workloads—something even TrueNAS is still figuring out. For now, it's experimental. It's promising. And honestly? It's pretty fun to watch unfold. ## Final Word Proxmox 9.1 didn't make Docker obsolete. It didn't let you ditch your compose files. It didn't let you collapse your entire home stack into one hypervisor feature. What it did was open a door—a doorway into a future where Proxmox can run containerized apps without heavyweight runtimes or fragile hacks. A doorway where homelabbers can deploy small services quickly, skip OS maintenance, and avoid VMs for single-app workloads. It's early. It's messy. It's misunderstood. But it's something new. And in a world where everyone has an opinion about how containers should work, Proxmox just made the debate even more interesting.