Skip to main content
A Dokploy installation cannot be imported directly into Towbar. Recreate the desired workload configuration in Git, move persistent data through supported backup or file-transfer paths, verify the destination without production traffic, and cut over only after the new deployment is healthy.

​
Decide whether Towbar fits

Review actual requirements rather than migrating for feature-count parity. A general Docker or Compose feature in Dokploy may be intentionally restricted by Towbar’s deployment policy.

​
1. Inventory Dokploy

For each project and environment, export or record:
  • application source, provider, repository, branch, build path, Dockerfile, build type, commands, and image;
  • Compose files and every override, profile, build, network, volume, label, port, and dependency;
  • domains, certificates, internal ports, health checks, resource limits, and deployment policy;
  • project, environment, and service variables, including all ${{project.*}} and ${{environment.*}} references;
  • databases, users, versions, backup destinations, schedules, and latest restore evidence; and
  • cron jobs, webhooks, notifications, registries, external secrets, monitoring, and log destinations.
Dokploy supports project-, environment-, and service-level variables. Resolve every reference to its intended Towbar scope before removing the source installation.
Dokploy’s server backup protects the Dokploy control plane. Treat each application volume and database as a separate migration concern.

​
2. Convert configuration to Git

Create a towbar.yml root file and one entity file for each app or resource. Map Dokploy environments to Towbar environments and branches. Store configuration in the manifest and values in Towbar’s encrypted secret stores. Towbar’s Compose policy is stricter than a general Dokploy Compose project. Remove unsupported host bindings, Docker socket access, privileged mode, remote includes, explicit public host ports, and external namespaces, or keep that workload outside Towbar. Dokploy manages application and Compose domains through Traefik. In Towbar, declare domains per environment in Git, then use direct DNS or the configured Cloudflare path described in Domains and TLS.

​
3. Recreate integrations and secrets

Configure the Towbar host environment for the Git provider, registry, backup storage, notifications, log forwarding, and any external-secret provider. Towbar exposes only valid, enabled integrations in the dashboard. Move variable values into Shared secrets or workload environment secrets. Preserve build/runtime intent and preview isolation rather than copying every Dokploy variable into one global scope. Rotate credentials where practical, and update OAuth callbacks, Git webhooks, CI secrets, DNS automation, email allowlists, and receiving webhooks.

​
4. Deploy without production traffic

Register and prepare a Towbar server. Deploy stateless services with temporary domains and automatic deployment disabled. Verify:
  • the intended commit or image digest;
  • build output, startup command, health check, and logs;
  • service discovery and private network aliases;
  • outbound access, background jobs, webhooks, and provider credentials; and
  • CPU, memory, disk, and startup-time headroom.
Do not reuse production domains until the destination works independently.

​
5. Move databases and files

Dokploy documents S3-backed database backups and database restores. Confirm the exact dump command, compression, engine, and major version before using an archive as a Towbar recovery point. When formats do not match, restore into a temporary database of the same engine first, then create a new logical export supported by the destination. For persistent application files, stop writes, copy the data into the destination volume while preserving numeric ownership and permissions, and verify the container can read and update it. Do not copy a running database volume as a migration shortcut.

​
6. Cut over

  1. Schedule a write freeze or maintenance window.
  2. Create the final logical database backup and file synchronization.
  3. Restore and verify representative data before starting dependent workers.
  4. Exercise login, reads, writes, uploads, jobs, queues, email, OAuth, webhooks, and backup creation through a temporary hostname.
  5. Assign production domains in the Towbar manifest and update DNS when the server address changes.
  6. Confirm TLS, deployment health, logs, notifications, and restore readiness.
Keep Dokploy stopped but unchanged during the rollback window. If the destination accepts production writes, account for them before returning traffic to the old deployment.

​
Migration checklist

  • Projects, environments, services, variables, domains, jobs, volumes, and dependencies are inventoried.
  • Every workload maps to a supported Towbar deployment mode.
  • Compose files pass Towbar policy validation.
  • Provider and secret scopes have been recreated without copying encrypted control-plane data.
  • Database archives and persistent files have been restored and checked on a disposable target.
  • Temporary-domain tests cover user, background, and provider flows.
  • Cutover, data freeze, rollback, and source-retention windows are documented.
Continue with Core concepts, Your first deployment, and Database restores.
Last modified on September 22, 2026