Lifecycle

Uninstalling

Removing the agent from a host, and optionally closing the org. The one thing to get right: back up the state dir before you delete it, or accept that every historical backup encrypted under that agent's keys becomes undecryptable.

Remove the agent from a host

This is the common case: you are retiring a VM. The org continues to exist.

1. Revoke the agent

Start dashboard-side. From Agents → <agent> → Retire, retire the agent record. The signing pubkey is archived (existing receipts keep verifying); the bearer token becomes inert. Doing this first prevents the agent from posting a final heartbeat after you've already wiped the host.

2. Back up the state dir

Keys first. Follow Backing up the state dir to produce a GPG-encrypted tarball of /var/lib/restorable/keys/. Move it off the host to wherever you keep long-term encrypted archives.

Do not skip this step if the agent has ever signed a receipt that still matters to you. Without the signing key, the auditor can still verify the receipt (the key lives on in the orchestrator's archive); without the age key, the encrypted backups that are still in the bucket become unrecoverable.

3. Stop the service

sudo systemctl disable --now restorable.service

4. Remove the unit

sudo rm /etc/systemd/system/restorable.service
sudo systemctl daemon-reload

5. Remove the binary

sudo rm /usr/local/bin/restorable

6. Remove config and state

# Config: safe to delete.
sudo rm -r /etc/restorable

# State: re-confirm you have the off-host backup before this!
sudo rm -r /var/lib/restorable

7. Remove the user

sudo userdel restorable

Drop the user out of the docker group (automatic with userdel). The docker group itself stays because other services may use it.

8. Optionally remove Docker

If Docker was installed exclusively for Restorable, remove it with the same package manager you used to install it:

# Debian / Ubuntu, installer-installed
sudo apt remove docker-ce docker-ce-cli containerd.io

# Fedora / Rocky / Alma
sudo dnf remove docker-ce docker-ce-cli containerd.io

If Docker was already there, leave it.

Close the org

Different operation, different consequences. Closing the org is irreversible and affects every agent in the org.

Before you close

Export everything you might need later:

  • All receipts. Dashboard Receipts → Export all. A .zip of every .intoto.json plus a manifest.json indexing them. Archive this somewhere durable.
  • The transparency log. Dashboard Events → Export. The append-only event stream with signed tree heads interleaved. Keep this for future consistency proofs if the org ever resurrects.
  • The agents' public signing keys. Dashboard Agents → <each> → Public key. Auditors verifying your receipts need these; once the org closes, the orchestrator-hosted copy is archived and not freely retrievable.

Then remove your agents from their hosts (above) one by one.

Closing the org itself

From org Settings → Danger zone → Close org. A confirmation dialog asks you to type the org slug. The orchestrator:

  • Revokes all agents in the org.
  • Marks all sources removed, issues delete_backup for every active backup. (Those commands never get acked because the agents are revoked; the orchestrator force-deletes bucket objects 72 hours after revocation.)
  • Archives the transparency log, freezing its tree head.
  • Removes user access to the dashboard.
  • Deletes billing records and closes any open subscription.

What the orchestrator keeps: the hash of the final tree head and the pubkeys of all revoked agents. This is the minimum to keep historical receipts verifiable against the transparency log, and we keep it for as long as we run the service.

A GDPR note

The orchestrator holds the org name, user email addresses, and backup metadata (source ids, ciphertext hashes, timestamps, sizes, event reason codes). The last four are operational metadata tied to the service; the first two are personal data. A GDPR Article 17 erasure request triggers removal of the first two; the operational metadata is retained under the legitimate-interest basis tied to the transparency log's integrity.

Details in the DPA template. Ask for it if your procurement needs one.

Reinstalling on the same host later

After a clean uninstall, the host is ready for a fresh install. Nothing left that would collide with a new curl | sh. The new agent will have fresh keys and a fresh agent_id; the historical receipts signed by the old agent are independent and verify through the archived pubkey.