Backup & migration

kimbap can package up every project on a host as a single file, and restore that file on another kimbap. Use it to move to a bigger box, rebuild a host from scratch, or keep a copy of how your projects are configured.

What's in a backup

For each project: its docker-compose.yml, its .env, its name and description, and its domain routes.

Container data is not included. Databases, uploaded files, and anything else living in a Docker volume stays on the original host. A restored project comes back fully configured and ready to deploy — but empty. To bring the data across too, snapshot its volumes separately: see Volumes & snapshots.

The file contains your .env contents in plain text. For most projects that means database passwords and API keys, readable by anyone who gets the file. Treat a downloaded backup like a password: don't email it or drop it in shared storage, and delete it once you've restored it.

Downloading a backup

System → Backup → Download backup. You get kimbap-backup-<date>.tar.gz containing every project on the host.

Only admins can export, and every export is recorded in the audit log.

Restoring on another kimbap

On the destination host: System → Backup → Choose a backup file.

kimbap reads the archive and shows you what's in it before writing anything — each project, how many domains it carries, and whether a project with that name already exists here. You then pick what happens to each one:

• Import — the project doesn't exist here yet; create it.
• Overwrite — a project with this slug already exists; replace its compose file, .env, name, description and domains with the archive's. Anything changed on this host is lost.
• Skip — leave it alone. This is the default for anything that would overwrite an existing project.

Press Import and kimbap writes the ones you chose.

After restoring

Imported projects are not started. kimbap won't launch containers on your host as a side effect of an import — you deploy them when you're ready, from each project's page. The import summary lists what needs deploying.

A couple of things worth checking afterwards:

• Domains. A hostname can only be routed to one project per host. If another project here already claims a domain from the archive, that route is skipped and named in the import summary; the project itself still imports. Add a different domain for it, or remove the conflicting one first.
• Registry logins. Private-registry credentials aren't part of a backup (they're encrypted with a key belonging to the host that stored them). If a restored project pulls from a private registry, add the credential again under Registries.
• DNS. Moving to a new host means the old DNS records still point at the old one. Update them, and let kimbap issue fresh certificates — see Domains & TLS.

Backing up a single project

Each project can be exported on its own via the API, which is handy for copying one project between hosts without moving everything:

curl -fsSL -u <api-key>: \
  https://<your-kimbap>/api/projects/<slug>/backup/export \
  -o my-project.tar.gz

Import it through the same System → Backup page.

Moving a whole host

1. On the old host: System → Backup → Download backup.
2. Install kimbap on the new host and create the first admin account.
3. Restore anything that isn't a project: registry logins, and any configuration you set with kimbap configure.
4. Import the backup, choosing Import for every project.
5. Move any container data you need (see above) — this part kimbap does not do for you.
6. Deploy the projects, check they come up, then repoint DNS.
7. Once the new host is serving traffic, decommission the old one.