Skip to main content
Dokku accepts Git pushes and derives runtime behavior from buildpacks, Dockerfiles, Procfiles, plugins, and host configuration. Towbar connects to the source repository, validates a declarative manifest, and records immutable deployment inputs. Plan the move as a configuration and data migration rather than a host copy.

​
Compare the tradeoffs

​
Towbar

​
✅ Pros

  • Towbar provides a web control plane for several servers, with Repository sync, previews, monitoring, incident history, vulnerability results, and team roles built into the product.
  • Workload declarations are validated in Git and deployments retain immutable source and image identities.
  • Apps, databases, backups, restores, notifications, and audit history use one model instead of a collection of unrelated plugins.

​
⚠️ Cons

  • Towbar is heavier to install and operate than a small Dokku host.
  • It supports a narrower set of extensions and rejects deployment patterns outside its manifest policy.
  • Towbar does not reproduce Dokku’s direct git push workflow or its large plugin ecosystem.

​
Dokku

​
✅ Pros

  • Dokku is a lean, CLI-native PaaS that can build from a Git push with Buildpacks or a Dockerfile on a single server.
  • Procfile process types, config commands, and datastore plugins feel familiar to teams coming from Heroku.
  • Its plugin system lets an experienced operator assemble only the capabilities a host needs.

​
⚠️ Cons

  • The default scheduler manages one server. Multi-node operation needs another scheduler and a more complex architecture.
  • Operational state is spread across host commands, app config, storage mounts, proxy settings, and plugins rather than one reviewed repository contract.
  • Plugin compatibility, upgrades, backups, observability, and access control remain the operator’s responsibility.

​
1. Inventory apps and plugins

For every app, record the Git source and branch, builder, Dockerfile, Procfile process types, config, domains, proxy settings, scale, checks, storage mounts, networks, scheduled tasks, and linked services. List every plugin and determine whether it supplies runtime behavior, a datastore, or only operator tooling. Dokku’s backup and recovery guide recommends keeping repositories, static assets, and tested datastore dumps. It also warns that filesystem copies of running datastores may be inconsistent.

​
2. Map the runtime model

Commit towbar.yml and one file per workload. A Procfile with several long-lived process types usually becomes several Apps so each process can have independent health, scaling, limits, and operational history.

​
3. Move config and integrations

Copy the names and intended scope of Dokku config values, then enter the values in Towbar’s encrypted secret stores. Do not commit output containing secrets. Recreate registry access, notifications, log forwarding, external secrets, and DNS automation through Towbar’s environment-configured integrations. Deploy to temporary domains. Verify the exact image or commit, process command, health check, internal service names, outbound access, jobs, queues, webhooks, and resource headroom.

​
4. Move databases, files, and traffic

Use each Dokku datastore plugin’s export command. For example, the official PostgreSQL plugin can create a logical export that you restore into a compatible Towbar PostgreSQL Resource. Match engine and major version before relying on a dump. Move persistent files only after stopping writers and preserve ownership and permissions. Freeze source writes, take the final exports, restore and verify representative records, then update domains or DNS. Keep Dokku stopped but available until the rollback window closes. If Towbar accepts new writes, reconcile them before returning traffic to Dokku. Continue with Deployment modes, Database guides, and Domains and TLS.
Last modified on September 22, 2026