Back up and restore data

Since Containly 2.2.0 the Backups page (shortcut G R) backs up the data of a stack (named volumes, the stack folder with compose file and .env, the container configuration with image digests), a single container or a single volume, and restores it. Manual backups, restores on the same host, database dumps, download and import and retention are free. Schedules, scheduled verification and the S3 and SFTP targets need Pro (since 2.3.0). From Containly 2.5.0, the SMB and NFS targets and restoring to another Docker host also need Pro.

Available from Containly 2.5.0: anonymous volumes, SMB and NFS targets and restoring to another host. Update your installation to use these features (see the update guide).

Video: Containly backups in 7 minutes shows targets, plans, database dumps, restore and download/import.

Add a backup target

Under Add target choose where backups are written:

• A folder on the Docker host (default /var/backups/containly). Containly writes through a short-lived hardened helper container with the path mounted, so it works on socket, TCP, SSH and agent hosts. Use an absolute path, not below /etc, /proc, /var/lib/docker or a stack folder.
• A folder inside the Containly container: below /backups (your own mount) or in the data volume under /data/backups.

For both folder types, Browse (since 2.4.0) opens a folder picker: click through the folders, create a new one and pick it instead of typing the path.

• S3-compatible storage (Pro): Amazon S3, Hetzner Object Storage, Backblaze B2, MinIO, Cloudflare R2, Wasabi and others, with presets for endpoint and region. Remote targets only accept encrypted sets.
• SFTP (Pro): password or private key (stored encrypted). The server's host key is remembered on the first successful connection test and checked on every connection after that.
• SMB (Pro, from Containly 2.5.0): server, port (445 by default), share, optional domain and subfolder, user name and password (stored encrypted). Only SMB3 with session encryption is accepted; a server that cannot encrypt is refused. Use a dedicated share. See SMB requirements below.
• NFS (Pro, from Containly 2.5.0): server, export (not /), NFSv4 or NFSv4.1 and an optional subfolder. The Docker host you pick mounts the export through a short-lived helper without extra privileges.

"Test connection" checks the target and shows the free space (SMB cannot report free space, so none is shown); "Scan for backups" finds existing sets. If your Pro licence ends, sets already on S3, SFTP, SMB or NFS stay visible, can be verified and downloaded and can be restored on the same host. New targets and new backups to them need Pro.

Back up now

Use Back up now on the Backups overview, in the stack list and the stack inspector (tab "Backups"), on the container overview or on the Volumes page.

• Encrypted by default: streaming tar, zstd compression and AES-256-GCM with a key derived from your passphrase. The passphrase is never stored. Unencrypted backups are possible on local targets. When you create a backup key, Generate (since 2.4.0) creates a strong passphrase, fills both fields and copies it with one click.
• Consistency: live, stop the containers during the backup (they are started again afterwards), pre and post hooks or database dump.
• Database dumps (free, since 2.3.0): PostgreSQL, MariaDB and MySQL, MongoDB and Redis. Containly detects the databases of a stack by image and preselects them. The dump runs in the running container without stopping it. Credentials are read from the container at run time and never stored. A restore loads the dump once the containers are up again.
• Anonymous volumes (from Containly 2.5.0): container and stack backups include anonymous Docker volumes (the ones with a random name that Docker creates for a VOLUME line in an image) by default. You can switch this off per plan or per backup. Containly identifies them by container name and mount path, not by the random name, so a restore lands in the volume that is mounted at that path today. Database dumps work on them too. Older backups stay readable.
• Runs show live phases, progress and a log. You can verify a set, pin it and delete it.

Restore

A restore always starts with a server-side preview: what happens, conflicts, risky settings and disk space.

• As a copy: next to the original with new names. Nothing is overwritten.
• Replace: overwrites the current data. You type the name to confirm; a safety backup is made first and pinned for 7 days.

Restoring on the same host is free.

Anonymous volumes

A restore puts the data into the volume that is mounted at the same path in the container now. If the container no longer exists, Containly creates a named local volume. A stack restore with anonymous volumes needs the configuration and all of the stack's volumes selected; Containly then writes a Compose override file (.containly-restore-volumes.json) so the mapping stays. If you start the stack by hand with docker compose, add -f .containly-restore-volumes.json after your Compose file. When Containly cannot tell which volume is meant (for example several replicas) or a partial selection would be unsafe, the preview blocks the restore and tells you why.

Restore to another host (Pro, from Containly 2.5.0)

A container, a volume or a Compose stack can be restored onto a different Docker host that Containly manages, as a copy or by replacing what is there.

• In the restore wizard pick the destination host and a name. For a stack also pick one of the stack folders that are set up for the destination host; the stack goes to <stack folder>/<name>, with a new project name and new volume names.
• The preview checks everything on the destination. A stack is refused when its Compose file is privileged, uses host namespaces, devices or dangerous capabilities, uses volumes_from, needs external volumes, or reaches folders outside the destination stack folder (for example a bind mount of a path on the old host). Containly does not migrate arbitrary bind mounts: only data that lies inside the stack folder travels with it.
• Replacing something that already exists on the destination first makes a safety backup on that destination host and needs the typed name as before. A copy never overwrites anything.
• The source host is never changed.
• Database dumps restore to the destination as well. A stack that was backed up with a dump instead of the raw database volume gets an empty volume that the dump fills once the database is ready.

Without Pro, Containly refuses a restore to another host and says that it needs a Pro licence.

Plans and retention

A plan bundles contents, target, key, compression and retention. Start it with Run now or give it a schedule (Pro): hourly, on chosen weekdays or monthly at a set time. A missed run is caught up on the same day. Without an active Pro licence scheduled plans pause and resume once Pro is active again; the settings are kept. Optionally a plan reads its newest set back in full every N days to verify it (Pro). Retention keeps the last, daily, weekly, monthly and yearly backups you choose; older backups of the plan are deleted after every run, the newest and pinned ones always stay.

Notifications: backup.failed (on), backup.succeeded (off) and backup.stale (warns when a scheduled plan has had no successful backup for the configured number of days, default 3), by e-mail and in the app. Viewers can look but not change anything.

Download and import

A complete set can be downloaded as a single .clbk file (encryption untouched) and imported on another Containly instance onto any of its targets. Every file is checked against the manifest. Free.

SMB requirements

The SMB target is deliberately strict, because Containly talks to a server on your network with a stored password.

• The server must offer SMB3 with encryption. Older protocol versions without encryption are not used.
• The Containly container runs smbclient in a sandbox (Landlock) that only allows the one connection to the checked server address. This needs Linux kernel 6.7 or newer on the machine that runs Containly and Docker's default seccomp profile (it permits the required system calls). If either is missing, "Test connection" shows a clear error and SMB stays off. There is no fallback without the sandbox. Other targets, NFS included, are not affected.
• Tested at runtime: Linux with Docker Engine. For arm64 the helper compiles, but it has not been run on real arm64 hardware, and Docker Desktop has not been tested. Treat both as unverified.
• Use a dedicated share and switch off symbolic links and wide links on the server.

Read a backup without Containly

Every set has a plaintext manifest.json and can be read with the recovery tool scripts/clbk-decrypt.mjs (in the image under /app/scripts). The format is documented in docs/backup-format.md in the Containly repository.

docker run --rm -i -e CLBK_PASSPHRASE -v "$PWD:/w" amslertec/containly \
  node /app/scripts/clbk-decrypt.mjs /w/<set-dir> --verify

Not the same: the Containly configuration

Settings, Containly configuration backs up the configuration of Containly itself (passphrase-encrypted, also on a schedule). Volumes, stacks and containers are backed up on the Backups page.