Portainer 2.0, and the development “balancing act”

Over the coming weeks we will announce the availability of Portainer Community Edition 2.0. We expect to ship code mid Q3, however it’s always dangerous to announce a date too early.

But before I talk about 2.0, I want to talk a bit about prioritization and decision making.

We have limited resources at Portainer, and a list of feature requests and opportunities as long as Route 66. We must make priority decisions every day, and inevitably, someone somewhere gets upset because we haven’t delivered to their expectations.  We know this, and it’s something that we don’t like to see happening, but we must work within our means.

The way we make decisions on requested functionality additions / fixes to Portainer is as follows:

  • is this addressing a security vulnerability or potential exploit? if so, add it;
  • is this a feature that we feel would have wide appeal? if so, add it;
  • is this a feature that has at least 20 “thumbs up” or “hearts” inside Github? if so, add it;
  • is this a feature that would benefit professional users of Portainer? if so, add it.

When there are feature requests / issues that exist only with a specific use cases, judged either by us or through a lack of community “thumbs up” then these sit “pending” until enough demand is identified for them (so don’t forget to thumbs up issues you care about). Also, it’s important to note that we don’t automatically maintain feature parity with Docker, so when they bring out new features in Docker CE, we evaluate each based on the 4 criteria above before deciding whether to add it to Portainer. With our current resources, we only add support for features we feel have real demand.

So, what’s going to be in Portainer Community Edition 2.0…

Of all the platforms Portainer supports, Docker and Docker Swarm are our fundamental roots; we would not be where we are today without what we built for these two underlying technologies, and as such, we plan to keep support for them as long as it makes sense. Lately though we have seen several issues opened with us relating to Swarm and these users are either hitting undocumented limitations in Swarm (eg 128 max ports exposed via Ingress) or known issues in Swarm that have been open and unresolved for 2+ years. This concerns us, as we cannot work around these issues in Portainer, so these issues/limitations become our issues/limitations too. We will be guided by our community on what features we need to continue to bring to Swarm deployments; we have our view and have collated a list of feature requests that meet our 4 criteria, and these will be added in the next 1-2 releases.

The biggest feature we will be adding to Portainer 2.0 is support for Kubernetes. We sat on the Kubernetes feature request for a long time as we struggled to come up with a simple UI/UX for it, but after cracking that nut late last year, we have advanced our development significantly. We want to add Kubernetes “without compromise”, and by that, what we mean is that we want to offer as many of the features we offer today for swarm, tomorrow for Kubernetes.

We have a lot of work to do though, and this means that most of our developers are focused on this Kubernetes activity. That said, we have assigned developers to keep working through the backlog of Swarm / standalone issues, starting with the most “in demand” and working down from there. We are also continuing to add functionality to our “serverless” options (Azure ACI support), and plan to keep building out our edge compute management functionality too.

In the diagram below (click to enlarge), we have tried to depict where we are focusing our development efforts over the coming 6 months.

Thats all for now.... we have product to build....



      • Thanks for your work on Portainer, I appreciate it every day.


      • thank you for your work on Portainer


      • The simplicity and reliability of Portainer have made me a fan and loyal user. Like so many others, I appreciate what you folks are doing.

        Your roadmap is well organized and ambitious. Quality always trumps quantity, so try to avoid the temptation to please everyone or over-stress to hit a deadline. PLEASE don’t burn yourselves out! We will appreciate the improvements when they are ready and want your small team motivated for the long haul.

        Above all else – Thank-you!


      • David Bayliss

        Portainer makes messing about with Docker fun (for us GUI lovers). Looking forward to Kubernetes support. Thanks.


      • Fred Delorme

        Portainer is one of the best light docker management UI. keep this tool so good and useful !


      • Ryan T Jones

        We’ve been using Portainer since we began our Docker journey several years ago. It has given us powerful capabilities and made the management of 500+ services over 7 separate swarms a breeze. We’re excited to be starting our Kubernetes and looking forward to having Portainer as our continued management tool!


      • Neil Cresswell

        Woohoo, that is an awesome sounding environment, and we are really happy to hear that we have been adding value to your management of such over the years..


    • I have just gotten into Portainer after hitting my max from the command line with Docker. This is an outstanding product. I am just managing a standalone server so haven’t needed Kubernetes other than just out of curiosity. I appreciate what you can bring to Kubernetes, just please don’t abandon the folks who are running things on a smaller scale.


    • Neil Cresswell

      We plan to keep developing for Docker Standalone, and Swarm as long as it makes sense technically… we keep coming up against unresolved outstanding issues with Docker that make us concerned about it, but we continue to add features and develop workarounds where possible.


Leave a comment!

All fields marked with an asterisk* are required.