Data Retention & Deletion

Last updated: June 26, 2026

This page explains how long DeployMill keeps each kind of data, what happens when you delete an app, an organization, or your account, and how deletion propagates through backups and to subprocessors. It's the companion to the Privacy Policy (what we collect and why) and the Subprocessors page (where data flows). Read those for the full picture. This page is only about how long and how it ends.

One honesty note before the table: some retention periods below are deliberate policy defaults, not laws of physics. Where a period is a choice (ours or the operator's), we say so, rather than presenting it as immutable. Where a period is set by law (tax records, for example), we say that too.

The principle: data minimization

We keep data for as long as it serves the purpose it was collected for, and no longer. In practice that means three tiers:

• Live service data (your account, your apps, your secrets) lives as long

  as the thing it describes lives. Delete the app or the account and the data goes with it.

• Accountability data (the audit trail, billing records) is kept longer on

  purpose, because its value is precisely that it survives the thing it describes. You want to know what an agent did to production especially after something was deleted.

• Operational exhaust (request logs, expired previews, telemetry) is kept

  briefly and rotated automatically.

Retention schedule

Periods marked (default) are the managed-service defaults. A self-hosted operator can configure several of them (backup windows, log rotation, telemetry). If you're on a self-hosted deployment, your operator's choices govern and they should publish them.

One thing we deliberately don't store, so it has no retention period: a profile photo / avatar. When you sign in with Google or GitHub we would otherwise receive an avatar URL, but we discard it instead of saving it. Nothing in the product uses it (the dashboard renders a letter from your email). There's nothing to retain or delete because we never kept it.

Deleting an app

You (or your agent, via the delete_app tool) can delete an individual app at any time. Be clear-eyed about what that does, because it is genuinely destructive:

• The app's running workloads, previews, and attached domains are torn down.
• The app's database is dropped, whether an internal Postgres database, or a

  Neon or Supabase database, whichever backend the app declared.

• The app's object-storage bucket and its contents are deleted, along with

  the bucket-scoped credentials.

• App metadata and env vars are removed from DeployMill's records.

What app deletion does not touch:

• Your source repository. Your code and its .deploymill/project.json

  stay in your source provider. Deleting an app never deletes its repo, whether that repo lives in your own namespace (an imported repo) or under DeployMill's house account (one start_project created for you). That's also your recovery path: as long as the repo exists, import_repo can rebuild the app from its config (the data in the dropped database and bucket is not recoverable that way, only the app's shape is). Note this is about delete_app. Deleting the whole organization is different: it disposes of the house-account repos DeployMill created for you (but still never your own-namespace repos), as described under "Deleting your account or organization" below.

• The audit trail. The record that the app existed, and what was done to

  it, survives. That's the point of an append-only trail.

There is no soft-delete grace window for individual apps today. Deletion of the app's database and storage is immediate, recoverable only from backups within the backup window. If you need a copy of the data, export it before deleting.

Deleting your account or organization

Account and organization deletion is available self-serve from the dashboard at /account (and by emailing [email protected] if you can't sign in). The flow:

1. Request: an org owner requests deletion of the organization (or a

   user requests deletion of their individual account).

2. Grace window: the org and its data enter a 30-day recovery window

   (default, a policy choice, not a legal requirement). Apps are stopped and access is disabled, but data is not yet destroyed. Signing back in and cancelling the deletion within the window restores everything. The window exists because deletion requests are sometimes mistakes, compromised accounts, or a departing teammate's parting gift.

3. Purge: after the window, we permanently delete account and org

   records, membership and invites, secrets vault entries, app and preview metadata, env vars, all deployed app data (databases, buckets, volumes), and any source repositories DeployMill created under its own (house) account for your apps. Repositories in your own source-provider namespace (the repos behind apps you imported, which live under your GitHub account, not ours) are not deleted by this purge. They're yours, and we never reach into your account to remove them (see the note under "Deleting an app" about your repo, which applies to your-namespace repos).

4. What survives the purge: billing/tax records (legal obligation, kept

   for the statutory period), the audit trail (retained per the schedule above, with personal identifiers minimized where feasible), and any data we are legally required to preserve, e.g. under a litigation hold. We keep only what those obligations require, nothing more.

Deleting your individual account when you're a member (not sole owner) of a shared organization removes you (your membership, your sessions, your personal data) but not the organization or its apps, which belong to the org. If you're the sole owner of a shared organization (one with other members), you must transfer ownership or delete it first. Account deletion never leaves a workspace ownerless, and never sweeps away a workspace other people still belong to. If instead you're the only member of a workspace, the account-deletion flow offers to delete that workspace along with your account (each on its own 30-day grace window), so a solo workspace can't indefinitely block you from leaving.

Data-subject erasure requests

If you want specific personal data erased (rather than whole-account deletion), email [email protected]. The process, identity verification, and response timelines are described in the Privacy Policy. Two boundaries worth knowing:

• Erasure is subject to the same legal carve-outs as account deletion: we may

  retain what tax law, security obligations, or legal process require, and we'll tell you what was retained and why.

• If your data lives inside a customer's deployed app, DeployMill is the

  processor, not the controller: the app's owner decides on erasure, and we assist them as the DPA requires. We'll refer you to them.

Backups, and how deletion propagates to them

Backups exist to survive disasters, which means they are deliberately append-only snapshots. We don't reach into past backups to surgically remove one record, because a backup you can quietly edit is not a backup you can trust after an incident.

Deletion therefore propagates to backups by expiry: when data is deleted from the live system, it stops appearing in new backups immediately, and the old backups containing it age out of the rolling window (default 30 days). Practical consequence: after account deletion completes, deleted data may persist in encrypted backups for up to the backup window before it is gone everywhere: roughly 30 days after the purge, ~60 days after the original request with the default grace window. Backups are access-restricted, encrypted at rest (AES-256-GCM, applied before the backup leaves for object storage, which covers both the managed app-database backups and the control-plane database backup), and used only for disaster recovery. If a backup is ever restored after your deletion completed, we re-apply the deletion as part of the restore process.

Subprocessor deletion

Where a subprocessor holds a copy of your data (a managed database backend, object storage, the email provider), deleting on our side triggers deletion on theirs:

• App deletion deletes the corresponding database/bucket at the provider

  (the Neon database, the Supabase database and role, the R2 bucket), not just our pointer to it.

• Providers then apply their own backup-expiry windows, which are theirs, not

  ours. The Subprocessors page is the maintained inventory of who holds what, and remember its caveat: several subprocessors are only engaged if the operator configured them, and the default database backend is internal Postgres, in which case no third party ever held your database content to begin with.

• Organization erasure deletes the **source repositories DeployMill created

  under its own (house) GitHub account for your apps: the customer source code we hosted on your behalf is removed at GitHub, not just unlinked. A repository in your own** GitHub namespace (an imported repo) is never touched: it's under your account, so its disposal is yours to perform. If our GitHub credentials lack the scope to delete a house repo, the rest of the erasure still completes and the leftover repo is flagged for manual cleanup rather than silently left behind.

• Organization erasure deletes your Stripe customer object (billing email

  and name) when self-serve billing is configured. Stripe may, however, retain certain immutable transaction and tax records under its own legal obligations, the same billing/tax carve-out noted under "What survives the purge" above. That retention is Stripe's, not ours.

• Transactional email providers retain sent-mail metadata per their own

  policies. We send them only what's needed to deliver the message (recipient address and content).

Contact

Questions about retention, or a deletion request we can help with: [email protected]. Security concerns: [email protected]. General support: [email protected].

Related: Privacy Policy, Subprocessors, DPA, Trust & Security, Terms of Service.