Move your setup to another install

Take your whole Synq control plane (servers, projects, services, domains, env vars and secrets) from one install to another, for example to a new server, or from the local Synq of an older desktop app to a server.

You want Synq itself to run somewhere else: a new or bigger server, or, if you ran a local Synq with desktop app version 1.2.5 or earlier, an always-on Linux server so deploys keep working when your laptop is closed. You don't want to recreate every project, server connection, domain and secret by hand.

Synq has a first-class data transfer for exactly this: export your entire instance to a single encrypted file on the old machine, import it on the new one. It carries the whole control plane — server/SSH connections, projects (including local-folder source settings), services, domains and routes, environment variables, deployment history and backup destinations — and your secrets travel re-encrypted under a passphrase you choose, never in the clear.

Embedded database → Postgres works

An install on the embedded database (PGlite), such as the local Synq of desktop app 1.2.5 or earlier, can move to a server that uses Postgres. The export records which it came from and the import adapts, so you do not convert anything by hand. To export from that local Synq, run version 1.2.5 again (see the desktop app); current versions of the app only open a panel.

Use Data Transfer for an instance move

The Settings → Team → Migrate → Own server shortcut is unavailable in this version. Its preflight reports the missing deployment step and cannot start a restore on an unprepared target. Install and start the destination first, then use the export/import steps below. Verify the imported installation and its projects before retiring the source.

What travels (and what to check after)

Carried: servers/SSH connections · projects · services · domains & routes · environment variables · deployment settings · backup destinations · git installations. Secrets (env values, SSH keys/passwords, clone tokens, backup credentials) are lifted into a passphrase-sealed AES-256-GCM bundle on export and re-encrypted under the destination's key on import.

Check after import: projects that deploy from a local folder (no git) store the folder's path on the source machine. That path won't exist on the new machine, so Synq flags those projects on import. Re-point them, or just re-deploy each from a folder that lives on the new machine (see the last step).

Move it

Export on the old machine

CLI:

synq system data-transfer export --passphrase "a-strong-passphrase" --out synq-export.osx

Or the dashboard: Settings → Instance → Data Transfer → Export, set a passphrase, download the file.

The passphrase encrypts the secrets inside the file. Anyone with the file but not the passphrase gets your projects/domains/config but no secret values. Keep the passphrase safe — it's required to import.

Copy the file to the new server

Any transport works — scp, rsync, a USB drive. The file is self-contained.

scp synq-export.osx you@your-server:/tmp/

Import on the new server

Install and start Synq on the server first (see Installation), then:

synq system data-transfer import --file /tmp/synq-export.osx \
  --passphrase "a-strong-passphrase" --mode wipe

Or the dashboard: Settings → Instance → Data Transfer → Import, choose the file, enter the passphrase, pick a mode.

wipe (default) — replace the destination's data with the file. Use this for a fresh server. It also replaces the login/session, so you'll re-authenticate as the imported owner afterward.
merge — insert only rows that don't already exist; the destination's own account/settings are kept. Use this to fold one install into another without clobbering it.

Re-deploy local-folder projects

If the import warned about local-folder projects, their source path pointed at the old machine. For each one, deploy the folder again from a computer that has it, with no git required:

cd /path/to/your/app
synq deploy --folder --project <project-id>

synq deploy --folder packages the folder, uploads it to this install, detects the stack, and deploys it (see Deploy a folder or archive).

Source release maintenance commands

A source release uses a flat api/, dashboard/, and packages/ layout. Its headless import entry is api/scripts/import-instance.ts; the database dump and restore entries are under packages/db/scripts/. These commands and the release supervisor use the assets from their installed PGlite package. They do not reuse SYNQ_PGLITE_ASSETS_DIR from a compiled CLI installation.

For a running destination, use the Data Transfer API or dashboard above. A headless import must use the destination's database configuration and encryption key, with any process owning that embedded database stopped first. It is a data import command; it does not install, start, route, or cut over the destination.

Deploy only what changed (don't restart your databases)

Once you're running on the server, a multi-service (Compose) project can deploy a subset of services so a backend-only change doesn't recreate your MySQL/Redis/Qdrant containers:

synq deploy --service-ids web,api

Services you don't name carry forward on their existing containers, untouched. Omit --service-ids on the first deploy to bring the whole stack up. For stateful services this is the difference between a quick app update and needless database downtime.

Deploy a local folder — the no-git deploy this guide re-points to.
Server-to-server migration — moving a running app + its volumes between servers (different from moving the control plane).
Database migrations — backing up and migrating a stateful volume safely around a deploy.

Move your setup to another install

On this page