Move your setup to another install

Take your whole GramCode control plane — servers, projects, services, domains, env vars and secrets — from one install to another. The classic case is a local desktop → an always-on self-hosted server.

You started on the desktop app on your laptop, and now you want GramCode itself to run on 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.

GramCode 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.

Desktop → server works

The desktop app stores its data in an embedded database (PGlite) and a server uses Postgres. The export records which it came from and the import adapts, so a desktop → server move imports cleanly — you do not convert anything by hand.

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 included as plaintext in current downloads when selected, then encrypted under the destination's key on import. Keep the file private.

Check after import: projects that deploy from a local folder (no git — the “Deploy a local folder” flow) store the folder's path on the source machine. That path won't exist on the new machine, so GramCode 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:

openship system data-transfer export --out openship-export.osx

Or the dashboard: Settings → Instance → Data Transfer → Export, review the selection and download.

The CLI writes a private file. Current exports include plaintext credentials; omit secrets in the selection if they are not needed. Legacy encrypted exports still require their original passphrase on import.

Copy the file to the new server

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

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

Import on the new server

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

openship system data-transfer import --file /tmp/openship-export.osx \
  --mode wipe --yes

Or the dashboard: Settings → Instance → Data Transfer → Import, choose the file and pick a mode. A passphrase is requested only for legacy encrypted archives.

wipe — 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-point local-folder projects

If the import warned about local-folder projects, their source path pointed at the old machine. For each one, put the source on the new server and re-deploy it from there — no git required:

cd /path/to/your/app/on/this/server
openship deploy

Run from a non-git folder, openship deploy packages the folder on the spot, uploads it to this install, detects the stack, and deploys — the headless equivalent of the desktop “Deploy a local folder” flow. That re-binds the project to a path that exists here.

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

openship 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.

On this page