OCI image support in Proxmox solves a problem I didn't have and ignores the one I do

When Proxmox VE 9.1 added support for OCI images, I immediately saw a chance to remove a layer from my home lab. Instead of creating a virtual machine, installing Docker, and then running containers inside that guest, I could apparently pull those same images straight into Proxmox. At least, that was how I read it at first. After spending some time with the feature, I found that Proxmox supports the image format, but not the Docker workflow I was hoping to replace. OCI image support is not the same as Docker Proxmox turns familiar images into something fundamentally different The terminology is what tripped me up first. Docker images generally use the OCI format, so seeing OCI support in Proxmox made the feature sound more familiar than it really was. I assumed I’d be getting something close to a built-in Docker host, only without the extra virtual machine. That assumption lasted until I started looking at what Proxmox was actually creating. When Proxmox pulls an OCI image, it uses that image as the basis for an LXC container. It isn’t launching the image through Docker Engine, and there isn’t a Docker container tucked away behind the Proxmox interface. The image becomes the root filesystem for a normal Proxmox-managed container. That one distinction explains most of the friction I ran into afterward. Proxmox’s OCI support imports an image as the basis for an LXC container. It doesn’t run Docker Engine, interpret a Compose file, or preserve the deployment workflow described in most Docker-focused documentation. Plan on translating the application’s storage, networking, environment variables, and update process into Proxmox’s container model. The OCI image is really just the raw material. Proxmox converts it into something that fits its own container system, complete with Proxmox networking, storage, resource controls, backups, and permissions. That’s useful, but it also means the result behaves like an LXC container rather than a Docker deployment. I wasn’t getting Docker support inside Proxmox so much as a new way to create an LXC. The surrounding Docker workflow is what I actually missed A container image alone does not replace Docker Compose Pulling an image has never been the difficult part of running most Docker services. The work is in everything wrapped around it, including environment variables, persistent volumes, port mappings, restart policies, dependencies, and networks. Docker Compose keeps all of that in one file, making it easy to see how the service was intended to run. Proxmox’s OCI support handles the image, but it leaves the rest of that work sitting in my lap. Proxmox can still provide most of those pieces. I can configure networking, mount storage, assign resources, and pass in environment variables. The irritation comes from having to translate instructions written for Docker into Proxmox’s LXC model. That’s fine for a small, self-contained application, but it gets old quickly once the original project includes a long Compose file and several interconnected services. The update process made the gap harder to ignore. With Docker, I’m used to pulling a newer image and recreating the container while leaving persistent data and most of the surrounding configuration alone. Proxmox’s OCI workflow doesn’t give me that same routine. I can create a new container from an updated image and reconnect everything, but that feels more like rebuilding than updating. Larger application stacks expose the missing pieces quickly My existing services depend on more than isolated containers A single, simple application is where this feature looks best. Give it an image, connect it to the network, add the storage it needs, and it may run without much complaint. The problem is that a lot of the applications I actually care about aren’t packaged that way. Even a fairly modest service can bring along a database, cache, helper process, or reverse proxy configuration. OCI support in Proxmox makes LXC more flexible, but it doesn’t remove the Docker layer I wanted to retire. Docker Compose handles those relationships in one place. It defines which services depend on one another, which private networks they share, which directories need to persist, and what each container should be called. With Proxmox, each OCI image becomes a separately managed LXC container. I’d have to recreate those relationships myself using Proxmox’s networking and storage tools. I could do that, and in some cases the result might be cleaner or better isolated. That still doesn’t make it a shortcut. At that point, I’m redesigning the application around Proxmox rather than deploying it as its documentation expects. Creating a small Docker virtual machine and using the original Compose file would usually take less effort and leave fewer details for me to remember later. Proxmox management still gives these containers real advantages Native backups and resource controls make a compelling case To be fair, copying Docker’s behavior may never have been the goal. Proxmox already has a mature container system, and OCI support gives that system access to a much larger pool of ready-made images. Those containers can use Proxmox’s existing backup tools, storage choices, CPU and memory limits, firewall rules, and cluster controls. For someone who already prefers managing services as individual LXCs, that’s a meaningful improvement. The lower overhead is appealing too. A lightweight service doesn’t necessarily need a complete virtual machine with its own kernel, reserved memory, operating system updates, and Docker installation. On a smaller Proxmox host, removing that extra guest can free up resources for the applications themselves. It also keeps the service visible directly in the Proxmox interface rather than hiding it inside another machine. There are workloads where I’d still use this. A small internal API, a stateless utility, or an application with limited storage needs could fit the model nicely. It becomes more attractive when I want Proxmox to treat that service as a first-class container with its own resource limits and backup schedule. I just had to stop judging the feature by the Docker-shaped idea I had attached to it. Those benefits still do not solve my deployment problem The feature improves LXC without simplifying my Docker workloads That’s where my opinion finally settled. I wasn’t looking for a larger collection of LXC templates. I wanted a cleaner way to run the Docker applications I already use without maintaining a separate Docker host. Proxmox removes some of that infrastructure, but it gives the work back as translation, manual setup, and a less familiar update process. That trade is reasonable when the application is simple. Once persistent data, multiple services, image refreshes, and Docker-specific instructions enter the picture, the convenience thins out fast. I also have to remember that an image built and tested for Docker isn’t automatically guaranteed to behave the same way after Proxmox turns it into an LXC. Being able to download the image is only the first hurdle. A dedicated Docker virtual machine is less elegant, and I still don’t love the extra layer. It does have the advantage of being boring and predictable. The application’s documentation works as written, Compose stays available, updates follow the expected process, and the whole stack can move to another Docker host without being rebuilt around Proxmox. For most of my services, that predictability is worth more than shaving off one guest operating system. OCI support is useful, but it is not Docker support Proxmox’s OCI support is still a worthwhile addition. It opens the door to application images that would otherwise require more manual preparation, and it lets those applications sit directly under Proxmox’s storage, networking, backup, and resource controls. That makes it more than a checkbox feature, especially for people who already build around LXC containers. It just doesn’t replace Docker in the way the announcement initially made me hope it would. For my home lab, I’m still keeping Docker in a dedicated virtual machine and letting each platform handle what it already does well. Proxmox manages the host, hardware, virtual machines, and backups, while Docker manages application images and multi-container stacks. OCI support may become easier to deploy and update over time, which would make me revisit it. Right now, it makes LXC more flexible, but it doesn’t remove the Docker layer I wanted to retire.