What Portainer 3.0 Changes for CE Users
Since its inception, Portainer Community Edition allowed managing Docker containers and Compose stacks through a web interface, for free, with no node limits. Portainer 3.0 changes this model: the CE disappears in favor of a unified plan, the 3 Nodes Free (formerly Business), which limits usage to three nodes at most. For teams exceeding this limit or unwilling to accept a commercial licence even if free (Business Terms of Service), migration is unavoidable.
As of 18 September 2026, the official announcement covers the imminent transition. For Portainer CE users, three questions arise immediately: will their configuration data be migratable, will their current workflow survive the change, and which alternative fits their constraints — single server, multi-server, or GitOps?
The Three Migration Profiles
- Single server, simplicity first → Dockge: lightweight interface, Compose stacks, zero dependencies.
- Full app deployment, self-hosted PaaS → Coolify: integrated reverse proxy, automatic SSL, deploy from Git.
- Multi-server, GitOps, teams → Komodo: centralised orchestration, Core < 256 MB RAM, available in the ServOrbit catalogue.
- All three tools are under open source licences, with no paid tier for core features, and are actively maintained in 2026.
Dockge — Compose Management Without the Complexity
Dockge is a docker-compose.yml stack manager developed by the creator of Uptime Kuma. It does not aim to replace Portainer entirely: it targets a precise scope, managing and deploying Compose files through a clean web interface.
Strengths: it starts with two commands (git clone + docker compose up), listens on a single port, requires no database, and a single Dockge instance can control multiple Docker hosts via SSH. Its interface clearly displays the state of each service, real-time logs, and allows editing a docker-compose.yml directly from the browser.
Limitations: Dockge does not handle Kubernetes, does not include an integrated reverse proxy, and does not support managing private Docker registries. If your workflow involves anything beyond Compose stacks on Linux VPS, you will quickly reach its limits.
Coolify — Self-Hosted PaaS With Integrated SSL and Reverse Proxy
Coolify positions itself as a Heroku or Render that you host yourself. It goes beyond container management: it handles deployment from Git (push-to-deploy), automatically configures the reverse proxy (Traefik), renews SSL Let's Encrypt certificates, and can deploy not only Docker apps but also static sites and Dockerfiles.
Strengths: a single install command (curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash), modern interface, native management of environment variables and secrets, and deployment across multiple servers from a central dashboard. Coolify also supports Laravel, Node.js, Python, and other frameworks without manual proxy configuration.
Limitations: heavier than Dockge (several background services), requires a domain to access the interface by default, and its Git deployment model may be overkill if you only manage Compose stacks.
Komodo — Multi-Server Orchestration and GitOps
Komodo (formerly Monitor) is the most fully-featured of the three. Under the GPL-3.0 licence, it offers a Core/Periphery architecture: a central Core orchestrates Periphery agents deployed on each server. It manages Docker and Docker Compose deployments, synchronises stacks from a Git repository, centralises logs and alerts, and exposes an API.
The Komodo Core consumes less than 256 MB of RAM at idle — it fits on the same entry-level VPS as your apps. It is the closest alternative to Portainer in terms of functional scope, and the only one of the three to natively cover the multi-server case with GitOps.
For a full installation walkthrough, see the dedicated guide: self-host-komodo-vps. Komodo is also available directly from the ServOrbit catalogue.
Deploy Komodo Core on a ServOrbit VPS
Prerequisites
A VPS with root access, Docker and Docker Compose installed. Allow for 1 vCPU and 512 MB RAM minimum for the Core alone (under 256 MB at idle). A domain name or subdomain pointing to your VPS is recommended for HTTPS access.
Create the directory and Compose file
Connect via SSH, then:
mkdir -p /opt/komodo && cd /opt/komodoCreate a
compose.ymlfile using the official content from the Komodo documentation. Adapt theKOMODO_HOSTvariable (your domain),KOMODO_PASSKEY(a long random string), and volume paths to your setup.Start the Core
docker compose up -dCheck that both
komodo-coreandkomodo-mongocontainers areUp:docker compose psThe Core listens on port 9120 by default. If you use a reverse proxy (nginx, Caddy), create a vhost that proxies to
localhost:9120.Configure HTTPS with Caddy or nginx
With Caddy (the simplest approach):
komodo.your-domain.com { reverse_proxy localhost:9120 }Caddy automatically renews the Let's Encrypt certificate. With nginx, create a standard
serverblock withproxy_pass http://127.0.0.1:9120;and manage the certificate via Certbot.Add your servers (Periphery agents)
On each server to monitor, deploy the Periphery agent:
docker run -d \ --name komodo-periphery \ --restart unless-stopped \ -v /var/run/docker.sock:/var/run/docker.sock \ ghcr.io/moghtech/komodo-periphery:latestIn the Core interface, add the server with its IP and the shared passkey. The agent immediately reports the state of all containers and stacks.
Connect a Git repository for GitOps
In Komodo, go to Resources → Repos and add your repository (GitHub, Gitea, Forgejo, or any compatible Git server). Then create a Stack pointing to a
compose.ymlpath in that repository. On each sync (manual or triggered by a webhook), Komodo applies the diff — exactly the expected GitOps behaviour.For further integration with Forgejo/Woodpecker, see deployer-avec-portainer for the reverse proxy and SSL configuration reference, applicable to any container manager.
Comparison: Dockge, Coolify and Komodo vs Portainer CE
Scroll the table
| Criterion | Dockge | Coolify | Komodo |
|---|---|---|---|
| Licence | MIT | Apache 2.0 | GPL-3.0 |
| Multi-server | No (1 host) | Yes (SSH nodes) | Yes (Core/Periphery) |
| GitOps / repo sync | No | Yes (push-to-deploy) | Yes (Git Stacks) |
| Automatic SSL | No (managed separately) | Yes (integrated Traefik) | No (managed separately) |
| RAM idle (Core) | < 50 MB | ~ 300–500 MB | < 256 MB |
| RBAC / users | No | Yes | Yes |
| REST API | No | Yes | Yes |
| Primary use case | Single-server Compose | Dev/agency PaaS | Docker fleet + GitOps |
| In ServOrbit catalogue | No | No | Yes |
Troubleshooting — Common Migration Errors
Portainer CE port 9000 conflicts with Komodo. If you run Portainer in parallel during migration, check that Komodo listens on a different port (9120 by default). Adjust KOMODO_PORT in Komodo's Compose file if needed.
docker.sock refused by the Periphery agent. On some distributions (Ubuntu 22.04+), the socket belongs to the docker group. Add the current user to that group (usermod -aG docker $USER) or run the agent with --user root — only if you understand the security implications.
Compose stacks imported from Portainer fail to start. Portainer stores some environment variables in its own vault (Secrets). Check that each migrated compose.yml has a complete .env file, or declare the variables in Komodo's Variables section.
Coolify cannot find the Dockerfile after connecting Git. The "Build path" field must point to the directory containing the Dockerfile, not the repository root if the file is in a subdirectory. Also verify that the configured branch actually exists on the remote.
Dockge shows "Compose file not found" after a restart. The volume mount must point to the parent directory of the project, not to the compose.yml file directly. Dockge's convention is /opt/stacks/<stack-name>/compose.yml — follow this layout.
Progressive migration strategy
Do not cut Portainer CE before validating your alternative. Deploy Komodo (or Dockge) in parallel on the same server, import your stacks one by one, test each deployment, then stop Portainer. The two tools do not interfere: Komodo accesses the Docker socket without conflicting with Portainer on a different port. A one-night migration for a fleet of ten stacks is realistic.
