> ## Documentation Index
> Fetch the complete documentation index at: https://www.towbar.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Migrate from Dokku

> Move Dokku apps, process types, config, data services, domains, and storage to Towbar.

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](https://dokku.com/docs/getting-started/installation/).
* 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](https://dokku.com/docs/advanced-usage/backup-recovery/)
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

| Dokku concept               | Towbar destination                                                       |
| --------------------------- | ------------------------------------------------------------------------ |
| Buildpack or Dockerfile app | Towbar App using a supported source builder or Dockerfile                |
| `web` process               | Public App with a declared container port and health check               |
| Worker process              | Separate private App using the same source and an explicit start command |
| Scheduled command           | App job with an explicit schedule and command                            |
| Official datastore plugin   | Compatible managed database Resource                                     |
| Mounted app storage         | Declared App volume                                                      |

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](/docs/platform-deployments), [Database guides](/docs/databases),
and [Domains and TLS](/docs/domains-tls).