Keep your deployment data

Know where state lives

Use Bash on your existing server's Linux host, inside the directory you installed from. You need Docker access and the local Owner for browser checks.

The data root holds private settings, accounts, certificates, saved logs/metrics, and update information. Remote Agents keep their registered identity and queued observations in persistent local storage.

Keep the same installation: preserve the installation directory, settings, data root, and agent state. With the offline auto storage setting, changing the launching account can select different data.

Stop and resume safely

Before a planned stop, finish any pending update or recovery.

Online installation

Use these Compose commands before the first product update, when the connected initializer has created deployment.env and a runtime Compose file under your data directory. For an older repository installation without those files, use the README kept with that installation. After an update, follow the installed release's planned-shutdown procedure and its recorded updater start command.

In Bash inside the original clone, set DATA to the same data root. For default storage, stop the generated runtime:

DATA="$PWD/data"
docker compose --project-directory "$PWD" \
  --env-file "$DATA/deployment.env" \
  -f "$DATA/product-updates/deployment/compose.yaml" stop

Before the first product update, resume when you are ready:

docker compose --project-directory "$PWD" \
  --env-file "$DATA/deployment.env" \
  -f "$DATA/product-updates/deployment/compose.yaml" up -d

docker compose --project-directory "$PWD" \
  --env-file "$DATA/deployment.env" \
  -f "$DATA/product-updates/deployment/compose.yaml" ps -a

Stopping preserves containers and data. Check: after resuming, services become healthy, Owner access works and saved data remains queryable. After a product update has created an operation journal, use the updater's recorded start command instead.

Signed package

From the same extracted installation directory, list this deployment's containers:

./unicron status

Copy a container name from a running row in that output. Replace CONTAINER_NAME below and repeat for each running container in this deployment:

docker stop CONTAINER_NAME

Check: ./unicron status shows no running services. Stop only names listed for this deployment; preserve the containers and data. Do not use docker compose down after updater adoption: the launcher also refuses ./unicron down once an update journal exists.

To resume, replace the verification-file path and run:

./unicron up --trust /absolute/path/to/vendor-public.jwks.json
./unicron status

Check: the verified active release starts, Owner sign-in works, existing agents reconnect, and previously saved logs and metrics remain queryable. An unfinished update must be resumed or explicitly restored; a restart does not bypass it.

Do not rerun an older initializer or use docker compose down after native updater adoption. See Updates and recovery.

Own your backup plan

Arrange backups with your infrastructure administrator before retaining important data. Product-managed backup/restore is not a base-product feature.

Your plan must:

• Consistently protect settings, keys/certificates, the database, saved logs/metrics, and required agent state.
• Define how writes are handled during capture and how restores are tested.
• Restrict backup/restore access and record the required release and storage layout.

Protect backups as secrets. Copying selected live files is not an established backup procedure. Agent queues are temporary delivery storage, not a backup.

If the deployment needs recovery

1. Preserve the installation directory, data root, agent state, and errors.
2. For online initialization failures, read docker compose logs storage-init from the clone. For a running installation, follow its generated-runtime or updater recovery controls above. For the signed package, use ./unicron logs. Keep logs private and share redacted diagnostics only.
3. For an agent, open Settings > Remote Agent deployments and follow its offered recovery on the recorded host/cluster.
4. Check Owner sign-in, unchanged agent identities, current health, and previously saved queries afterward.

Check: existing evidence is queryable. Restart success alone does not prove recovery.

Do not delete data directories or agent volumes, register replacement agents blindly, or reset the Owner through database edits. For empty views, begin with When data is missing.