Moving CapRover one-click apps to another platform
- Step 1: inventory from Docker Swarm
- Step 2: map volumes to their data
- Step 3: export each app’s definition
- Step 4: decide per app
- Step 5: move data properly
- Step 6: recreate on the new platform
- Step 7: domains and certificates
- Step 8: keep the old host briefly
- Common surprises
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_dumpandpg_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--nameinternal 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