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
.zipof every.intoto.jsonplus amanifest.jsonindexing 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, issuesdelete_backupfor 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.