Deleting resources

Deletes in Tandem are destructive and almost always irreversible. This guide is the one place to see, per tool, what cascades (gets torn down) versus what is preserved (kept and re-attachable). Most delete tools accept an optional confirmName / confirmSlug safety check that must match the resource’s current name.

Scope: delete a service vs delete a project

delete_service — the fine-grained option. Tears down one service and everything hanging off it: all its deployments (and build logs), env vars, deployment tokens, attached domains (hostname rows + their platform-zone DNS records), and its attachment rows to buckets / databases / redis / mailboxes (removing the env vars those injected). Then it stops + removes the running container and refreshes Caddy so the hostname stops resolving. Preserved: the buckets, databases (and their data + engine roles), redis instances, mailboxes, and registered domains themselves — only this service’s attachment to them is removed, so they stay available to re-attach elsewhere. Requires manage + admin; optional confirmName.
delete_project — cascade-deletes the whole project: every service in it (with deployments, env vars, attached domains), every bucket (dropped at the provider), every database (dropped at the engine), and the project row. Custom domains attached to services are removed too — re-attach them to a replacement project if needed. Requires manage + admin and confirmSlug matching the project’s current slug verbatim.

Data resources

Tool	Cascades (destroyed)	Preserved	Gate
`delete_database`	Drops the DB and its role at the engine (all data gone); removes `DATABASE_URL` from every attached service; cascades attachment rows.	— (nothing; take a backup first).	`manage` + developer; optional `confirmName` = db_name
`delete_bucket`	Revokes scoped creds; removes `S3_` vars from attached services; deletes the bucket. Bucket must be empty first* (`bucket_not_empty` otherwise — empty it with e.g. `aws s3 rm s3://<bucket>/ --recursive`).	—	—
`delete_redis`	Removes `REDIS_URL` from attached services; tears down the container and its data volume (async).	—	—

All three are irreversible and destroy the data they hold. For non-destructive removal from a single service, detach instead of delete (detach_bucket_from_service, detach_redis_from_service) — that removes only the env vars and keeps the resource.

Email

Tool	Cascades	Preserved	Notes
`delete_email`	Removes `EMAIL_` vars from attached services; deletes the mailbox on the mail server (all stored mail lost); tears down the mail domain’s DNS if this was the last mailbox* in it.	Other mailboxes on the domain.	No undo.
`remove_email_domain`	Deletes the SES identity and Tandem-managed mail DNS.	—	Refuses if any mailboxes still exist on the domain — delete those first.

Undoing an attach (no deletion)

You often want to disconnect a resource from a service without destroying it. Use the paired detach tool — detach_bucket_from_service, detach_redis_from_service, detach_email_from_service, remove_database_allowlist, or delete_env_var. These remove the injected env vars or grants only; the underlying resource and its data stay put, ready to re-attach.

DNS and domains

delete_dns_record removes one zone record (irreversible; platform-managed records are protected). See Managing DNS records.
There is no “delete domain” tool — a registered domain lapses only by turning off auto-renew and letting it expire (set_domain_auto_renew). See Domain lifecycle.