# Move your setup to another install
URL: https://synquic.tech/docs/guides/migrate-control-plane.md

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.

import { Step, Steps } from 'fumadocs-ui/components/steps';

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.

<Callout title="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](/docs/getting-started/desktop-app#updating-from-version-125-or-earlier)); current versions
of the app only open a panel.
</Callout>

<Callout title="Use Data Transfer for an instance move" type="warn">
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.
</Callout>

## 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

<Steps>

<Step>

### Export on the old machine

**CLI:**

```bash
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.

</Step>

<Step>

### Copy the file to the new server

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

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

</Step>

<Step>

### Import on the new server

Install and start Synq on the server first (see [Installation](/docs/getting-started/installation)),
then:

```bash
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.

</Step>

<Step>

### 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:

```bash
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](/docs/guides/deploy-local-folder#cli)).

</Step>

</Steps>

## 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:

```bash
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.

<Callout title="Related">
- [Deploy a local folder](/docs/guides/deploy-local-folder) — the no-git deploy this guide re-points to.
- [Server-to-server migration](/docs/guides/server-to-server-migration) — moving a *running app + its
  volumes* between servers (different from moving the control plane).
- [Database migrations](/docs/guides/database-migrations) — backing up and migrating a stateful volume
  safely around a deploy.
</Callout>