Account/Closing an Account

Closing an account

Closing an account destroys everything it owns. To make that survivable, a closure is scheduled, not immediate: seven days pass before anything is deleted, and any owner can cancel inside that window.

Closure lives at the bottom of Account → Overview.

Scheduling a closure

Only an owner can close an account. The confirmation asks for three things:

  1. Your current password.
  2. The account name, typed exactly.
  3. A second factor, if two-factor authentication is armed on your user — a current six-digit code or one recovery code, which is spent.

The account name is checked before the second factor, so a typo in the name does not cost you a recovery code.

An account with an active subscription is refused: cancel the subscription first. A closure that is already scheduled is refused too — one open closure per account.

Every owner is emailed, not only the one who asked. An owner who did not request this is the person that notice exists for, and they have seven days to act on it.

The grace period

The deadline is seven days from the moment the closure is scheduled, computed on the server and re-derived before anything is deleted. It cannot be shortened by a client, so a stolen session cannot turn a closure into an instant one.

Nothing changes during those seven days:

  • Cells keep serving.
  • Databases, buckets, and webhook endpoints keep working.
  • Nobody is signed out. Scheduling a closure deliberately does not end sessions — you may need them to take an export.

The dashboard shows a standing banner with the date, and Cancel closure beside it. Any owner can cancel, and cancelling asks for no re-authentication: undoing a destructive action should be easier than starting one.

Cancelling after the purge has begun is not possible. The answer is "The purge has already started and cannot be cancelled."

What the purge deletes

After the deadline, a sweep running every five minutes picks the account up and deletes, in order:

  • API tokens and the account's object-storage credentials
  • Custom domains
  • Every Cell: its deployed code, its static files, gate policies, capability links and viewer sessions, pulse schedules, and its traffic and visitor rollups
  • Vault secrets
  • c3 databases, with their contents
  • g7 buckets, with their objects
  • Vesicle endpoints and every captured request
  • Sensor devices
  • Account flags, ingest limits, and the account's subdomain
  • Memberships, open invites, and the account itself
  • The user identity of anyone whose only membership was this account, along with their recovery codes, pending enrolments, and remembered devices

Someone whose identity is deleted this way can sign up again with the same address. Members who belong to another account keep that account and their identity.

The cascade is a delete per resource, keyed by the account, so a step that fails can be re-run. A closure that stalls partway leaves the account marked as purging with the error recorded, rather than half-deleted and unmarked.

What survives the purge

Four things are not deleted:

  • Audit records. The activity feed rows — including account.closed and account.purged — stay in the audit store and age out on the ordinary 30-day retention rule. So records of what was done on the account persist for up to 30 days after each was written, which can be after the account itself is gone. They carry the action, the actor's email address, the target's name, and the time.
  • Abuse records. A suspension recorded against the account is kept, so a closure is not a way to shed one.
  • Payment records. Charges and invoices held by the payment processor are outside the platform's stores and are not part of the purge.
  • Access-log files. The per-request access log is written to a platform-wide store keyed by Cell address, and the cascade does not reach into it. Those files age out on the access log's own 30-day retention, so a purged account's last 30 days of request lines outlive it by up to that long.

Everything else goes with the resources it belongs to: analytics rollups, visitor counts, and captured webhook payloads are deleted with the Cells and endpoints they describe.

Before you close

Take an export while the account still exists, and pull anything the export does not contain — database rows with ribo db exec, bucket objects with ribo bucket cp, Cell source from wherever you deploy it. After the purge there is nothing to restore from.

See also