Portainer CE 2.0 – What to expect

With the announcement of the launch of Portainer CE 2.0 on the 31st August, I‘d like to provide additional context on our thinking behind this release, the value we hope it will bring, the target audience, and what you can expect to see from it, features-wise.

Portainer CE 2.0 includes a staggering number of enhancements (~150), as well as a few breaking changes. Before you upgrade, you need to understand the changes in order to decide if 2.0 is right for you.

We have purposely decided to release CE 2.0 as an entirely new image to ensure there are no auto-updaters (like watchtower) that will expose users to risks by automatically updating on release. The new image will be portainer/portainer-ce. The first tag will be :2.0 and we will also use :latest as a tag pointing to the latest release.

Portainer 1.24.x will continue as a separate code branch, released as portainer/portainer:latest, and will receive ongoing security updates until at least 1st Sept 2021. No new features will be added beyond what was available in 1.24.1.

For two reasons we have removed the concept of “extensions” from 2.0 completely. First, we have been criticized for having closed source features as part of the open source project, and so by removing them Portainer CE reverts back to being 100% open source. Second, we have learned that to be successful, extensions need to be delivered as part of a supported solution. Whilst extensions provided al-carte functionality, users really need (and indeed expect) support using them.

Moving forward, we will contain all of our proprietary functionality in a specific commercial version of Portainer called Portainer Business, which will come with full support. Existing extension customers should look out for specific communications about the transition.

As part of removing extensions, we have elected to roll basic oAUTH authentication support into CE, so now you can configure Portainer to authenticate users from an oAUTH source. Be aware, this is a very technical implementation, so you need to be competent with oAUTH before attempting it. The Business Edition will retain ‘click to configure’ simplicity for the most common oAUTH providers like Azure AD, GitHub, Google.

Off the back of our intention to remove the ability to disable Portainer internal authentication, we have added support for the Admin to set a custom “session timeout’. This setting defines how often users are forced to re-authenticate with their Portainer session; the default remains at 8 hours, but it can now be changed to up to 1 year. So, whilst we are not disabling authentication completely, we are trying to make the required authentication invisible for those that don’t care for it.

We’ve also changed the way we handle application templates. Previously we let admins/users customize the application template list, and we provided a rudimentary UX to add/remove applications to the template list. Moving forward, we have changed this behavior. Now, the list of application templates is published by Portainer, maintained and updated by Portainer, and users can’t change it. Admins can choose to unsubscribe from the list and instead provide their own centrally managed list, but it would be “consume only” from a user perspective.

In addition, we have elected to provide a feature called “custom templates” which is where Portainer users can create their own bespoke templates. Unlike previous capability, the new custom templates rely solely upon Stack/Compose files, so when you add a new template, you add it by pasting in (or uploading) a compose file and then annotating some detail around the file.  Through Portainer access control, users can choose to publish their custom templates for themselves, for their team, or for all users within their organization.

One other cool addition to the custom templates is the ability to create one from a running stack...  simply open a stack and click on the button “create template from stack” and voila, you have a reusable custom template.

