Portainer 2.45 LTS brings native Kubernetes RBAC and automated image cleanup to self-hosters
On August 27, 2026, Portainer moved its LTS line from 2.39.6 to 2.45.0, consolidating a year of short-term releases. The part that matters is not cosmetic: Pod Security Standards, native Kubernetes RBAC, and scheduled image pruning now live inside the UI.
August 27, 2026. Portainer shipped version 2.45.0, a Long Term Support release, sliding its stable line from 2.39.6 to 2.45.0. August 28, 2026. Synology and home NAS users picked up the updated Docker image. This is not just another release: 2.45 bundles Pod Security Standards policies, native Kubernetes RBAC, and automated image cleanup — enough to turn a container-management UI into a small self-hosted control plane.
The move follows a clear logic. Since switching to an LTS cadence, Portainer alternates Short Term Support releases that experiment, then folds everything into a tested, stabilized LTS. 2.45 is that consolidation point: everything accumulated since 2.39 lands at once, polished and supported long-term. For a homelab still running an aging 2.39, it is the moment to move — provided you know what you actually gain.
What “LTS” means in practice
An LTS is not a richer release than an STS; it is a more committed one. Features that trickled out across the STS releases — often flagged experimental — become stable, documented, and covered by a long support window. For a self-hoster, the difference is peace of mind: update once, and stop tracking intermediate releases for months.
2.45.0 succeeds 2.39.6 directly as the LTS reference. In between, several STS releases added real material: a reworked home page, a redesigned GitOps flow, alerting promoted to general availability, and — most importantly — a policy layer that pulls Portainer closer to a genuine multi-environment governance tool. The question is no longer “does Portainer do Kubernetes” but “does it do it with the same control as Rancher or Lens”. With 2.45, the answer is increasingly yes.
Kubernetes governance arrives in the UI
This is the heart of the release. Portainer 2.45 introduces several policy types that apply across one or many environments at once.
Pod Security Standards. The policy enforces the privileged, baseline, or restricted profiles per namespace, independently in enforce, audit, or warn mode. An admin can block privileged pods everywhere except a dedicated namespace, without writing a single line of YAML. It is the control homelabs skip most often — and the first one an auditor looks at.
Kubernetes NetworkPolicy. Define ingress and egress rules through presets or label-based rules, deployed as real native NetworkPolicy objects. The UI again translates clicks into Kubernetes.
Native Kubernetes RBAC. The deepest change: alongside the legacy homegrown privilege model, Portainer now offers a native Kubernetes permission model, where rights accumulate across cluster, team, and namespace roles. For a small company that wants Portainer aligned with its kubectl habits, this ends the risky translation between two permission systems.
Observability. A dedicated policy connects Portainer to a OneUptime instance, pulling logs and metrics straight into the namespace view.
The common thread: these four pieces make governance declarative and reusable, instead of scattering it across per-environment settings. For a self-hoster juggling a home cluster and a handful of VMs, that is the difference between “I run containers” and “I operate infrastructure”.
Centralized GitOps and image cleanup
Two more additions speak directly to modern self-hosting practice.
On one side, GitOps is finally centralized. A new Sources view groups Git connections instead of re-entering credentials per workflow. A guided assistant walks through workflow creation end to end — source, stack file, deployment targets, environment variables, registry, and a rollout strategy with parallel batches and automatic pause or rollback. A Workflows dashboard then unifies the health of everything deployed from Git, whether Docker, Edge, or Kubernetes.
On the other, image cleanup moves from manual chore to automatic policy. Prune dangling or unused images from the Images view, or schedule an automated cleanup by image age or storage thresholds — with the option to protect specific images. It is the kind of feature that never shines in a demo but stops a homelab waking up one morning with a full disk from forgotten build images.
The rest of the dashboard
The release rounds out the picture. The home page was refreshed, with environment groupings sortable by group, platform, or health — useful once you pass three hosts. Add-ons appear: installable tools deployed as Helm releases inside the cluster, with a first module, Portainer-Run. Alerting reaches general availability with multi-severity thresholds, new Kubernetes rules (etcd, API server, TLS certificate expiry, NotReady nodes), and Slack, email, or Teams notifications. GPU visibility shows up for equipped clusters. Finally, an official Terraform provider lets you manage environments, teams, and stacks as Infrastructure as Code.
Taken together, the trajectory is clear: Portainer stops being the “pretty Docker UI” and becomes the control plane of a self-hosted stack, from a single server to a small Kubernetes cluster.
A note on editions. 2.45 ships for both the free Community Edition (CE) and the paid Business Edition (BE). The governance policies at the center of this release — Pod Security Standards, NetworkPolicy, native RBAC, and the image cleanup policies — land in CE, which is what lets self-hosters stay on the free tier without losing the controls that matter. A few deeper registry and service-account automations remain BE-only. For a homelab the read is simple: the free tier just absorbed most of the serious governance surface it had been missing, and that is the real headline of 2.45.
Migrating from 2.39 without breaking anything
The jump from one LTS to the next is a documented path, not a silent click. Portainer recommends backing up the data volume (/data) before any upgrade, then re-pulling the Docker image. For a classic docker run install, the sequence is:
docker stop portainer
docker rm portainer
docker run -d -p 9443:9443 \
-v /var/run/docker.sock:/var/run/docker.sock \
-v portainer_data:/data \
--name portainer portainer/portainer-ce:2.45.0Teams on Docker Compose just change the image tag and run docker compose up -d. The watch-point is the newly created policies: they do not apply retroactively, so attach them explicitly to existing environments. And for those using the old Kubernetes privilege model, native RBAC is an additional option, not a forced replacement — both models coexist.
On the comparison front, 2.45 pulls Portainer closer to Rancher on Kubernetes governance while staying easier to pick up. Against Cockpit or Yacht, the gap widens sharply on policies and GitOps. The trade-off fits one sentence: a rich control plane that is easy to adopt, versus a complete but heavier-to-operate Kubernetes-native platform.
One practical caveat for the upgrade: 2.45 keeps the same LTS data model, so the 2.39 → 2.45 jump does not require re-provisioning environments or rebuilding stacks. The main behavioral change is additive — new policies sit dormant until you attach them — which makes this one of the lower-risk LTS hops Portainer has shipped, and an easy argument for finally getting off an aging 2.39.
Verdict
If you run a Kubernetes cluster, even a modest one, move to 2.45 LTS: native RBAC and Pod Security Standards close the governance gap that pushed you elsewhere, and the image-pruning policy fixes a recurring operational pain.
If you only run one or two Docker hosts with a handful of stacks, the update is still worth it for LTS stability, but half the features will not apply to you — take it for image cleanup and the home-page rework, not for Kubernetes.
If you are still on 2.39.6, plan the jump: it is LTS to LTS, the path is clean, and two years of intermediate features are worth a single update.