Skip to main content

Archiving & deleting a workspace

Shutting a workspace down and deleting it are the same mechanism with one difference: a date.

ArchiveDelete
EffectEveryone loses access; the workspace stops doing workIdentical — plus a 30-day timer
ReversibleYes, indefinitelyYes, until the timer elapses
Data destroyedNoneAfter 30 days, permanently
Who canOwners and adminsOwners only
ConfirmationOne clickType the workspace slug

Nothing is destroyed when you press Delete. The workspace is archived immediately and the deletion happens 30 days later. Until then, Restore brings it back exactly as it was, and Keep it archived stops the clock without un-archiving.

Archiving is deliberately the lighter action, with no typing and a plain confirm. It is reversible, and putting a reversible action behind the same ceremony as an irreversible one only teaches people to click through both.

What happens the moment you archive

Access is revoked immediately — for everyone except owners, who keep the ability to restore. The workspace's attachments are suspended rather than severed: webhook endpoints and notification channels move to disabled, integration connections to suspended (not revoked), repo links to unlinked, and agent routines are turned off. No data is moved, copied, or rewritten.

Your workspace's name and slug are released immediately, so you can reuse them for a new workspace right away. The permanent ws_… Workspace ID is never reused.

What restoring does not bring back

  • API keys. They are revoked at archive time and stay revoked — issue new ones. "Un-revoking" a key is a security hole with a friendly name.
  • Running agent sessions. Their sandboxes are destroyed so they stop costing you money. The sealed session records remain.
  • Your subscription is not affected by archiving and keeps billing. It ends only if the workspace is actually deleted. An archived workspace does not count against your plan's workspace limit.

Everything else — projects, secrets, settings, members, roles, integrations, repo links, webhooks, channels, routines, and all history — returns exactly as it was, including anything you had already disabled yourself.

When the timer elapses

Deletion is permanent and cannot be reversed. It begins by destroying the encryption keys for the workspace's secrets, which makes every stored secret unreadable immediately, and then removes the workspace's data context by context.

Restore stops being possible the moment that begins, not when it finishes. If you might want the workspace back, restore it before the date shown on the banner.

What we keep, and why

A deletion removes your workspace's data. A small, fixed set of records deliberately survives it — each because deleting it would break an obligation we have to you or to a regulator.

RecordWhy it survives
billing.invoicesInvoices are financial records with tax and accounting retention requirements that outlive the customer relationship. Deleting a workspace never shortens one.
events.audit_entriesSecurity-category audit entries have a retention floor. Deletion is precisely when that floor matters — it is the record of who did what, including the deletion itself. Non-security entries age out normally.
events.event_logHolds the workspace's own lifecycle record (archived, deleted) and the security events behind the same floor. The remainder ages out normally.
membership.lifecycle_requestsThe record of the deletion: who asked, when, why, and what was destroyed. Your deletion certificate is a read of it. Deleting this with the workspace would erase the evidence that the deletion happened.

Nothing in that list contains your workspace's content — no secrets, no code, no project data, no configuration.

Account-level records are not touched by a workspace deletion. Your account's credit balance, credit ledger, spending limits, and settlement statements belong to the account, not to any one workspace, and deleting a workspace never draws them down.

Proof of deletion

curl https://api.orunbase.com/v1/workspaces/ws_a1b2c3d4/deletion/certificate \
-H "Authorization: Bearer $TOKEN"

The certificate states what was deleted — per context, with row counts and timestamps — what was retained and on what basis, and when each step happened. It is built from the record of the statements that actually ran, not from a description of what deletion is supposed to do.

It reports complete: false if any part of the deletion did not finish, rather than rounding up. Read it against the account that owned the workspace: after a deletion the workspace itself has no members left to authorize the request.

API

VerbRoute
ArchivePOST /v1/workspaces/{id}/archive
Delete (archive + timer)DELETE /v1/workspaces/{id} — body {"confirm": "<slug>"}
RestorePOST /v1/workspaces/{id}/restore
Keep it archivedPOST /v1/workspaces/{id}/cancel-deletion
Current stateGET /v1/workspaces/{id}/lifecycle
CertificateGET /v1/workspaces/{id}/deletion/certificate

GET …/lifecycle returns purgeAfter: null for a workspace that is archived with no timer, or a date for one scheduled for deletion. It also returns restoreCaveats — the same list as above, so you never have to reconstruct it.