Proxmox VE containers from OCI images

The main difference is what the container is expected to be. An LXC system container on Proxmox VE behaves like a lightweight machine: it shares the host kernel, but it runs its own init system, services, users and package manager from the image. An application container built from an OCI image usually packages one process and its dependencies, and when that image changes, it is normally rebuilt and redeployed. Operators who expect to log in, run updates and manage services inside a container will find the system model familiar, but they must own the work that an application container pipeline would normally handle. Settle this difference first, because it drives the patching, dependency, isolation and image lifecycle decisions in the rest of this section.

Patching is where the difference shows first. A kernel fix applied to a Proxmox VE host applies to every container on that node, so the host maintenance window is also a container maintenance window, and a kernel change can affect containers that nobody has touched. Userspace packages inside each container are patched with that image's own package manager, which means a named team must own those updates after deployment. Kernel dependencies matter too. A workload that expects a kernel feature the host does not provide may fail to start, so confirm the host kernel version and the features your workloads need against the Proxmox VE 9.1 release documentation before you standardize on a base image.

Isolation is a design choice that you must make explicitly. LXC relies on kernel namespaces and control groups, so the boundary between two containers is narrower than the boundary between two virtual machines, which each have their own kernel. Decide whether each container will run unprivileged, which features such as nesting or device access it requests, and which of those settings your security team will accept. The same node may also run KVM guests, so a container compromise should be assessed against everything else hosted on that node, including the firewall rules and access controls described elsewhere in this series.

Image handling is the area where you should verify the most before writing a design. Pulling an OCI image, storing the resulting root filesystem or template on a Proxmox VE storage backend, and updating a container from a newer image are behaviors that can differ between releases. Before you write a runbook, confirm in the Proxmox VE 9.1 documentation, released on November 19, 2025, which registries images can be pulled from, where the filesystem is stored, whether an update re-pulls and recreates the container or changes it in place, and how old images and templates are removed. Test each of those steps on a non-production cluster that uses the repository your organization has chosen before any production workload depends on them.

Kubernetes on Proxmox VMs is still the right choice when you are running a platform rather than a single service. Multi-service application estates, where many teams deploy independently and services need scheduling, rolling updates and replica management across nodes, fit Kubernetes better than a set of system containers. The same applies when your engineers already work with standard Kubernetes APIs and tooling, such as Helm, GitOps controllers and admission policies, and you want that knowledge to carry over without retraining. Proxmox VE 9.1 can create LXC system containers from OCI images, but that path does not provide a cluster-wide scheduler or the API surface your tooling targets. Before you commit, list the services that would run on the platform and count how many need those capabilities.

Portability is the second reason. Kubernetes is open source under the Apache 2.0 license, and the CNCF Certified Kubernetes conformance program checks that distributions support the required APIs. The CNCF page reports over 90 certified offerings, which gives you options if you later run workloads in a public cloud or another data center. Portability depends on discipline, though. Confirm which Kubernetes minor version and which add-ons, storage classes and load balancer integrations each target environment supports, and keep those choices in version-controlled manifests so the same workload can be redeployed elsewhere.

Kubernetes also carries an operating cost that you must staff. The kubeadm high availability guide describes a control plane of at least three nodes with a TCP load balancer in front of kube-apiserver on port 6443. etcd should run with an odd number of members, and the Kubernetes documentation recommends five members in production. You need a tested etcd backup plan using etcdctl snapshot save, with restores performed through etcdutl. Upgrades must move kube-apiserver one minor version at a time, before the controller manager, scheduler and kubelets. Kubelets may be up to three minor versions older than kube-apiserver. Ask whether your team can rehearse these steps on a schedule before go-live.

Lifecycle timing belongs in the decision as well. The Kubernetes project maintains the three most recent minor releases. As of September 2026, these were 1.37 (end of life October 28, 2027), 1.36 (June 28, 2027) and 1.35 (February 28, 2027), according to the Kubernetes releases page. Releases arrive about three times a year. Budget recurring upgrade work into the platform plan, and confirm the current release table on kubernetes.io before you pick a starting version. Security also needs an explicit owner. Kubernetes Secrets are stored unencrypted in etcd by default, so you must configure encryption at rest, restrict list and watch access with least-privilege RBAC, or use an external store through the Secrets Store CSI Driver.

Decision rule: choose Kubernetes on Proxmox VMs when all three conditions hold: you run several services that need scheduling and scaling, your teams need the Kubernetes API and its ecosystem, and you can staff control plane operations, etcd backups, upgrades and secret encryption on the release cadence above. If only one or two of those hold, keep the workload on Proxmox VE as a VM or LXC container and revisit the decision when the service count grows.

Cost for this work comes from three places: the Proxmox VE subscription (if you buy one), the DeployOpen implementation scope, and your own internal time and infrastructure. Proxmox VE is licensed under the GNU Affero General Public License, version 3, and the software can be used without a subscription. Paid subscriptions are priced per CPU socket per year. The Proxmox VE pricing page lists Community at 120 euros, Basic at 370 euros, Standard at 550 euros and Premium at 1,100 euros. All tiers include the same software features. They differ in support tickets, response times and access to the enterprise repository, which Proxmox recommends for production. Confirm current prices on the pricing page and confirm with Proxmox how many subscription keys your node count requires.

The subscription is a recurring cost that renews each year for each socket it covers. The implementation is largely one-time: design, build of the image pipeline, testing and handover documentation. Ongoing costs appear later, in the form of image rebuilds, Proxmox VE upgrades, security patching and support, which can be bought as a retainer. When you request a quote, ask which of these items are included in the fixed scope, which are optional, and which recur. Ask also whether the quote assumes a particular subscription tier, because the tier you choose changes both your support path and your repository access for production nodes.

The largest effort driver is the number of images. Each image needs its own base, dependency set, configuration, update cycle and test run, so the effort grows with every image and every update you expect to ship. Storage design is the second driver. Container root filesystems can sit on local ZFS, LVM or directory storage, or on network storage such as Ceph RBD or NFS, and that choice determines how snapshots, backups, replication and failover behave. Identity integration is the third. Deciding who may build, pull and start containers means connecting Proxmox VE to Linux PAM, LDAP, Active Directory or OpenID Connect realms, and deciding which second factors to require.

Backup and high availability requirements add the next layer of work. Proxmox VE high availability needs at least three cluster nodes, shared storage for guests, redundant hardware and watchdog-based fencing, so a failed node is reset before its guests restart elsewhere. If a container must survive node loss, that design and its failover testing become part of the scope. Backup design, including whether you use Proxmox Backup Server, sets the restore points you can offer. Testing and documentation close the scope: restore tests, failover drills and runbooks for rebuilding images. Ask each vendor to list these tests and documents as named deliverables, so you can compare quotes on the same basis.

DeployOpen does not publish a price list. A quote follows from a written scope, and most engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts. To get a comparable quote, prepare the number of images and their update frequency, the storage and network targets, the identity sources and second factors, the backup and availability targets, the test and documentation deliverables, and what your team will provide, such as hardware, access and a named owner for decisions. Ask whether the quote includes subscription purchase or assumes you already hold one.