Move apps from another platform

Deploy the appCopy Anchor Link

How depends on how it runs on your old platform:

• A common app such as Umami: open New project, choose Template and pick it. The Umami template adds Umami and a managed PostgreSQL 17 database, connects them, generates APP_SECRET and deploys.
• A docker-compose.yml: import the Compose file. Well-known database images become managed databases, so you can import their data in the next steps.
• Your own code: import the repository. launchroom detects how to build it.

Pick the same database engine and the same or a newer major version as on your old platform: a dump only imports into the same or a newer version.

On its first start, Umami creates its tables. That's expected: the import replaces them.

Copy the variablesCopy Anchor Link

Write the app's variables to a .env file on your old server:

docker exec umami env > umami.env

Remove what launchroom sets itself: PATH, HOSTNAME, HOME, the database's address and credentials (DATABASE_URL, DB_HOST and similar come from the connection), and anything the image sets itself (NODE_VERSION and similar).

Open the service's Variables tab and paste the file or choose Import .env. launchroom shows a preview with conflicts and suggests which values to keep as secrets. Deploy to apply them. From a terminal, launchroom env set KEY=VALUE… adds variables (staged) and launchroom deploy --staged applies them.

Umami's secretsCopy Anchor Link

Umami 3.4 reads one secret, APP_SECRET. When it isn't set, Umami derives it from DATABASE_URL. It signs sign-in tokens, share links and the tracker's cache tokens, and it is part of how Umami hashes visitor sessions. The data doesn't depend on it, but with a new secret everyone signs in again, shared links stop working and visitors in the current month count as new sessions. Copy these from your old server when they are set:

• APP_SECRET
• TWO_FACTOR_ENCRYPTION_KEY: Umami encrypts two-factor secrets with it. Without it, users with two-factor sign-in can't sign in.
• SALT_ROTATION, if you changed it.

If your old app had no APP_SECRET, its secret came from its old DATABASE_URL. Keep the generated one; everyone signs in once more. Older Umami versions used HASH_SALT. Umami 3.4 doesn't read it.

Import the databaseCopy Anchor Link

Find the database container and its user and database name:

docker ps --format '{{.Names}}\t{{.Image}}'
docker exec umami-db env | grep -E '^(POSTGRES|MYSQL|MONGO)'

Dump it with the engine's own tool. The dump streams to a file on your old server:

# PostgreSQL: custom format, compressed
docker exec umami-db pg_dump -Fc -U umami umami > umami.dump

# MySQL or MariaDB (password from the container's env)
docker exec shop-db sh -c 'exec mysqldump --single-transaction --routines --triggers -u"$MYSQL_USER" -p"$MYSQL_PASSWORD" "$MYSQL_DATABASE"' | gzip > shop.sql.gz

# MongoDB
docker exec chat-db mongodump --archive --gzip --db chat -u app -p '<password>' --authenticationDatabase admin > chat.archive

To dump inside the container instead, write to /tmp and copy it out: docker exec umami-db pg_dump -Fc -U umami -f /tmp/umami.dump umami, then docker cp umami-db:/tmp/umami.dump .. Copy the dump to the machine you upload from, for example with scp.

On launchroom, open the database on the canvas and go to Backups → Move data → Import data…. Drop the dump in. The upload resumes if your connection drops. launchroom shows what it found ("PostgreSQL custom dump · from PostgreSQL 15.8") and what the database holds now.

Umami already created its tables, so choose Replace everything. launchroom takes a safety snapshot, stops Umami, drops and recreates the database, imports the dump and starts Umami again. Type the database's name to confirm.

From a terminal, with a token that has the data:transfer ability:

launchroom db import postgres umami.dump --replace

When the old database is reachable from the internet, From a connection URL copies it directly without a dump file. See Import and export for formats, version rules and what launchroom adjusts in a dump.

Import filesCopy Anchor Link

If the app keeps uploads or other files on disk, add a volume at the same path on the service (Settings → Volumes) and deploy. Then pack the folder on your old server:

docker exec app tar -czf - -C /app/uploads . > uploads.tar.gz

In the service's Backups tab, choose Import files… next to the volume and upload uploads.tar.gz. Owners and modes from the archive are kept, or set one owner for all files if the image runs as a non-root user. See Import files into a volume.

Check the appCopy Anchor Link

Open the app on its generated address. For Umami: sign in with your old account and check that your websites and their history are there. Check the service's logs for errors.

Switch DNSCopy Anchor Link

Add your domain to the service and point its DNS record at launchroom. launchroom issues a certificate once the record resolves. With a low TTL, traffic moves within minutes. The Umami tracking script on your sites keeps working because the domain stays the same.

Requests that reach your old platform between the dump and the switch stay there. To move without that gap, stop the app on your old platform, take a fresh dump, import it again with Replace everything and switch DNS right after.

Clean upCopy Anchor Link

Once traffic reaches launchroom (check the service's metrics) and you're sure:

• Stop the app on your old platform, and keep its last dump until launchroom has taken its first scheduled backups.
• Raise the DNS TTL again.
• Remove umami.env and the dump files from your machines: they hold secrets and data.