Dokku: the small PaaS that never dies

Logotipo oficial del proyecto Dokku alojado en el repositorio abierto de la organización en GitHub, plataforma como servicio minimalista de código abierto inspirada en Heroku con buildpacks, hooks y git push como mecanismo de despliegue, pensada para caber en un único servidor privado virtual y ofrecer a equipos pequeños la mayor parte de la comodidad operativa de un PaaS comercial sin coste de licencia ni complejidad de Kubernetes

Dokku appeared in 2013 as a weekend experiment by Jeff Lindsay, an engineer long fascinated by Heroku’s operational simplicity who wanted to see if the core experience could be reproduced on a single server using the then-newly-arrived Docker and a handful of bash scripts. Twelve years later, with entire ecosystems (Heroku, Dokku itself, Fly.io, Railway, Render) swinging between boom and decline and with Kubernetes established as the large-scale infrastructure standard, Dokku is still alive, actively maintained and surprisingly relevant for a niche other solutions don’t serve well. By late 2025 it’s worth examining what Dokku does, why it has survived, and when picking it pays off.

What Dokku is in 2025

Dokku is an open-source PaaS designed to run on a single server, typically a VPS. Its proposition is to reproduce Heroku’s git push deployment flow: you configure a server with Dokku, add the git remote, push your code and Dokku builds a Docker image using Heroku buildpacks or your own Dockerfile, deploys it, configures HTTP routing with nginx or Caddy, and hands back a working URL. All in under a minute for small applications.

The architecture is deliberately simple. Dokku isn’t a multi-node orchestrator and doesn’t pretend to be. It runs Docker containers on the local machine, manages their lifecycles, connects databases offered as plugins (PostgreSQL, MySQL, Redis, MongoDB and others), configures reverse proxy with automatic SSL via Let’s Encrypt, and offers a command-line interface and optional web panel for administration.

The project has evolved significantly. Version 0.35 released mid-2025 improved support for Cloud Native Buildpacks, refined integration with Caddy as an alternative to nginx, and added more robust support for multi-stage Dockerfile deployments. There are over thirty official plugins for databases, caches, message queues and auxiliary services, and the community maintains many more.

Why it survived the hype cycle

Dokku’s survival in an ecosystem that has seen so many alternatives come and go (Deis, Flynn, Cloudron, Caprover with varying fortunes) is an interesting signal. There are three main reasons.

The first is focus. Dokku doesn’t try to grow in functionality to compete with Kubernetes or commercial PaaSes. It stays true to its original principle: a minimal PaaS that fits on a server. When competing projects tried to add clustering, multi-node high availability or enterprise features, they diluted their identity and lost the niche. Dokku has resisted that temptation and it has kept it useful for those who have the problem it solves.

The second is Heroku compatibility. Because buildpacks are the same, an application that ran on Heroku typically runs on Dokku unchanged. That was a huge advantage when Heroku killed its free plan in 2022 and thousands of small projects sought alternatives: Dokku was the lowest-friction route. Much of the user base that arrived then is still there in 2025.

The third is community. Dokku has a small but stable community, with Jose Diaz-Gonzalez as main maintainer for many years. Release cadence is reasonable (roughly a minor version every two or three months), security issues are addressed quickly, and the discussion forum remains active. It isn’t Kubernetes’ explosive ecosystem, but it’s reliable.

When Dokku pays off versus alternatives

The interesting choice in 2025 depends on the concrete problem. If you have a small or medium web application that fits on a VPS and want comfortable deployment without managing complex infrastructure, Dokku is an excellent option. The cost is the VPS itself (typically 10-30 euros per month for modest workloads) and administration time is minimal if you configure it well from the start.

Versus Kubernetes, the difference in operational complexity is vast. Kubernetes in a managed cluster like GKE or EKS has high base cost (node billing, load balancer, container registry, storage) and a serious learning curve. For a low-traffic application, the cost-complexity to benefit ratio is absurd. Dokku solves 90% of what these applications need with 5% of the complexity.

Versus commercial PaaSes like Fly.io, Railway or Render, the difference is cost and control. These services offer better developer experience and automatic horizontal scaling, but bill by usage with invoices that grow quickly as the application scales. For projects that want full data control, predictable costs, or European residency requirements not met by providers, a European VPS with Dokku is a pragmatic solution.

Versus Docker Compose on a server, the difference is subtler. Docker Compose is enough if your application is simple. Dokku adds automatic buildpacks, certificate management, database management, revision between deployments, and hooks for migrations. If you’re going to replicate all that by hand with Compose, sooner or later you arrive at something similar to Dokku but worse.

Typical installation and deployment

The Dokku onboarding flow is clean. On a fresh Debian or Ubuntu VPS, you run the bootstrap script, create an app, create and link a database, set a domain, and enable Let’s Encrypt. From the local machine, you add a git remote and push. In three minutes the application is deployed, with connected database, configured domain and issued SSL certificate. That’s the flow Heroku made famous, reproduced faithfully.

Honest limitations

Being clear about limitations matters. The most important is that Dokku runs everything on a single server. If the server goes down, the application goes down. For real high availability you need another approach: external load balancer with several Dokku servers behind, or jump to Docker Swarm or Kubernetes. There’s no elegant solution within Dokku for this because it isn’t its problem.

The second limitation is scaling. Dokku supports vertical scaling (more memory, more CPU on the same server) and running multiple processes in parallel on the same server (web, worker, etc.), but doesn’t scale horizontally across servers. For applications receiving heavy traffic, sooner or later you hit the single-server ceiling.

The third is the plugin ecosystem. Official ones are well maintained but community ones vary in quality. Before relying on a little-used plugin in production, reviewing its activity and testing in a non-critical environment pays off. That’s true for any open-source project but worth a reminder.

The fourth, subtler, is that Dokku doesn’t offer strong multi-tenant isolation. All applications on the server share the kernel and resources. For a team deploying its own applications, that’s fine; for offering hosting to third parties, it isn’t enough.

When it pays off

My reading after using Dokku personally for several years and seeing it across client projects is that it’s an excellent tool for a well-defined set of cases. For a solo developer or a small team deploying several web applications with moderate traffic, Dokku is probably the best productivity-cost-control ratio that exists in 2025. Neither Kubernetes nor commercial PaaSes beat it in that specific zone.

For any other case, better alternatives exist. If you need real high availability, Kubernetes or Docker Swarm. If you need deployment to be maximally frictionless and cost doesn’t matter, Fly.io or Render. If the project is a single static page, Cloudflare Pages or Netlify. But that intermediate niche (few applications, moderate traffic, contained budget, data control) is large and Dokku remains the tacit king. The general lesson is that tools that survive long technology cycles aren’t the flashiest but the ones that solve a concrete problem without overreaching, and Dokku fits that description exactly. Ignoring its existence when evaluating options for a small project is a common mistake that ends up costing money and unnecessary complexity.

Entradas relacionadas