Portainer 3.0 is coming: what Docker users need to know. Portainer 3.0 is shifting its focus toward Kubernetes, but what does that mean for Docker users? Here's what's changing and what happens to Community Edition. Portainer has been a popular choice for managing Docker containers for years, especially among self-hosters who prefer a web interface over the command line. But with Portainer 3.0 on the horizon, the company is making some significant changes to its development priorities. On September 11, 2026, Portainer announced that version 3.0 would take a Kubernetes-first approach, raising questions about the future of Docker support and Community Edition. If you're currently running Portainer on your home server, here's what you need to know. What's changing in Portainer 3.0? Portainer is shifting its development focus toward Kubernetes, primarily to support more advanced infrastructure management capabilities. According to the company, maintaining feature parity across Docker, Docker Swarm, Podman, and Kubernetes has become increasingly difficult. As explained in its follow-up article, The Docker API Ceiling, new capabilities involving GitOps, observability, and policy management will primarily target Kubernetes. Docker support isn't going away. Portainer has confirmed that Docker, Docker Swarm, and Podman will continue to be supported in version 3.0. However, Docker users shouldn't expect to receive every new feature introduced in future releases. Portainer is also working on projects like KubeSolo and Portainer-D2K, which aim to make Kubernetes more accessible to users familiar with Docker workflows. What happens to Community Edition? This is probably the most important change for home server users. Portainer Community Edition will remain on the 2.x branch, with version 2.45 LTS serving as its final release line. The company says Community Edition will continue receiving maintenance updates, security patches, and bug fixes throughout its supported lifecycle. However, the new Portainer 3.x architecture won't be available in Community Edition. Instead, Portainer 3.x will be distributed through Business Edition, which includes a free three-node offering. That distinction matters for users who prefer the traditional open-source Community Edition rather than a commercially licensed product. Should Docker users look for alternatives? If your current Portainer installation works well, there's no immediate reason to replace it. Docker management features aren't suddenly disappearing, and Community Edition will continue receiving updates during its supported lifecycle. Still, the announcement makes this a good time to explore some alternatives. Projects like Komodo, Dockge, and Dockhand offer different approaches to managing Docker containers and Compose stacks. Dockge focuses on Compose management, while Komodo provides more extensive deployment and infrastructure management capabilities. Dockhand is another option for users interested in a modern Docker management interface. Each has its own strengths, and none requires moving your entire environment to Kubernetes. Final notes and thoughts. I've used Portainer extensively, and I understand why some Docker users are concerned about the direction it's taking. Portainer has become popular in the self-hosting community because it makes managing containers straightforward. Many of Noted don't need the additional complexity that comes with Kubernetes. At the same time, Portainer is building a platform for customers whose infrastructure requirements go well beyond a typical home server. For now, I'll continue using Portainer while keeping an eye on the alternatives. There's no reason to abandon a working setup simply because the development roadmap is changing. But I do think this creates an opportunity for Docker-focused projects to gain more attention. For most home server users, Docker Compose still does everything they need. And there's no shortage of tools available to manage it. Noted Poll Which Docker manager do you prefer? Choose one option. If you found it useful, let Noted know. 1 reader found this helpful Related apps.

Integrate portainer and Keycloak Identity and Access Management (IAM). Managing users individually within Portainer works fine for small labs, but as your infrastructure grows, manual user management becomes a security risk and an administrative headache. To achieve true scalability and centralized control, you need a robust Identity and Access Management (IAM) strategy. In this guide, Cylab will walk through the process of integrating Portainer with Keycloak using OpenID Connect (OIDC). Beyond just setting up Single Sign-On (SSO), you will learn how to automate user provisioning and use Keycloak group mapping to automatically assign Portainer teams and permissions. Prerequisites Before Cylab begin, ensure you have a running instance of Portainer Business edition and a Keycloak realm already configured. If needed, you can get a free Business edition licence for up to 3 nodes at https://www.portainer.io/take-3 Keycloak. In Keycloak, create a new client with the type OpenID Connect. On the second screen (Capability config), make sure Client authentication and Standard flow are selected. On the third screen (Login settings), indicate the URL of your portainer instance (WITH the trailing /) in the Valid redirect URIs field. Once the client is created, open the Credentials tab and copy the Client Secret Configuring portainer for OAuth. Now, open your portainer instance and in the menu open Settings => Authentication. * For Authentication method, select OAuth * You can enable Use SSO to speed-up the login process * Disable Hide internal authentication Keep Hide internal authentication DISABLED and make sure you have an emergency admin account configured on Portainer. If your Keycloak instance becomes unreachable, you will need the local admin account to recover the system. * You can enable Automatic user provisioning as it means you don't need to manually create users in Portainer, but keep in mind that with this configuration anyone with a Keycloak account will have access to your Portainer instance. Now in the Provider section select Custom then fill the following OIDC endpoints. Note: Replace {your.keycloak.address} with your domain and {realm} with your specific Keycloak realm name. | Field | Value | | Client ID & Secret | Copy from Keycloak Credentials tab | | Authorization URL | https://{addr}/realms/{realm}/protocol/openid-connect/auth | | Access Token URL | https://{addr}/realms/{realm}/protocol/openid-connect/token | | Resource URL | https://{addr}/realms/{realm}/protocol/openid-connect/userinfo | | User Identifier | preferred_username (or email) | | Scopes | openid email profile | Testing the integration. You can now test you OAuth authentication. Authentication will succeed, but the user will not have access to any resource. To give the user access to resources, you must either manually assign roles or teams to the user, or configure groups mapping as explained below. Roles and teams management. The primary mechanism for managing Portainer roles and teams from Keycloak relies on mapping Keycloak groups to Portainer teams. This means that the name of the teams you create in Portainer must exactly match the name of the realm groups in Keycloak. Keycloak group mapping. In Keycloak, open the client, then the tab Client scopes then the Dedicated scope for this client. Click on Configure a new mapper then in the list select Group membership. * Name: groups * Token Claim Name: groups * Full group path: Off Now the list of groups a user belongs to will be added to the token Keycloak handles to Portainer. Portainer team. Back to Portainer, in the user-related menu, select Teams and create a team. The name must exactly match the name of the corresponding group in Keycloak. Then in Environment-related, select one (or more) environments and create an access to this environment for the team you created. Portainer authentication. Now in the Authentication menu, you can enable Automatic team membership and set claim name to groups. If needed you can also Assign admin rights to group(s) and define a mapping (regex) that matches groups(s) that should be Portainer administrators. This blog post is licensed under CC BY-SA 4.0