Installing a chart yourself leaves you owning the parts nobody demos: where the values live, who notices when the upstream chart moves, how the tool gets a login. Add-ons hand that to the component already holding cluster credentials and already knowing who your operators are, since an add-on runs beside Portainer in the same cluster and Portainer-Run reuses Portainer's own authentication and access control [4][7]. For a two-person platform team that is real work removed. It is also a dependency swap: the tool's upgrade cadence becomes the catalog's cadence, and Portainer says the catalog is how it intends to extend the product from here [8].
That makes the size of the catalog the number worth quoting, and it is one [14]. Portainer-Run is the first add-on and the only one named in the release [7], so anyone reading Add-ons as a general route to installing cluster tooling from a UI is reading a roadmap rather than a feature.
The awkward fit is with the rest of the same release. GitOps gained a Workflows dashboard covering every Docker, Edge and Kubernetes workload deployed from a Git repository, plus a Sources view for the connected Git sources themselves [9], and workflow creation is now a single guided flow that ends with the stack created and deploying, batching rollouts and pausing or rolling back on failure [10]. That is a push toward Git as the record of what is running. Add-ons are installed by clicking. A team that keeps a declarative record will have cluster tooling sitting outside it, which is manageable for one tool and becomes an exception list after that.
There is a governance answer in the release, though it points elsewhere. The new Banner and Custom Change Confirmation policy paints a group of environments in a color of your choosing and can force a confirmation prompt before any change lands there, extending the Fleet Governance Policies line that began in 2.39 LTS [11][12]. It reduces careless changes made by humans in the console. It does not change where Portainer-Run's workloads are scheduled, which is the cluster running Portainer [4].
For cautious shops, the thing that changed is eligibility. The add-on mechanism has already been through an STS cycle and now arrives with the hardening and long-term support commitment Portainer attaches to LTS builds [2][15]. The post also opens a section on new Kubernetes Security Policies, which the copy supplied to us cuts off mid-sentence [13].
