Heroku vs Dokku: which fits your team's Heroku exit or renewal
Heroku fits teams that want managed dynos and add-ons with the vendor operating the platform, while Dokku fits teams that want the same git push deploy model on servers they control and have the skills to run. The decision turns on four questions: how much operating capacity your team can spare for patching, upgrades and on-call; who owns database backups and restore testing; which compliance scope your auditors will draw around the platform; and whether one host is enough. Dokku is a single-server tool by default, so the last question matters most if you expect traffic or redundancy requirements to grow.
Timing matters because of Heroku's February 6, 2026 move to a sustaining engineering model, which the company describes as a focus on stability, security, reliability and support rather than new features, and which ended new Enterprise Account contracts. For existing customers this is a change in direction, not a shutdown, but it means you should confirm in writing what your current contract covers and at what renewal date. Heroku's next-generation Fir platform, generally available since April 2, 2025, uses Cloud Native Buildpacks only, so check whether your app's current buildpack stack and add-ons behave the same way before you commit to a migration window. Dokku's current release is v0.38.31, and because it is still versioned 0.x, pin the version you test and plan upgrades deliberately.
Ask your team three concrete questions before choosing. First, can you name who on your side will apply security updates to the host and the Docker daemon each month? Second, if Dokku runs the database through the dokku-postgres plugin, who tests restores from the S3-compatible backups and who owns retention? Third, if a single server failure would breach your service commitments, does the k3s scheduler, which builds a multi-server K3s cluster and requires a Docker registry, fit your plan, or should you move toward Kubernetes instead? If the answers point to a single host with a skilled operator, Dokku is a strong fit. If they point to vendor-run operations or multi-host resilience from day one, keep Heroku or plan a different target.
Which platform fits which scenario
This table matches common team situations to the platform that usually fits best, with the reason and the condition that could change the answer. Read each row as a starting point, then check the flagged dependency against your own team skills and compliance scope before you decide.
| Scenario | Better fit | Why and what it depends on |
|---|---|---|
| Small team with simple web apps and a Procfile | Dokku | Git push deploys, Heroku buildpacks and Procfiles carry over with few changes. Depends on whether someone on the team is comfortable with Linux server administration and SSH. |
| Team that wants Heroku Postgres-style backups but does not want to run them | Heroku, or a managed database outside Dokku | Dokku's dokku-postgres plugin can run scheduled backups to S3-compatible storage, but the team still owns upgrades, restore tests and failover. Ask whether the team will own those tasks before choosing Dokku. |
| Team with a data residency rule | Dokku on servers in a data center you choose | Dokku runs on hardware you select, so data location follows your choice of host. Confirm with your legal or compliance lead which regions and subprocessors are allowed, since Heroku's region options differ by runtime. |
| Team that needs several servers for one app | Heroku, or Kubernetes for a larger footprint | Dokku's default scheduler runs on a single host. The k3s scheduler can span servers but requires a Docker registry and uses the first Dokku server as the only git push target. Judge the added operational load against the benefit. |
| Team with an existing Heroku buildpack app | Dokku | Dokku's herokuish builder accepts Heroku v2a buildpacks, so many apps build with little change. Apps that rely on Fir-only behavior or unsupported Heroku features need a build test before cutover. |
| Team with Heroku Shield or HIPAA or PCI scope | Depends on compliance scope | Dokku can be run inside an environment you control, but the controls, logging, access reviews and evidence become your responsibility. Confirm the scope with your assessor before choosing either platform. |
| Team with no dedicated platform or operations staff | Heroku or a managed PaaS | Self-hosting moves patching, backups, recovery and on-call time to your team. A managed service may cost more per resource but carries less operating work. |
| Team that needs a web dashboard for multi-server management | Coolify or Dokploy, not Dokku | Dokku is command-line driven. Teams that want a graphical interface should compare the sibling Coolify and Dokploy pages before deciding. |
Where your data lives and who controls the platform
Moving from Heroku to Dokku changes three things at once: where application data sits, who operates the platform underneath it, and which records you can show an assessor. The cards below cover each of these so you can check them against your own requirements before a renewal or migration decision.
Data location on Heroku
On Heroku, dynos, Postgres and add-on data run in Salesforce-operated regions, and you choose a region within the options your account and space type offer. Check which region each app, database and backup sits in, and whether add-on providers store data in a different location. Write down the region for every component before you compare it with a server you choose yourself.
Data location on your own servers
With Dokku, application containers, the Postgres plugin data directory and any S3-compatible backup target run on hosts you rent or own, in the data center and country you select. The Dokku host is the single point where app data lives unless you add replicas. Confirm the hosting country, the provider's sub-processors and where backup copies are stored.
Hosting model and paid options
Heroku is a managed service: Salesforce operates the platform, and you pay per dyno, database and add-on. Dokku is software you install on a server you rent, so you pay the server provider and your own staff time. The optional paid Dokku Pro is a separate product from the MIT-licensed core. Ask which features are in the free core and which depend on Pro before you sign anything.
Licensing and forking risk
Dokku is MIT licensed, so you can run, modify and redistribute it without asking the project for permission. Heroku is a proprietary service under Heroku's terms, and its exit from new features and Enterprise Account contracts makes the product roadmap less predictable for planning. Keep a record of the Dokku version you run, and have your engineers confirm that every plugin you depend on carries a license your legal team has approved.
Identity and access control to confirm
Heroku provides team roles and SSO options through its account settings, and those controls are managed for you. On Dokku, access to the git push target, the server SSH keys and the Docker socket are your responsibility to design. Confirm who holds root on each host, how SSH keys are rotated when staff leave, whether you need a bastion host, and how deploy keys for CI are scoped.
Compliance evidence you keep
When Heroku operates the platform, some of the platform evidence comes from Salesforce's own programs, and you collect the rest. On Dokku, host hardening, patching records, access reviews, backup restore tests and change logs are yours to produce and retain. DeployOpen can prepare these controls and collect the evidence, but independent auditors and certification bodies issue any audit report or certification. Ask your assessor which artifacts they will request before the migration starts.
How Dokku runs an app from git push to live traffic
A single git push to the dokku remote is the entry point. Dokku creates the app on the fly if it does not exist yet, then selects a builder from the files in the repository. A Procfile and app.json are read for process types, deploy scripts and healthchecks, and the builder can be a herokuish buildpack run, Cloud Native Buildpacks through the pack CLI, a Dockerfile, or a Nixpacks or Railpack build when nixpacks.toml or railpack.json is present. Builder choice is set per app, so teams moving a Heroku app should confirm which builder it resolves to before the first deploy, and check whether its Procfile or app.json uses anything the Dokku documentation marks as unsupported.
The built image then starts as a container on the default docker-local scheduler, which runs it directly on the Dokku host. Dokku scales the web process to 1 on the first deploy, and any release process type runs before traffic moves. The proxy is nginx by default, with Caddy, HAProxy, OpenResty and Traefik available as alternatives, and it routes each domain to the container and handles HTTPS. If a datastore plugin is linked, such as the official Postgres plugin, Dokku sets DATABASE_URL for the app, so the code that reads it on Heroku usually needs no change. Confirm that your server has at least 1 GB of RAM for the default scheduler, and that the operating system is one of the supported Ubuntu 22.04, 24.04 or 26.04 or Debian 11 or later releases on AMD64 or arm64.
Everything in this flow runs on one server by default, which means the build, the containers, the proxy and the database share the same CPU, memory and disk. There is no equivalent of Heroku's managed dyno pool that adds capacity on your behalf. Scaling past one host is a separate decision that involves the k3s scheduler and a Docker registry, covered in the scaling section. Before cutover, plan the host's sizing, its patching window, and where the Postgres backups will be sent, since a failed host takes the whole flow down with it.
What you pay for on Heroku versus Dokku
Heroku bills recurring fees per dyno, database and add-on, so the invoice scales with resources you allocate. Dokku moves that spend to servers, storage, backups and the staff time needed to run them. Use Heroku's pricing page and your own usage to price the Heroku side, then build the Dokku side from the components below.
Heroku dyno and add-on fees
Heroku bills each dyno, Postgres plan and add-on per month, so cost follows the number of process types, dyno sizes and database tiers you run. Pull your current formation from the Heroku dashboard and multiply it by the list rates on Heroku's pricing page. Ask whether your plan includes enterprise terms, since the February 2026 sustaining engineering update affects new Enterprise Account contracts. This line recurs every month and is the cost most directly tied to scale.
Server rental for Dokku
Dokku runs on a single server, so the main infrastructure line is the monthly rent for one host, sized to your app containers, build jobs and the datastore plugins you co-locate. Dokku needs 1 GB of RAM for its default Docker scheduler, but real sizing depends on builds, concurrency and database load. Ask your provider for the monthly rate of a host with the CPU, memory and disk you need, and plan a second host if you need redundancy.
Storage and backup storage
Database volumes, uploaded files and backup copies consume disk and, when you send backups to S3-compatible storage, a separate object storage bill. The dokku-postgres plugin can run scheduled backups to that storage, so retention length and copy count directly set this cost. Confirm the retention you need with your compliance owner before you size the bucket, and budget for restores tested at least as often as backups run.
Dokku Pro, if you choose it
Dokku is MIT licensed and free to run, but Dokku Pro is an optional paid offering from the same project. Treat it as a separate line item only if you buy it, and get its scope, support terms and renewal in writing before you commit. Do not assume it replaces any Heroku feature until you have checked the feature list against your current add-ons and workflows.
Internal time for patching and on-call
This is the cost Heroku currently carries for you: OS and Docker patching, Dokku upgrades, certificate and proxy maintenance, monitoring and on-call response. It recurs and is often the largest line on the Dokku side. Estimate the hours per month with your platform team, and decide who answers pages out of hours before comparing totals. Heroku's sustaining engineering model changes the risk profile of staying put, so plan this line with your renewal date in mind.
One-time migration work
Migration is a one-time cost separate from the monthly comparison. It covers rebuilding apps with git push, moving buildpacks, Procfiles and app.json, exporting and restoring Heroku Postgres data, re-creating config vars, testing and the DNS cutover. Ask any implementation partner for a fixed-scope written quote that lists each app, datastore and cutover step, and keep it out of the recurring totals.
How a move from Heroku to Dokku unfolds
The sequence turns a Heroku app estate into Dokku apps on a server you control, with each step ending in a check that proves the app, its data and its operations are ready before DNS moves. Confirm your Heroku exit timeline against your contract renewal dates before the first step begins.
Inventory apps, Procfiles, buildpacks and add-ons
Your engineering lead lists every Heroku app, its process types in the Procfile, the buildpacks in use, the add-ons attached (Postgres, Redis, schedulers, logging) and any app.json file. Flag anything Dokku does not replicate, such as add-ons without an official Dokku plugin or Heroku-specific features. The step is done when each app has a written row covering runtime, processes, datastores, environment variables and public domains, reviewed by the team that owns it.
Prove builds on a staging Dokku host
Install Dokku on a staging server that matches your target operating system and memory needs, then push each app to a dokku remote with git push. Dokku builds with herokuish by default, or you can select Cloud Native Buildpacks, Nixpacks, Railpack or a Dockerfile where the buildpack will not run. Record which builder works for each app. The step is done when every app boots, passes its smoke tests and serves its web process from the staging host.
Map Procfile processes, release phase and scheduled jobs
Confirm that each process type scales as intended with ps:scale, that a release process type replaces any Heroku Release Phase task, and that scheduled work is moved to cron tasks in app.json or to another scheduler you operate. Check the Procfile against Dokku's strict parsing rules, since a file that Heroku accepted may fail. The step is done when a staged deploy runs the release task once and the worker and scheduled jobs produce the same output as on Heroku.
Export Heroku Postgres and restore with dokku-postgres
Take a backup from Heroku Postgres, transfer it to the new host, and load it into a PostgreSQL service created with the dokku-postgres plugin. Link the service to the app so that DATABASE_URL is set, then compare row counts and run the application's own read and write checks. Confirm the PostgreSQL version the plugin installs against the plugin README before you schedule the restore. The step is done when a restored copy has passed data checks and the app runs against it in staging.
Re-create config vars and secrets on Dokku
Copy each Heroku config var into Dokku with config:set, grouped by app, and review the list for values that should not travel, such as credentials for services you are retiring. Rotate secrets that were exposed in logs, shared chats or former team members' machines. The step is done when a diff of variable names between the two platforms matches, and the staging app reads the values it needs without printing them in logs.
Stage the DNS cutover
Lower the TTL on production records in advance, point a test hostname at the Dokku host, and confirm the HTTPS certificate and proxy routing for each domain. Dokku ships nginx by default, with Caddy, HAProxy, OpenResty and Traefik as alternatives, so confirm the proxy you chose before the change. Cut over one app at a time, keep Heroku running until the new target has served live traffic for a period you agree in advance, and document the rollback path. The step is done when each domain resolves to Dokku and the rollback has been rehearsed.
Set up backups, monitoring and patching ownership
Before you retire Heroku, configure scheduled Postgres backups to S3-compatible storage, test a restore on a separate host, add uptime and log monitoring, and name the people who apply operating system and Dokku updates. Dokku is still versioned 0.x, so plan for upgrades and read release notes before applying them. Ask your contract team what Dokku Pro or any support arrangement would cover. The step is done when a restore test has succeeded and a runbook names an owner for each task.
Retire Heroku resources after sign-off
After the owning teams sign off, scale Heroku dynos to zero, export final data, and remove add-ons and the app once the retention you need is in place. Check your Heroku agreement, including any renewal date, notice period and whether your account is on a contract still offered, before you cancel anything. The step is done when Heroku billing shows no active resources for the migrated apps and the runbook and backups have been filed with your records.
Questions buyers ask before switching from Heroku to Dokku
How much effort and time does a move from Heroku to Dokku take?
The effort depends mostly on how many apps you run, how much of each app relies on Heroku-specific behavior, and how large your databases are. Dokku takes the same git push workflow and reads Procfiles and app.json, so simple buildpack apps move quickly. The work grows when you have many apps, custom add-ons without a Dokku plugin, large Heroku Postgres datasets to export and import, or DNS and certificate cutovers that must be coordinated. Ask any partner to break the scope down by app, data store and cutover step, so each part can be estimated and agreed in writing before work starts.
Can our internal team move from Heroku to Dokku without outside help?
Yes, a team with Linux and Docker experience can do it, and Dokku's documentation covers installation, deployment and plugins. The questions to answer honestly are whether anyone has run a server, configured a reverse proxy and TLS, restored a database and worked through an incident at night. Dokku's default proxy is nginx, with Caddy, HAProxy, OpenResty and Traefik as alternatives, so someone must own that layer. If those skills are thin, an outside partner can run the migration in parallel with your team while they learn the platform.
What does running Dokku ourselves require in skills, on-call and backups?
Running Dokku moves the platform duties that Heroku handled into your team. You take on server patching, Dokku and plugin upgrades, certificate renewal, monitoring, and capacity planning for the single host. Database backups are also your responsibility: the dokku-postgres plugin can run scheduled backups to S3-compatible storage, but you must set the schedule, storage location, retention and restore tests. Plan on-call coverage for host outages, and document who restores data and how long that takes, because Dokku does not restore your data for you.
Does Dokku handle scaling across multiple servers?
Dokku runs on a single server by default, and its default docker-local scheduler runs containers directly on that host. The k3s scheduler, introduced in Dokku 0.33.0, can build a multi-server K3s cluster, but it requires a Docker registry, and only the initial Dokku server is configured as the git push target. Teams with several hosts, high availability needs or heavy horizontal scaling should compare this with Kubernetes and confirm the operating model before committing. Ask for a written test of the k3s setup against your traffic and failover requirements.
Will our Heroku buildpack apps run on Dokku unchanged?
Many apps build without changes because Dokku's default builder, herokuish, implements Heroku's v2a buildpack specification, and Dokku reads Procfiles and a subset of app.json. Cloud Native Buildpacks, Nixpacks, Railpack and Dockerfiles are also supported, and each can produce different results. Check for Heroku-only features such as release-phase behavior, one-off dyno semantics, Heroku-specific environment variables and add-ons that have no Dokku plugin. Dokku's documentation notes that not all Heroku functionality is supported, so run a test build of every app before cutover.
How do we ask a partner for a fixed-scope quote for this migration?
Send a written inventory first: the apps and their process types, the Heroku add-ons in use, database sizes, required uptime windows, DNS and certificate ownership, and any compliance or data residency obligations. DeployOpen plans and implements self-hosted platforms in your own infrastructure and agrees scope, deliverables and timelines in writing before work starts, and does not publish a price list. Ask the partner to list each deliverable, the assumptions behind it, what you must provide, what is excluded, and whether ongoing support, upgrades and backup testing are priced as a separate retainer.
What recurring costs should we compare against Heroku dynos and Postgres?
Heroku bills dynos and database plans per month, so your Heroku invoice is the baseline. On Dokku, the recurring costs are the servers you rent or own, storage and backup storage, bandwidth, and the staff time spent on patching, monitoring and on-call. Dokku itself is MIT licensed, and the optional Dokku Pro is a separate commercial product to price on its own. Ask for each line item in a quote, including server sizing for your peak load, backup retention, and the hours assumed for upgrades and incident response.
What to confirm with your team before deciding
Start with build compatibility, because it decides whether Dokku can take your apps as they are. Dokku builds with the herokuish builder, Cloud Native Buildpacks through the pack CLI, a Dockerfile, or the Nixpacks and Railpack builders. Run a trial build of every app in a staging Dokku instance and compare the resulting process types, buildpack versions and any custom buildpack URLs against what Heroku uses today. Check your app.json closely too, since Dokku documents that not all Heroku functionality is supported. Any feature that fails should be listed as a rework item before the migration date is set.
Next, list every datastore your apps depend on beyond PostgreSQL. Dokku provides no datastores by default, so each Redis, search, queue or messaging dependency needs an official plugin or an external service, along with its own backup job and restore test. Confirm which add-ons your apps actually attach, which environment variables they read, and whether any app relies on a managed feature such as Heroku's point-in-time recovery. Scaling demand is the other open question: the default docker-local scheduler runs on one host, and the k3s scheduler needs a Docker registry and configures only the initial Dokku server as the git push target. If your load or availability needs point toward several servers, decide that now rather than after cutover.
Finally, agree on who owns backups, restores and compliance evidence. Run a restore test against a copy of production data and time it against your recovery objectives, because a backup that has never been restored is not yet a backup. Map the controls that Heroku handled for you, such as patching, network isolation and log retention, to named owners in your team, and confirm with your auditor or compliance lead which of them fall into your assessment scope. DeployOpen can help plan and document these checks, but the results should come from your own environment and your own assessors.
How DeployOpen helps you evaluate and move off Heroku
DeployOpen plans, implements and supports self-hosted open-source platforms inside your own infrastructure, so a Heroku vs Dokku decision can be tested against your real builds, databases and servers before anything changes. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory each Heroku app's buildpacks, Procfile, app.json, process types and add-ons before choosing a target
- Document which Heroku features your apps rely on and which Dokku plugins or workarounds cover them
- Agree the written scope, deliverables and timeline in writing before any migration work begins
How we build
- Install and harden Dokku on servers in your own cloud account, data center or air-gapped network
- Test builds with the herokuish, Cloud Native Buildpacks, Dockerfile or Nixpacks paths against your code
- Restore Postgres dumps into the dokku-postgres plugin, re-create config vars and verify DNS cutover steps
How we hand over
- Deliver runbooks for deploys, rollbacks, database restores and scaling past a single host
- Document backup schedules, S3-compatible storage targets and the restore tests your team should run
- Walk your platform and on-call staff through operations, with written records of every configuration choice
How we support
- Offer ongoing support, upgrades and patching of the Dokku host as a retainer if you want continuity
- Run security testing of the deployed applications and APIs on the same platform, as a separate scoped engagement
- Prepare systems, controls and evidence for your compliance assessments, while independent auditors issue any reports
