Moving CapRover one-click apps to another platform

How to inventory and migrate CapRover one-click apps, volumes and captain definitions to a different deployment setup.

CapRover’s one-click apps make it easy to start a database, a wiki or an analytics tool in seconds. Years later, those same apps are the hardest part of a migration, because nobody remembers how they were configured. Here is a methodical way to move them.

Step 1: inventory from Docker Swarm

CapRover runs on Docker Swarm, so the truth is in Swarm, not the dashboard:

docker service ls
docker service inspect srv-captain--myapp --pretty

For each service, record the image and tag, environment variables, published ports, volumes and resource limits.

Step 2: map volumes to their data

CapRover persistent directories are Docker volumes named after the app. Find them:

docker volume ls | grep captain

Note which app owns which volume. This is the data you must not lose.

Step 3: export each app’s definition

For apps deployed from your own code, the captain-definition file in the repo tells you the build method. For one-click apps, the template lives in CapRover’s one-click repository; find the matching template to see the intended configuration, then compare with what is actually running.

Step 4: decide per app

  • Still needed and actively used: migrate.
  • Used, but a managed or simpler option exists: replace.
  • Nobody remembers it: take a backup, stop it for two weeks, delete if nobody complains.

Step 5: move data properly

For databases, do not copy volume files between hosts while running. Use the database’s own tools:

  • Postgres: pg_dump and pg_restore
  • MySQL or MariaDB: mysqldump
  • MongoDB: mongodump

For file volumes, stop the app and tar the volume, or use rsync over SSH.

Step 6: recreate on the new platform

Recreate each app with the same image tag first, not the latest. Match environment variables, then restore data. Upgrade versions only after the migration is stable.

Step 7: domains and certificates

CapRover routed domains through its Nginx. On the new setup, add the same domains, lower DNS TTLs a day ahead, switch records, and verify certificates are issued.

Step 8: keep the old host briefly

Leave CapRover running read only for a week. Then snapshot the server and shut it down.

Common surprises

  • Apps relying on the srv-captain--name internal hostnames for service discovery
  • Custom Nginx config added through the dashboard
  • Swarm overlay networks that the new setup does not use

A broader look at where CapRover still fits and where teams outgrow it is in this CapRover vs Peon comparison.

Disclosure: I work on Peon.


Write a comment