Deleting & Restoring

Parslinks never destroys anything immediately. Every deletion follows the same three-phase model:

Disable  →  14-day undo window  →  Purge

Phase 1: Disable

The moment you confirm deletion:

• The project or service is tombstoned and hidden from the UI
• Instances pause
• Public routes are dropped (your domains stop serving)
• Everything else is kept: source connections, configuration, artifacts, logs, volumes

Phase 2: Undo window (14 days)

For 14 days you can restore the deleted item from the dashboard. Restore reverses the disable: instances resume, routing is rebuilt from the derived state, and nothing was ever lost.

The remaining time is shown on the deleted-items list.

Phase 3: Purge

After the window expires, a background sweeper purges metadata and resources in dependency order: source connections → resources → variables → domains/routes → observability data → compute (workloads, replicas, endpoints) → build caches → artifacts (content-addressed objects reclaimed only when no longer referenced) → identity rows.

Purge is idempotent and retries safely; a failed step never blocks the rest from being attempted again on the next sweep.

Service vs project deletion

Deleting with volume wipe requires project-admin permission and explicit confirmation when the project has a production environment.

What is never deleted

• Your remote GitHub/GitLab repository and its commits — disconnecting only removes Parslinks' webhooks and link rows
• Billing history for the workspace

Best practices

• Prefer deleting a single service over the whole project when cleaning up.
• If something looks wrong after a restore, check that domains re-verified and that instance placement intent is what you expect.