Retention + deletion — ZevCloud¶
Honest snapshot of where retention stands today. NDPA §31 requires data to be kept "no longer than necessary" — the substance of that rule applies to ZevCloud now; the automated enforcement of it is on the roadmap, not yet shipped.
Current state — short version¶
No automated retention purge runs on ZevCloud today. Data is retained for the lifetime of the team / service / domain registration. The cron-driven cleanup model that ZevID uses (90-day login-events purge, etc.) hasn't been ported to ZevCloud's tables yet. When the DPO requests formalisation, retention windows will be agreed and the relevant cleanup cron added.
What this means per category¶
| Category | Currently retained | Comment |
|---|---|---|
| Team + membership | Lifetime of the team | Hard delete is admin-only and rare; a deactivated team's rows stay |
| Service + deployment metadata | Lifetime of the service | When a customer deletes a service, the row is hard-deleted; deployment-event rows linked to it cascade |
| Service environment variables | Lifetime of the service | Encrypted; deletes cascade with the service |
| Build / runtime logs | Ephemeral on the Coolify host | Not centrally stored by ZevCloud; rotation is whatever Coolify's host config does |
| Domain registration + contacts | Lifetime of the domain at the registry | Customer can release a domain at expiry; rows remain for audit but contact PII becomes vestigial |
| DNS records mirror | Tracks Cloudflare; tombstones (deleted_at) for user / out-of-band deletions |
Tombstone rows are retained for audit |
| Invoices + subscriptions + payment-method tokens | Retained — financial-record-adjacent | Expected to align with CBN 7-year financial-record retention when formalised |
| Admin audit logs | Retained — security-forensic | Expected long retention; will be agreed with DPO |
| ZPIP token + delivery audit | Retained — replay protection + audit | — |
Account deletion (customer-initiated)¶
When a customer asks to close their ZevCloud account:
- The team owner can request deletion via the dashboard's account-settings page (this flow is in progress; until it ships, requests come through support and are actioned by admin).
- On deletion, services are stopped and the Coolify containers torn down. Custom domains they attached are detached. Registered domains they own remain at the registry (the customer owns the registration — we don't delete domains they purchased through us; expiry handling is governed by NIRA / NameSilo rules).
- Financial records (invoices, subscriptions) are retained per legal-obligation basis. The customer's PII inside those records (name, email captured at invoice time) is retained for the same period.
- Cross-product cascade: ZevCloud writes a de-enrollment record back to ZevID (
PUT /v1/internal/users/:accountId/enrollments/zevcloudwithisActive: false).
Deletion via subject-rights request¶
See subject-rights.md. The DPO office is the entry point for formal NDPA erasure requests.
Backups¶
Neon's point-in-time recovery covers the database. The retention horizon of the PITR window is governed by the Neon plan we're on (the DPO can confirm with Daniel for the current value). Coolify volume backups (for customer container state) are governed by the host's backup configuration on Hetzner.
When this will be formalised¶
When the DPO requests a retention schedule with concrete windows + a deletion cron, engineering will:
- Agree windows per category with the DPO.
- Implement a
cleanup.service.ts-style cron inzevcloud-backend(mirroring the ZevID pattern). - Update this page with the cron's name, schedule, and what it deletes.
- Add a row to
change-log.md.