This new method of managing application templates means there is a new schema, so any custom template files created for Portainer 1.x will need to be updated to accommodate Portainer 2.0. We have provided a tool to assist with this conversion (https://github.com/portainer/helper-templates).

Speaking of stacks, we have added the ability to stop a stack; this is a Portainer specific feature, and takes all services/containers offline, whilst retaining the configurations required to restart the stack within the Portainer DB should the need arise (simply click the “start stack” button). This is a neat feature that lets you centralize all of your stacks in one place, and control which run, and when.

Looking beyond Docker; we have further matured our support for Azure ACI. You can now reliably deploy applications in an Azure ACI instance from within Portainer. These containers are all stateless, and internet facing. It takes mere seconds to deploy any container in ACI with Portainer, which is very cool.

Regarding Edge Compute; we have relocated the former “Host Jobs” functionality into “Edge Jobs” and reconfigured the logic that underpins this so that they only function when used against Edge Agent enabled endpoints. This now means that the “Edge Compute” specific features includes; the ability to group edge endpoints, the ability to deploy stacks against groups of endpoints, and the ability to run cron jobs against edge endpoints.

And finally, the biggest change of all, Kubernetes.

We have introduced support for Kubernetes enabled endpoints as part of Portainer CE 2.0,. This means you can manage the deployment of applications atop Kubernetes clusters from within Portainer, using the familiar Portainer UX. We have safely abstracted as much of the unnecessary Kubernetes lingo as possible, leaving a clean UI that allows you to deploy/manage/monitor applications in Kubernetes without needing to know all that much about Kubernetes. We negate the need for you to learn YAML and how to write Kubernetes Manifests, we negate the need for you to learn all of the Kubernetes deployment “rules” and constraints, and when to use which deployment mode for what, and we negate the need for you to learn any of the Kube CLI commands.

It’s important to note, we’re not saying that organizations can fully embrace Kubernetes without having any technical insight into how Kubernetes works (as that’s just crazy talk). Like everything in the IT space, the more you know, generally the better off you are. What we are saying however is that with Portainer, not EVERYONE in your IT/Dev team needs to understand Kubernetes to the same degree. There will be some on the team that naturally gravitate to Kube and its infinite flexibility, but equally there will be some on the team that “just want to deploy an app”… Portainer has always been targeted at those that “just want it to work”… and that continues to ring true as we release Portainer CE 2.0.

So, what can you do in Portainer against Kubernetes; well, there is so much, a list is going to be easier to digest...

As an Administrator, you can:

  • Define what cluster resources users have access to (eg persistent storage, load balancers, ingress, metrics)
  • Create Resource Pools (Kubernetes namespaces) for users to deploy their apps within
  • Assign CPU and RAM quota to resource pools
  • Assign Ingresses to Resource Pools
  • Assign permissions to Resource Pools, so only authorized users can access corresponding resource pools
  • See the status and component health of the Kubernetes Cluster
  • See the leader status, and which nodes are API endpoint enabled
  • See Cluster Events
  • See the Cluster resources assigned vs total
  • See the Node resources assigned vs total
  • Add Node Labels
  • Add Node Taints
  • See which applications are running on each node
  • See and manage all applications deployed across the cluster
  • See and manage all configs/secrets defined in the cluster
  • See and manage all persistent volumes defined in the cluster
  • Deploy applications by directly inputting a Kubernetes Manifest
  • Deploy applications using the simplified UX
  • See which users deployed which applications and when

As a User, you can:

  • Deploy applications in the resource pools you are entitled
  • Assign CPU and RAM reservations for applications up to your quota
  • Add environment variables to your applications
  • Create and Manage Configurations and Secrets for your applications
  • Assign Persistent Storage to applications, if enabled by your administrator
  • Assign Ingress or Load Balancers to applications, if enabled by your administrator
  • Deploy either replicated or global applications
  • Deploy one or more replica of an application
  • Enable auto-scaling for an application if enabled by your administrator
  • Assign placement rules for an application
  • Publish an application either internally, across the cluster, or via Ingress/Load Balancers if enabled by your administrator
  • See the logs of the Application components (PODs)
  • Open a console of each application component (PODs)
  • See the effective placement results (which nodes can the application run on)
  • See the application events
  • See the application resultant manifest
  • See the resulting application deployment type (deployment, daemonset, etc)
  • Edit and application and adjust any prior setting
  • Roll back an application to the last version
  • Redeploy an application
  • Combine applications into logical groups, called Stacks, for simplified management
  • Add annotations for applications to help other users understand the purpose and owner of the application

One final word; in Portainer CE 2.0, we made a change to how we collect anonymous usage data; prior versions leveraged Google Analytics, which was often criticized, and so in 2.0, we have moved to Matomo Analytics, which is hosted in Germany and fully GDPR compliant.

When Portainer first starts, you will be given the option to DISABLE analytics.  If you don’t choose to disable it, Portainer will continue to collect anonymous usage as per our privacy policy. We need this basic telemetry to know which features of Portainer are in most demand, and it is the only mechanism we have in order to focus development efforts. Note that there is no personally identifiable information sent or stored at any time.

We are really looking forward to user feedback on Portainer CE 2.0, and can’t wait for you all to get your hands on it.



          • can’t wait to experience Portainer CE 2.0


          • Excellent! I assume 2.0/CE will have standalone binary releases in addition to Docker images? (like 1.x)


          • No, we will no longer be providing the static binaries for the 2.0 releases.

            This is for the reason that we are using call-outs to external binaries such as kubectl, docker, kompose, and we cannot package these within our binary. Simply ignoring this fact and assuming the user has them installed and in their path is also dangerous, as we only support specific versions.

            So, we will not be providing binaries moving forward.


        • Will Portainer CE 2.0 abandon libcompose in favor of something that actually works? Like docker-compose? As it stands now, version 1.24.1 is nearly useless with stack deployments being horribly broken.


        • Neil Cresswell

          At this stage, out focus is on orchestrated environments, so Swarm and Kubernetes, neither of which rely upon Libcompose. We are looking to replace libcompose once (if) Docker ever release an API for compose. At present for swarm we call the docker binary to do a “docker stack deploy” as there is not even an API for that.

          So no, CE 2.0 will not abandon libcompose for standalone hosts.


      • Egor Pavlikhin

        Amazing update. You guys are delivering so much more than expected. Can’t wait to try out Kubernetes support.


      • Neil Cresswell

        Thank you… its now generally available, so go and play 🙂


    • Very happy OAuth is now included in CE! 😀
      Just for my home use, when trying to self-host things the number of logins just exploded into the 20+ so I started rolling out SSO with Keycloak. Tested CE 2.0 and works like a charm.


    • Hi Neil,

      We are currently exposing port 8000 for portainer and portainer edge agent communication in portainer version 1.24.1.
      After upgrading to 2.0, do we still need to expose 8000 port because as per the release notes it’s exposing by default on Portainer?

      We also tried without exposing port 8000 on portainer but communication btw agent and portainer not working anymore.


    • Neil Cresswell

      Yes, you need to expose 8000 if using the edge agent. What we fixed in 2.0 was adding the EXPOSE 8000 in the docker file, so that if you just use a -P to start portainer, then 8000 is exposed automatically. It was more for completeness than anything else.


Leave a comment!

All fields marked with an asterisk* are required.