Which should a team choose, App Platform or Dokku?
App Platform fits teams that want DigitalOcean to run builds, containers and managed databases, while Dokku fits teams that accept running one server themselves. The choice turns less on features than on who carries the operating work. Start by deciding who will patch the host operating system, apply Docker and Dokku updates, watch disk and memory, and restore backups when something fails. On App Platform that work sits with the provider for the build and runtime layers. On Dokku it sits with your team, on a single machine that you provision and secure. Three questions usually settle it. First, does the team need managed database services with provider-run backups and failover, or is it comfortable operating PostgreSQL through Dokku plugins such as the official dokku-postgres plugin, which can run backups to S3-compatible storage? Second, how much on-call time can the team give to the host? Dokku's single-server design means a host failure takes every app on it offline until you recover it. Third, what does a renewal or price change actually cost once you list every component, including containers, bandwidth, databases and the staff hours that a self-run server consumes. Ask DigitalOcean for a written quote for your exact container sizes and database tier, and build a matching estimate for the Droplet, storage, backup storage and engineering time before comparing totals.
A practical test is to deploy one representative service on each platform and time the work you actually perform: a Git push, a rollback, a database restore to a new host and a failed-build investigation. Check which build path your app needs. Dokku supports Cloud Native Buildpacks through the pack CLI, Dockerfile builds, and the herokuish builder, so confirm that your buildpack or Dockerfile works before committing. Confirm also whether your team will need the k3s scheduler for more than one server, since the documentation says only the initial Dokku server is the git push target. If you expect several servers, multi-host operations may change the decision.
Choose App Platform if the team's priority is fewer operational duties and it accepts the provider's pricing model and feature set. Choose Dokku if the team has Linux operations skills, wants full control of the host and data location, and has a documented plan for backups, restores and patching. Whichever you pick, write down the owner for each recurring task before migration, because the sibling pages on moving from App Platform to Coolify and on cost of ownership assume those owners are already named.
Which platform fits which team and situation
This table maps common team situations to the platform that usually fits better, with the condition that drives the choice. Read each row against your own constraints: App Platform shifts host operations to DigitalOcean, while Dokku keeps the host, data and operating work under your control on one server.
| Team situation | Better fit | Why |
|---|---|---|
| Small team with one or two apps | App Platform | If nobody wants to run a server, App Platform handles builds and runtime from a Git source without a host to maintain. |
| Team with a Heroku-style Procfile workflow | Dokku | Dokku reads Procfiles and supports a release process type similar to Heroku's Release Phase, so existing process definitions carry over more directly. |
| Team that must keep data on its own server | Dokku | Dokku runs on a single server you choose, and database plugins store data on that host or in S3-compatible storage you operate. |
| Team that wants managed databases with backups handled by the provider | App Platform | Dokku provides no datastores by default, so a team needs the Postgres or other plugin plus its own backup schedule and restore testing. |
| Team with no one to patch servers | App Platform | Dokku runs on a host you manage, including OS updates, Docker, the proxy and plugin upgrades, so this fit depends on an operator being available. |
| Team running several services on one host | Dokku | Dokku can run several apps and process types on one server, but a 1 GB RAM minimum for the default scheduler and shared host capacity must be sized by you. |
| Team needing rollback that restores data | Confirm before choosing | Rolling back a retained image does not restore databases or persistent files on either platform, so confirm your backup and restore process in both. |
How Cloud Native Buildpacks, Dockerfiles and Procfiles behave on Dokku
Dokku decides how your app becomes a container at deploy time, and that choice sets your runtime versions, your build failures and your upgrade effort. The cards below cover each build path Dokku documents and the Procfile rules that decide which processes run, so you can check them against the App Platform builds you run today.
herokuish buildpack builds
The default Dokku builder runs Heroku's v2a buildpack specification through herokuish, so apps that deployed on Heroku-style buildpacks often build with little change. The team must confirm that the buildpack it relies on supports the language version in its lock file, because herokuish builds pull buildpack versions that can differ from the ones App Platform uses for the same runtime. Test one build from a clean clone before cutover.
Cloud Native Buildpacks through pack
Dokku can build with Cloud Native Buildpacks, but the CNB builder defaults to a stack based on heroku/builder:24 and needs the pack CLI installed on the host separately. Installing and updating pack is a host maintenance task that App Platform handles for you. Check that your runtime and native dependencies are supported on that stack, and record the pack version so a rebuild months later produces the same image.
Dockerfile builds
When a Dockerfile is present, Dokku builds from it, which gives you full control over base images, system packages and multi-stage builds. The trade-off is that you own image patching, so a base image update is a change your team must schedule and test. Confirm that the Dockerfile builds on the Dokku host architecture, AMD64 or arm64, and that it does not depend on build secrets that App Platform injected through its own settings.
Nixpacks and Railpack builders
Dokku documents Nixpacks from version 0.32.0 and Railpack from version 0.37.0 as builders, selected when the repository contains a nixpacks.toml or railpack.json file. These builders detect the language and generate the build plan, which is convenient for teams without a Dockerfile but makes the build output harder to predict. Pin the builder version in your configuration, and compare the generated start command and exposed port with what App Platform runs today.
Procfile process types and scaling
Dokku reads a Procfile under procfile-util strict mode rules and scales the web process to 1 on the first deploy, so a worker or cron-style process will not start until you scale it. Use ps:scale to set each process type, and map every App Platform component, including workers, to a Procfile line. Check that the release process type, which works like the Heroku Release Phase, runs your migrations before the new version takes traffic.
Unsupported manifest features
Dokku reads an app.json manifest for deploy scripts, cron tasks, process formation and healthchecks, but its documentation states that not all Heroku functionality is supported. Any App Platform setting that lives in the app spec, such as health check paths, alerts or deploy-time jobs, must be translated by hand and tested. Treat each setting you cannot map as a gap to resolve before migration, not as a silent default.
Capability comparison from documented facts
This table sets DigitalOcean App Platform against Dokku on a single server across build methods, process types, datastores, licensing, hosting and host requirements. Where no researched fact covers an App Platform detail, the cell says to confirm it with DigitalOcean, so treat those rows as a checklist for your procurement call. The main takeaway is that Dokku gives you control over the host and data, and in exchange you own the server, patching and backups.
| Capability | DigitalOcean App Platform | Dokku |
|---|---|---|
| Build methods | Buildpacks or Dockerfiles; confirm the current buildpack stack with DigitalOcean | herokuish, Cloud Native Buildpacks via the pack CLI, Dockerfile, Nixpacks, Railpack, Lambda or null builder |
| Process types | Confirm process types and component model in the App Platform app spec with DigitalOcean | Procfile process types, a release process type, and scaling with ps:scale |
| Datastores | Managed DigitalOcean databases; confirm supported engines and add-on options with DigitalOcean | No datastore by default; official plugins such as dokku-postgres, Redis, MySQL and MongoDB |
| Licensing | Proprietary managed service; confirm terms with DigitalOcean | MIT license |
| Hosting model | Managed platform run by DigitalOcean | Runs on a single server you operate; default docker-local scheduler |
| Reverse proxy | Managed by the platform; confirm routing and TLS behavior with DigitalOcean | nginx by default; Caddy, HAProxy, OpenResty and Traefik as alternatives |
| Minimum host requirements | Not applicable; no host to size. Confirm plan and container sizes with DigitalOcean | Ubuntu 22.04, 24.04 or 26.04, or Debian 11 or later on AMD64 or arm64; 1 GB RAM for the default Docker scheduler |
| Multi-server scaling (k3s) | Confirm scaling options with DigitalOcean | k3s scheduler from 0.33.0 builds a multi-server cluster but requires a Docker registry, and only the initial server is the git push target |
| Current version | Managed service; no self-managed version to track | v0.38.31 per GitHub releases; still versioned 0.x |
How datastores move from DigitalOcean databases to Dokku plugins
Dokku provides no datastores by default, so the database that a DigitalOcean managed database supplies today has to be added as an official plugin on the Dokku host. The plugins cover Postgres, MySQL, MariaDB, Redis, Mongo and several others. Creating a service and linking it to an app sets the app's DATABASE_URL, which means the application code that already reads that variable on App Platform usually needs no change. Before you start, list every connection string, environment variable and extension your app depends on, because the Postgres version, extensions and connection limits on the plugin are yours to match, and you should confirm the same details for your current App Platform database with DigitalOcean.
The dokku-postgres plugin installs PostgreSQL 18.6 by default, so check the version your App Platform database runs before you choose the default, and pin a version that matches. The plugin exports and imports databases with postgres:export and postgres:import, which handles one-time cutover dumps, and it can run one-off or scheduled backups to S3-compatible storage. Those backups are only useful if you test them. Plan a restore into a scratch database on a separate host, time it, and check row counts and application behavior, because a backup that has never been restored is an unverified assumption.
The core trade-off is who carries the operating work. A managed database moves patching, failover and backup scheduling to the provider, while a Dokku plugin leaves those tasks with your team: applying Postgres minor releases, planning major upgrades, monitoring disk and connections, and owning the recovery runbook. Ask DigitalOcean to confirm what its managed database provides for backup retention, point-in-time recovery, high availability and version support, and compare those answers with the plugin's behavior in your own environment before you decide. A single Dokku server also has no built-in failover, so a database failure there is a restore event, not a switchover.
Where data lives and what the licenses allow
DigitalOcean App Platform runs in DigitalOcean's managed environment, so application code, build artifacts, environment variables and any attached databases sit in the provider's infrastructure, and the provider's terms of service and data processing terms govern that data. Before committing, the team should read those terms for the region options available to them, the data retention and deletion commitments, and where logs and build outputs are stored. Confirm these with DigitalOcean directly, since your data residency obligations may depend on exact terms rather than general statements.
Dokku runs on a server you choose. That server can sit in your own cloud account, in a DigitalOcean Droplet you already govern, or in an on-premises data center. Application data, the Docker images built on the host, and any datastore plugins stay on that machine and on storage you attach to it, so the residency decision becomes an infrastructure decision you make and document. The MIT license in Dokku's LICENSE file permits commercial use, modification and redistribution without a copyleft obligation on your applications. Dokku Pro is offered at Dokku Pro, but its licensing terms and feature list are separate from the MIT-licensed core, so confirm in writing what Pro adds and what it costs before depending on any Pro-only capability.
For compliance work, DeployOpen prepares systems, configuration, access records and evidence for assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies assess your controls, whichever platform you run. With App Platform, part of the evidence comes from the provider's own attestations, which you should request and map to your control set. With Dokku, you own every control on the host, including patching, access, backups and logging, and that evidence must be produced from your environment.
What moving from App Platform to Dokku involves
The sequence turns App Platform's managed builds, components and managed databases into a single Dokku host that your team patches, backs up and monitors. Each step ends with a check so the cutover can be reversed if a check fails.
Inventory apps, components and environment variables
Your team exports each App Platform app spec with DigitalOcean's tooling and confirms that the export matches what the console shows, including services, workers, jobs, routes and environment variables. Secrets are listed separately because they must be re-entered on Dokku with dokku config:set. The step is done when every app has a written list of components, build settings, domains and secrets, and each secret has an owner who can supply it.
Confirm build path and process types
For each component, the team records whether App Platform builds from a buildpack or a Dockerfile and maps that to a Dokku builder: herokuish, Cloud Native Buildpacks through the pack CLI, or a Dockerfile. Procfile process types are checked against Dokku's strict Procfile rules, and any worker or job that App Platform runs separately is given its own process type or scheduled task. The step is done when each component has a named builder and a Procfile entry, and any gaps are listed as open issues.
Provision and harden the Dokku host
Your operations team provisions a server on a supported Ubuntu or Debian release, confirms it has the RAM that Dokku's installation documentation requires for the default Docker scheduler, and applies your standard hardening baseline, including SSH key access, firewall rules and automatic security updates. The host is documented with its size, region and owner. The step is done when the host passes your baseline review and the Dokku installation completes on a clean machine.
Install Dokku and configure the proxy
Your team installs Dokku, registers SSH keys for the git push remote, and chooses a reverse proxy. Dokku ships nginx by default, with Caddy, HAProxy, OpenResty and Traefik as alternatives, so the choice is made against your TLS and routing needs. Domains are attached to a test app before any production DNS changes. The step is done when a test app deploys by git push, responds on a test hostname with valid HTTPS, and the proxy configuration is saved in version control.
Rebuild and test each app on Dokku
Each app is pushed to Dokku and built, and your team compares the result with the App Platform build log and runtime behavior. Keys in app.json are checked one by one, because Dokku supports only part of Heroku's manifest format and unsupported keys must be found in testing and handled by hand. The step is done when each app passes its functional tests, health checks respond, and every unsupported app.json key has a documented replacement.
Move databases and verify restored data
Each managed database is exported from DigitalOcean, created as a Dokku service through the matching plugin, and restored with the plugin's import command. Linking the service sets DATABASE_URL on the app, so connection settings are checked after linking. Row counts, key queries and application-level checks confirm that the data matches the source before any writes move to the new database. The step is done when the restored data matches the source on agreed checks and the application runs against it in a test environment.
Set up and test backups to S3-compatible storage
Your team configures scheduled database backups to an S3-compatible bucket, sets retention to match your recovery policy, and extends backups to any persistent files or volumes that App Platform did not hold for you. A restore is performed into a separate environment and the result is checked against the source. Backups are not treated as working until a restore has succeeded. The step is done when at least one full restore has been tested end to end and the runbook names who performs restores.
Switch DNS with a rollback path
Before the change, your team lowers DNS time to live where your provider allows it, records the current App Platform records, and keeps the App Platform app running as a fallback. DNS is switched to the Dokku host in a planned window, and the health checks and key user journeys are watched. If a check fails, the records are pointed back to the App Platform app. The step is done when traffic is served by Dokku, the rollback has been rehearsed, and the change is logged.
Retire App Platform resources
After an agreed observation period, your team removes the App Platform apps, databases and any dedicated egress or container resources that are no longer needed, and confirms the final invoice with billing. Credentials used for the migration are rotated, and the Dokku host's ownership, patch schedule and monitoring are handed to the team that will operate it. The step is done when the old resources are deleted, the billing line items stop, and the operations runbook is signed off.
Questions buyers ask before switching from App Platform to Dokku
How much effort does moving from App Platform to Dokku take?
The effort depends mainly on how many apps you run, how many use a database, and how much of your build setup relies on App Platform-specific settings. Dokku builds apps from a Dockerfile, Cloud Native Buildpacks, or Procfile-based herokuish builds, so a standard web app with a Dockerfile or a supported buildpack moves with fewer changes. The work that usually takes the most time is:
- Recreating environment variables, domains and health checks
- Moving each database and validating its data after import
- Testing deploys, scaling and cutover on a server you have provisioned
Ask DigitalOcean to confirm which App Platform app spec settings have no direct equivalent in your apps before you plan the cutover.
Can our team migrate to Dokku without outside help?
Yes, a team with Linux server administration skills and experience with Docker can run Dokku itself, since the project documents installation on supported Ubuntu and Debian releases. The harder part is the operating model around it. Your team would own the server, the reverse proxy configuration, TLS, backups, upgrades and monitoring, all of which App Platform handles for you. If those responsibilities are new to your staff, a fixed-scope engagement with DeployOpen can plan, implement and document the setup, and hand over runbooks your team can follow.
What ongoing operating work does Dokku add?
Dokku adds the platform layer that a managed service normally carries. Plan to own these recurring tasks:
- Patching the host operating system and Docker
- Keeping the Dokku release current, noting that it is still versioned 0.x
- Managing the proxy, which uses nginx by default, with Caddy, HAProxy, OpenResty and Traefik as alternatives
- Running and testing backups, and monitoring disk, memory and container health
Each of these needs an owner and a schedule before go-live. Confirm your monitoring and alerting approach in advance.
Does Dokku scale across multiple servers like App Platform?
Not in the same way. Dokku's default docker-local scheduler runs containers on the single Dokku host. Multi-server operation is available only through the k3s scheduler, which requires a Docker registry, and only the initial Dokku server is configured as the git push target. If your current App Platform setup depends on scaling across machines or on managed autoscaling, treat that as a design change, and confirm the specifics of your workloads with a partner before committing.
How do database backups on Dokku compare with DigitalOcean managed databases?
DigitalOcean managed databases provide backups and maintenance as a managed service, while Dokku relies on plugins. The official dokku-postgres plugin supports export and import, and one-off or scheduled backups to S3-compatible storage. Your team would configure the schedule, retention, off-site copies and restore tests, and must verify restores regularly. Ask DigitalOcean to confirm its current backup retention and point-in-time options so you can compare them with the backups you design.
Does our data stay in our own account after the move?
Yes, with Dokku the application containers, databases and backups run on servers in your account or data center, and the project does not host your data. Your data location then depends on where you provision the server and where you send backups. Confirm the region, provider contracts and backup destination in writing, and check any residency or retention rules that apply to your organization.
Which license applies to Dokku, and what does it allow?
Dokku is released under the MIT license, and its LICENSE file carries a 2014 copyright by Jeff Lindsay. The MIT license permits use, modification and redistribution, including commercial use, subject to keeping the copyright and license notice. Have your legal or procurement team review the license terms for the plugins and any commercial add-on you choose, since each component may carry its own license.
What should we ask a partner for in a fixed-scope quote?
Ask for a written scope that lists the apps, databases, domains, environments and cutover window included. Request deliverables such as the server build, proxy and TLS configuration, backup and restore tests, monitoring setup, runbooks, and a handover session. Also ask what is excluded, how rollback works, what happens if the scope changes, and whether ongoing support or upgrades are offered as a separate retainer. DeployOpen does not publish a price list, so a quote follows from the written scope.
How DeployOpen helps evaluate, implement and migrate Dokku
DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a move from DigitalOcean App Platform to Dokku, we start with the written scope so the decision about builds, datastores and operating work rests on your apps and your environment.
How we scope
- Inventory each App Platform component, build method, route and datastore before choosing a Dokku layout.
- Agree in writing which apps move to a single Droplet and which, if any, stay on App Platform.
- Confirm the Dokku plugins, backup targets and proxy choice that your data and uptime requirements call for.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed before work starts.
How we build
- Set up the Dokku host, Docker, the reverse proxy and the pack CLI on servers in your environment.
- Verify Procfile process types, release phase behavior and app.json settings against each application.
- Configure datastores with official Dokku plugins and test restores, not only backups.
- Document the build path, environment variables, domains and HTTPS renewal for your operators.
How we hand over
- Deliver runbooks for deploys, rollbacks, scaling with ps:scale and host maintenance.
- Walk your platform and security teams through patching, Dokku upgrades and access control.
- Provide test evidence and configuration records that your auditors or assessors can review.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover Dokku version upgrades, plugin updates and periodic backup restore tests.
- Ask any provider to confirm who answers host incidents, patch windows and after-hours escalation.
