Retention and deletion

Last updated 7 October 2026. Source: sheptra.core/docs/data-retention.md · sheptra.vantage/src/pages/docs/offboarding.md · sheptra.vantage/src/pages/docs/backup-and-restore.md

How long Sheptra keeps execution data, what it archives before removing anything, and what happens when you leave or ask for your data to be erased.

A retention window per workspace#

Execution data ages out on a schedule so history cannot grow without bound. Two windows are set per organization, stored with your workspace rather than in our configuration, and agreed with your plan:

• History — the step-by-step record of each instance. Default 90 days.
• Instances — the completed instance itself, with its variables, jobs and incidents. Default 365 days.

A window of zero means keep forever. Running instances are never retired, whatever their age. Completed instances leave the live table after seven days into an archive table on the same database — a move, not a deletion — so the hot path stays fast without anything being lost early.

Nothing is removed before it is archived#

The invariant the sweep is built around: a slice of data is removed only after the archive has accepted a copy of it. If the archive write fails, nothing is deleted and the next sweep retries. The archive is gzipped JSON Lines — one complete record per line, carrying your organization’s id — written per organization and per month to an encrypted bucket in Cloudflare R2, so that a human can open it years later with ordinary tools. Objects move to a cheaper storage class after 90 days and never expire: adding an expiry is a retention decision we would take in the open, and today there is none. The archive is deleted when you leave (below), not before.

Where this stands today. The bucket, its lifecycle rule and the writer’s credential are provisioned and proved by a smoke test. The staging environment’s sweep still runs with no destination — it discards and logs a warning on every pass — until the archive’s cell-aware layout lands. A production engine refuses to run retention without a durable destination, so this cannot be the state a customer workspace runs in.

Two things are purged, never archived#

• Idempotency keys — the stored response that lets a client safely retry a request. Purged after 24 hours; that purge is what bounds the replay window.
• Dead letters — messages the engine could not deliver. Listable and replayable for 30 days, then purged; the operator actions on them stay in the audit trail.

Modeler content#

Diagrams, forms and decisions you delete go to the Modeler’s trash, where they are recoverable for 30 days and then purged with their versions. Deployed versions already on an engine are unaffected by what happens in the Modeler.

What retention never touches#

The audit trails — operator actions on instances, administrative changes to your organization, and changes to modeler content — are append-only by database grant. The retention sweep cannot delete them, and neither can an operator. They are your evidence as much as ours, and they are kept after you leave (below).

Backups and telemetry#

Every cell’s database has daily backups and a seven-day point-in-time window. A row deleted by retention or by an erasure persists inside that window and would reappear in a restore to a point before the deletion; nothing can erase inside a backup short of the window expiring, and an erasure answer says so. Logs, traces and metrics carry identifiers and timings rather than process variables and expire with the telemetry stack’s retention window.

When you leave, or ask for erasure#

Both start the same way and differ only in the pause in the middle: at the end of a contract, we stop serving, you export, then retention runs or we erase on the agreed date; for an erasure request, we export if you want it and erase now. The procedure Sheptra staff follow:

1. Agree the scope in writing. Who asked, when serving stops, whether you want an export, the erasure date, and any legal hold. Everything after cites this record.
2. Stop serving. Your administrator revokes your API credentials (an issued token lives out its hour); we unassign your environments. Nothing is deleted by this step.
3. Export. The archive — every retired instance with its history, in the format above — is copied to a bucket you own or handed over by signed URL, never onto a laptop. What is not in it is stated in writing: running instances, instances completed more recently than seven days, and anything your history settings kept out. You export your own diagrams from the Modeler before serving stops.
4. Erase. A single reviewed action, restricted to a staff role that exists only for it, deletes your organization’s rows on the management plane and then on every cell in the estate — every cell is asked, because once unassigned nothing records where you lived. It is run a second time to confirm every plane reports zero, and the run is written into our own audit trail with every count.
5. By hand, two things no Sheptra host can do: delete your prefix from the archive bucket (the engine’s own credential deliberately cannot delete), and delete your organization in the identity provider, which takes its memberships and invitations with it.
6. The answer you get lists the planes and tables erased, the archive prefix, the identity deletion, the backup window, and the table below.

What is retained, and why#

Nothing else is retained.

Data from this site#

The marketing site collects one thing, an email address for the notify list; how long it is kept and how to have it deleted is the privacy note. For anything on this page, write to contact@sheptracloud.com.