Pin Portainer 2.45 LTS and Run This Post-Upgrade Checklist
A short, repeatable check that a solo operator can finish quickly, so a stable dashboard does not become a weekend incident.
Pin 2.45 LTS before you trust the dashboard
Your Portainer CE dashboard is up, but the image tag under it can still move. Portainer CE 2.45 LTS, available on 27 August 2026, is the stable tag to pin. It closed a critical Docker proxy authorization bypass where non-admin users could reach the Docker API directly by using unrecognised API version prefixes such as /v1.47.0/ or /v01.47/.
The 2.45 LTS line aggregates changes from the 2.40 through 2.44 STS releases. For a solo operator, that is the difference between a dashboard that changes under you and one that stays put until you decide otherwise. The same release moved to Go toolchain 1.26.6 and remediated CVE-2026-39821, a Critical 9.6 IDNA validation bypass affecting hostname-based access controls.
Portainer CE 2.45 LTS retains native Docker Compose v2 support and turns on HTTPS by default on port 9443. The post-upgrade check is short: pin the version, confirm the default HTTPS path, test the access boundary, and prove the deploy loop still works.
Run the checklist before the next deploy
Run it after the upgrade, not after the incident. Each item is a boundary you can test alone, and each one protects a different part of your margin. The test is to prove the parts you rely on are still where you left them, not to prove the dashboard is perfect. A failed item costs hours, and a short checklist is the cheaper way to find it before you make the next change.
Pin first, because an unpinned image is the easiest way to lose control of a self-hosted setup. A floating tag lets the dashboard change under you without a decision. Then check HTTPS, because the default path should be the path you actually use. Leave the default and check 9443. Change it and check the port you chose, then make sure the browser does not warn you.
Use a non-admin account for the access test, not the admin account, because the admin account is not the risk. The Compose checks are the basic test for the work you actually do. The dashboard must load a stack and deploy it; that is the core loop.
- Pin the image to 2.45 LTS in your Compose file, then restart the container.
- Open the dashboard over HTTPS on port 9443 and confirm the certificate is trusted.
- From a non-admin account, request the unrecognised API version prefixes and confirm the proxy denies them.
- Confirm Compose v2 still works by loading a small stack definition.
- Deploy the stack and confirm it reaches a healthy state.
- Record the closed CVEs, the Go toolchain move, and the LTS roll-up in your runbook.
When an item fails, stop. Do not add features, do not chase a newer tag, and do not open a terminal. Fix the boundary or roll back. A solo operator does not have a spare reviewer, so the checklist has to do the work of a reviewer.
The runbook note is part of the fix
A short runbook note is the difference between remembering why you pinned the version and guessing during a late-night check. It should hold the version, the date, the closed CVEs, and the rollback command in one place. Do not scatter the facts across chat messages, browser tabs, or memory. A note longer than a screen will not get read.
Name the access-control fix, the IDNA fix, and the LTS roll-up in the note. Keep the next upgrade out of the current runbook until you have a reason to change it. Keep the rollback command next to the pin, because the fastest recovery is the one you already wrote down before the next bad week.
