Cloud Parts

Dokku

A Heroku-like PaaS on one server of your own: git push to it, and Dokku builds the app with buildpacks or a Dockerfile and runs it in Docker containers behind nginx.

What it is
Platform as a service (PaaS)
Type
Open source
Made by
Dokku maintainers
License
MIT
Facts checked
12 October 2026
Website Source code

What it is

Dokku installs on a single Ubuntu or Debian machine with at least 1 GB of memory. You create an app on the host (dokku apps:create), add a Git remote such as dokku@dokku.me:ruby-getting-started and git push to it over SSH. A builder turns the code into an image: by default herokuish, which runs Heroku’s classic buildpacks; pack, which runs Cloud Native Buildpacks; or dockerfile when the repository only has a Dockerfile. Prebuilt Docker images work too. The default scheduler then starts the processes from your Procfile as containers on the local Docker daemon, nginx routes each app’s domain to its web containers, and Dokku manages cron tasks and background processes as well.

Almost everything is a plugin: Dokku itself is a collection of plugins run by plugn. Datastores aren’t built in. Official plugins such as dokku-postgres create a database container, and dokku postgres:link sets DATABASE_URL on the app, the same contract as a Heroku add-on. Deploys are zero-downtime by default: Dokku waits 10 seconds after starting each new container (or runs your checks), switches traffic, then sends SIGTERM to the old containers. For more than one server, the K3s scheduler (since 0.33.0) runs apps on a Dokku-managed K3s cluster, with KEDA for autoscaling.

Why teams pick it

  • A Heroku-style workflow (git push, Procfile, buildpacks, config as env vars) on a single VM you already pay for
  • Three builders and plain Docker images, so the same host runs buildpack apps and Dockerfile apps side by side
  • Official plugins for common datastores, plus community plugins, all wired up through environment variables
  • MIT-licensed and actively released: v0.38.31 shipped in September 2026

Watch out for

  • By default everything, apps and databases included, runs on one host, so that host is a single point of failure and its OS, Docker and backups are yours to run
  • Multi-server setups mean the K3s scheduler, which needs at least 2 GB of memory on every node and brings Kubernetes with it
  • Apps must listen on the port in $PORT, or they won’t answer web requests
  • Still versioned 0.x after more than 13 years, so read the upgrade notes before each release

Alternatives

What all platform as a service (paas) have in common →
AWS Elastic BeanstalkAWSUpload your code and Elastic Beanstalk builds the AWS setup to run it (EC2 instances, a load balancer, an Auto Scaling group) in your own account, where you can still see and change every piece.Azure App ServiceAzureAzure’s platform for web apps and APIs: you rent a pool of VMs called an App Service plan, and every app you put in it runs on those VMs without you managing them.Cloud FoundryOpen sourceAn open-source PaaS you run yourself: `cf push` uploads your code, a buildpack stages it into a droplet, and Diego keeps the requested number of instances running behind the Gorouter.Fly.ioCommercialFly.io turns your Docker image into fast-booting Firecracker microVMs on its own servers in regions around the world, and routes each user to the nearest one.Google App EngineGoogle CloudGoogle’s original platform as a service: describe your app in an `app.yaml`, run one deploy command, and Google runs and scales the instances.HerokuCommercialThe platform that defined PaaS: `git push` your code, and Heroku builds it with a buildpack and runs it on managed containers called dynos behind its own HTTP router.RenderCommercialRender builds and deploys web services, background workers, cron jobs and managed Postgres and Key Value stores from your Git repo, all described in one `render.yaml` file if you like.

How it fits with other technologies

Deploy a Rails app with a Postgres database · bash

# on the Dokku host
dokku apps:create ruby-getting-started
sudo dokku plugin:install https://github.com/dokku/dokku-postgres.git
dokku postgres:create railsdatabase
dokku postgres:link railsdatabase ruby-getting-started   # sets DATABASE_URL

# on your machine
git remote add dokku dokku@dokku.me:ruby-getting-started
git push dokku main      # herokuish build, then a zero-downtime deploy

# back on the host: two web containers behind nginx
dokku ps:scale ruby-getting-started web=2

See it in a real stack

No architecture uses Dokku yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2013–2026

Jeff Lindsay made the first Dokku commit on June 8, 2013. The README called it a “Docker powered mini-Heroku” and “the smallest PaaS implementation you’ve ever seen”. It glued together three small projects: Docker to run containers, Buildstep to build apps with Heroku buildpacks (Node.js and Ruby at first), and gitreceive to accept a git push.

The point was size and speed. The first README said installing took around 5 minutes, “certainly better than the several hours it takes to bootstrap Cloud Foundry”. The first outside pull request, a day later, prepared it for Java apps. Over the following years Dokku grew a plugin system, official datastore plugins and a choice of builders, including Cloud Native Buildpacks.

Dokku stayed a single-server tool by default, but builders (0.24.0, 2021) and schedulers (0.26.0, 2021) became pluggable, and in 2024 version 0.33.0 added a K3s scheduler that spreads apps over a cluster of servers while keeping the same git push workflow.

Why it’s built this way

Assemble existing tools instead of building a platform
The first version was Docker, a buildpack runner and a Git receiver wired together by a bootstrap script, and it installed in about 5 minutes instead of the hours a full platform such as Cloud Foundry took.
Heroku compatibility
Using Heroku’s buildpacks and Procfile meant apps written for Heroku, such as Heroku’s own getting-started apps, deploy to Dokku unchanged.
Everything as a plugin
Dokku’s own features are plugins run by plugn, so datastores, builders and schedulers can be added or swapped without changing the core.

Timeline

  1. 2013

    Jeff Lindsay makes the first commit on June 8: Docker, Buildstep and gitreceive

  2. 2021

    Pluggable builders arrive in 0.24.0 (March) and schedulers in 0.26.0 (October)

  3. 2024

    0.33.0 adds the K3s scheduler for multi-server clusters (January)

  4. 2026

    v0.38.31 is released in September

Sources12 · facts checked 12 October 2026

Improve this page on GitHub