Moving an app you already run somewhere else

If you are already running something on a VPS or at home, you do not have to start over. Deploy the same app here, bring your data across, and carry on.

The shape is the same for almost every app:

1. Deploy the app here and open it once, so it creates its own structure.
2. Copy your files in over SFTP.
3. Import your database.
4. Restart the app.

Before you start

Take a copy of everything on the old machine first. Not because anything here will damage it, but because a migration you can retry is a much calmer afternoon than one you cannot.

Deploy the same major version where you can. Most apps will upgrade their own data on first start, but almost none will downgrade it. Going from an older version to a newer one is normal; going backwards usually is not.

Step 1: your files

Open the app and go to the Files tab. It gives you SFTP details for that app's own storage, which you can use with FileZilla, WinSCP, Cyberduck, sftp, rsync or anything else.

Copy your old data into the same folders the app created here. If your old install kept uploads in data/uploads, they belong in data/uploads here too.

Two things that catch people out:

• Copy the contents, not the folder. Dropping uploads/ inside uploads/ leaves you with uploads/uploads, and the app will report everything as missing.
• Stop the app first if you are replacing a lot at once. An app writing to files while you overwrite them can leave you with a mix of both. Stop it from the Overview tab, copy, then start it again.

Step 2: your database

If your app has a managed database, the Database tab both exports and imports.

On your old machine, take a dump:

# MySQL or MariaDB
mysqldump -u USER -p DATABASE > backup.sql

# PostgreSQL
pg_dump -U USER DATABASE > backup.sql

Then use Restore on the Database tab and give it that file. Your app is stopped while the import runs and started again afterwards, so you do not need to do anything around it.

The app must be running before you start a restore. That reads oddly when you are importing into a fresh install, but the import runs against the live database container, so the stack has to be up first.

Dumps are limited to 64 MB. That is plenty for most apps -- a busy forum's database is usually a few megabytes -- but a large Nextcloud or a long-running Immich can exceed it. If yours is bigger, open a ticket and we will do it from our side rather than have you split the file.

Making a dump smaller

Most of the size in a big dump is history you may not need:

• Exclude cache and session tables. They rebuild themselves.
• Some apps keep logs or audit trails in the database and offer a way to prune them before export.
• gzip does not help here -- upload the plain .sql.

Step 3: point your domain at it

Once the app looks right, move your domain. The Domain tab takes your own domain and issues a certificate automatically.

Change the DNS record last, after you have checked the app on its platform address. That way, if anything is wrong, your existing site is still serving while you sort it out.

What you cannot bring

Snapshots from another host. Our restore only works with snapshots taken here -- it expects our own archive, not a tar file from elsewhere. Use the files-and-database route above instead, which does the same job.

Anything that needs a port other than HTTP. Apps here are served over HTTPS on their own address. Something that expects a raw TCP port -- a game server, an RTMP ingest, a mail server -- is not a fit, and a VPS is the right tool for it.

Custom code you added to an app. If you have patched the application itself, that patch will not survive an update here, because updates replace the whole image. Data is preserved; changes to the app's own files are not.

When it does not work

Take a look at the Logs tab first. Most migration problems say exactly what is wrong: a database the app cannot read, a file it cannot open, a version mismatch it refuses to start against.

If the log does not explain it, open a ticket and tell us what you moved from and what you have tried. Include the last twenty or so lines of the log. A migration that half-worked is usually one setting away from working, and it is much easier to spot with the log in front of us.