Skip to main content
CapRover and Towbar both run containers on infrastructure you control, but the configuration boundary is different. CapRover keeps much of the desired state in its control plane. Towbar expects workloads and their environment mappings to be reviewed in Git.

​
Compare the tradeoffs

​
Towbar

​
✅ Pros

  • Deployment configuration, environment mappings, and review history stay with the repository instead of only in the control plane.
  • Towbar records immutable deployment inputs and includes previews, Scout monitoring, deployment comparisons, vulnerability results, and database recovery history.
  • Each server remains an explicit deployment target, which makes workload and capacity ownership visible.

​
⚠️ Cons

  • Towbar has no Docker Swarm scheduler or automatic cross-node distribution.
  • It has no one-click application catalog. Every workload needs a reviewed App, Resource, or Compose declaration.
  • Its managed database and Compose support is narrower, and it requires more up-front configuration than a small CapRover installation.

​
CapRover

​
✅ Pros

  • CapRover offers a straightforward dashboard, CLI, one-click apps, automatic HTTPS, and several deployment inputs with little setup.
  • It uses Docker Swarm and can add worker nodes and distribute replicas.
  • Teams already comfortable with Captain definitions can keep a compact, Docker-native operating model.

​
⚠️ Cons

  • Much of the desired state lives in CapRover rather than in a complete repository declaration.
  • Docker Swarm is part of the runtime contract, which is a poor fit if you do not want to operate Swarm.
  • CapRover documents that apps with persistent data stay on one node, so adding cluster nodes does not make those workloads highly available.

​
1. Inventory CapRover

Record every app’s repository or image, Captain definition, build arguments, environment variables, container port, health check, instance count, domains, HTTPS settings, persistent directories, and service dependencies. Include one-click apps and databases even when you did not customize them. Create a CapRover backup for control-plane recovery, but treat application data separately. CapRover’s backup documentation notes that images and persistent directories are not included in the ordinary backup. Keep the source instance intact until Towbar has passed restore and cutover tests.

​
2. Translate workloads to Git

Create towbar.yml, add one entity file per workload, and map production and staging to their source branches. Do not copy generated CapRover state into the repository. Re-express only the configuration you intend to keep.

​
3. Recreate protected values and routes

Move application values into Towbar’s encrypted secret stores. Configure Git, registry, backup, notification, external-secret, or telemetry identities in the Towbar runtime environment. Rotate credentials when practical instead of carrying old shared values into the new control plane. Declare public domains and TLS in each workload manifest. Deploy first with a temporary hostname so production DNS remains untouched while you verify startup, health checks, background work, uploads, email, OAuth callbacks, and webhooks.

​
4. Move state and cut over

Use the database engine’s logical dump tools and restore into a matching Towbar database preset. For persistent directories, stop writers and copy files while preserving numeric ownership, permissions, links, and timestamps. Verify reads and writes from the destination container. At cutover, freeze source writes, repeat the final data transfer, test the restored state, then change DNS. Confirm TLS, deployment health, logs, notifications, and a manual Towbar backup. Retain the stopped CapRover instance for the agreed rollback window and account for any writes accepted by Towbar before reversing traffic. Continue with Your first deployment, Resources, and Database restores.
Last modified on September 22, 2026