# Data retention (/platform/enterprise/data-retention)





Data retention controls age-based cleanup of logs, deleted resources, Chat data, and previous file versions. The same policy can redact PII in workflow inputs, block outputs, or persisted logs.

Organization owners and admins set the organization policy and workspace overrides. Billing-enabled deployments require Enterprise to configure these policies. Billing-disabled deployments can configure them; applying cleanup also requires the feature and a scheduler. See [self-hosted setup](#self-hosted-setup).

## Defaults [#defaults]

Cloud plan defaults apply when no configurable policy takes precedence:

| Deployment or plan | Execution/job logs | Soft-deleted resources | Chat task cleanup | Previous file versions |
| - | - | - | - | - |
| Free Cloud | 30 days | 30 days | No default age expiry | 30 days |
| Pro or Max Cloud, including Teams | No default age expiry | 90 days | No default age expiry | 180 days |
| Enterprise | No default age expiry | No default age expiry | No default age expiry | No default age expiry |
| Billing-disabled self-hosting | No plan-based age expiry | No plan-based age expiry | No plan-based age expiry | No plan-based age expiry |

Enterprise and billing-disabled deployments retain data without an age-based expiry until configured otherwise. This does not prevent manual deletion, storage cleanup, or the file-version count limits below. PII redaction is off until a stored policy enables a stage and selects entities or patterns.

## Configure a policy [#configure-a-policy]

1. Open **Settings → Organization → Data retention**.
2. Open the **Organization** default row, or choose **Add override** for selected workspaces.
3. Choose retention periods and any PII stages, entities, languages, and custom patterns.
4. Save the policy and verify its summary in the policy list.

The three UI retention fields offer **1 day**, **3 days**, **7 days**, **14 days**, **30 days**, **60 days**, **90 days**, **180 days**, **1 year**, **5 years**, or **Forever**. One year is 365 days and five years is 1,825 days. The API accepts integer hours from 24 to 43,800, or `null` for Forever.

<Callout type="warn">
  Shortening a retention period makes older data eligible for permanent deletion on the next successful cleanup passes. Once removed, that data cannot be recovered by restoring the old policy.
</Callout>

Cleanup runs in bounded scheduled passes rather than at the exact expiry time. **Forever** disables age-based deletion for that category; it does not remove count caps or undo a manual deletion.

### Workspace overrides [#workspace-overrides]

An override can target one or more workspaces, and a workspace can belong to only one override. Each retention field can **Inherit from organization** independently or set a period, including Forever. An omitted API field inherits; `null` explicitly disables age expiry.

PII settings use **Inherit** or **Override** for the whole policy. Override replaces the organization's redaction policy for that workspace; stages are not merged. Removing an override restores organization defaults.

<Image src="/static/enterprise/data-retention-override.png" alt="Workspace override with Log retention set to 30 days, other retention fields inherited, and a PII Inherit or Override choice" width="900" height="537" />

## What each retention field removes [#what-each-retention-field-removes]

### Log retention [#log-retention]

Cleans workflow execution logs and background job logs for deployed APIs, schedules, and webhooks, based on `startedAt`. Related execution files are also scheduled for storage cleanup; logical record deletion does not guarantee immediate physical removal of every object.

Logs and referenced files for an active paused execution are protected while that execution still has live paused state. They become eligible after that protection ends and the retention window applies.

### Soft deletion cleanup [#soft-deletion-cleanup]

Permanently removes resources that have remained soft-deleted beyond the window:

* Workflows and workflow folders
* Knowledge bases and their documents
* Tables and files
* MCP server configurations
* Agent memory
* Chat conversations

Recover supported resources through Recently Deleted before cleanup removes them. Not every stored resource in this list has a corresponding recovery action in that interface. Permanent cleanup cannot be undone.

### Task cleanup [#task-cleanup]

Removes old Chat conversations, run history, checkpoints, async tool calls, and inbox tasks. Chat conversations and runs use their last update time; inbox tasks use creation time. This is separate from execution-log retention and soft-deletion cleanup.

### Previous file versions [#previous-file-versions]

`fileVersionRetentionHours` is available through the data-retention API, including workspace overrides; it is not yet a settings-page field. Read or revert versions through the [Files API](/api-reference/files/listFileVersions), [CLI](/cli/files), or MCP.

File edits can coalesce into an editing session rather than create a version for every keystroke. Sessions have a ten-minute window and five-minute idle threshold. Age cleanup protects the current version and nine newest previous versions, regardless of age. Superseded versions also have a 500-version ceiling; Free cleanup keeps at most 99 previous versions. Forever prevents age expiry but does not remove that ceiling.

## PII redaction [#pii-redaction]

A stored policy must enable a redaction stage and select entity types or custom patterns. A reachable `PII_URL` alone does not enable redaction. Matches are replaced with tokens such as `<EMAIL_ADDRESS>` using the Presidio service.

| Stage | Effect |
| - | - |
| **Logs** | Masks workflow data as logs are persisted. Execution uses the original data. |
| **Workflow input** | Masks inputs before execution, so the workflow computes on masked values. |
| **Block outputs** | Masks outputs before downstream blocks consume them. |

<Image src="/static/enterprise/data-retention-pii.png" alt="PII redaction controls with Block outputs selected and entity types grouped by region" width="900" height="537" />

<Callout type="warn">
  Workflow input and Block outputs redaction alter computation. Test affected workflows with representative values before applying these stages: masking can change outputs and add execution latency.
</Callout>

### Entity types and languages [#entity-types-and-languages]

Choose entities separately for each stage:

| Group | Available entity families |
| - | - |
| Common | Person name, email, phone, credit card, IP address, location, date/time, URL, IBAN, crypto wallet, nationality/religious/political group, medical license, VIN |
| United States | SSN, passport, driver's license, bank account, ITIN |
| United Kingdom | NHS number, National Insurance number |
| Other regions | Spanish NIF/NIE; Italian fiscal code, driver's licence, VAT code, passport, identity card; Polish PESEL; Singaporean NRIC/FIN and UEN; Australian ABN, ACN, TFN, Medicare; Indian PAN, Aadhaar, vehicle registration, voter ID, passport; Finnish personal identity code |

English, Spanish, Italian, Polish, and Finnish are supported. The selected language filters which recognizers and identifiers are available.

**Block outputs** supports regex- and checksum-based recognizers only. It does not offer person name, location, date/time, or nationality/religious/political group detection that depends on name models. SSN, US bank-account, and date/time recognizers can match loosely without a checksum; enable them where false positives are acceptable.

### Custom patterns [#custom-patterns]

Add up to 20 patterns per stage. Each has a name, regular expression, and replacement text. For example, replacement `EMPLOYEE_ID` produces `<EMPLOYEE_ID>` for each match. Use patterns for identifiers such as employee IDs, internal URLs, or ticket numbers.

### Scope and failures [#scope-and-failures]

Redaction applies to text strings at the configured workflow stages. It does not retroactively sanitize retained history, inspect every binary file, or intercept every arbitrary outbound request. Detection can miss PII or mask unrelated text; review the selected recognizers and patterns against your data.

If log redaction fails, affected strings are replaced with `[REDACTION_FAILED]` rather than stored unmasked. Failure at Workflow input or Block outputs stops the run instead of passing unredacted values downstream.

## Self-hosted setup [#self-hosted-setup]

### Enable cleanup and schedule it [#enable-cleanup-and-schedule-it]

On billing-disabled deployments, enable retention through enterprise configuration or explicitly set:

```bash
DATA_RETENTION_ENABLED=true
NEXT_PUBLIC_DATA_RETENTION_ENABLED=true
```

An explicit feature value takes precedence over the enterprise master configuration. No plan-based default window is introduced: configure the windows you intend to apply.

Deletion requires all three: an enabled feature, an effective retention period, and a scheduled authenticated request. Set `CRON_SECRET` on the app and use the same secret on the scheduler.

| Category | Endpoint |
| - | - |
| Execution and job logs | `GET /api/logs/cleanup` |
| Soft-deleted resources | `GET /api/cron/cleanup-soft-deletes` |
| Chat data and runs | `GET /api/cron/cleanup-tasks` |
| Previous file versions | `GET /api/cron/cleanup-file-versions` |

<Callout type="warn">
  The shipped Helm and Docker Compose schedules omit these four endpoints. Add calls through Helm's `cronjobs.jobs` or an external scheduler; enabling the feature alone performs no deletion.
</Callout>

```bash
curl --fail-with-body \
  -H "Authorization: Bearer $CRON_SECRET" \
  https://sim.example.com/api/logs/cleanup
```

Use the secret already configured on the app. A newly generated token that was not installed there returns `401`. Schedule each category you use, then check cleanup results. Trigger.dev is optional: without it, the dispatcher runs bounded cleanup chunks inline. A successful request is not a guarantee that all eligible stored bytes disappeared in one pass.

### Deploy the PII service [#deploy-the-pii-service]

Deploy `apps/pii`, which exposes `/analyze` and `/anonymize`, and set its reachable URL:

```bash
PII_URL=http://pii:5001
```

On Helm, `pii.enabled` deploys and wires the bundled service automatically; a manual `PII_URL` is ignored while it is enabled. For an external service, set `pii.enabled: false` and supply `PII_URL`. The bundled service is `<release>-sim-pii`, or `<release>-pii` when the release name already contains `sim`.

Docker Compose does not ship a PII service. Add one to the project or point to a reachable external service. After verifying service access, save a policy with enabled stages and selected entities or patterns under **Data retention**.

## Related docs [#related-docs]

* [Data drains](/platform/enterprise/data-drains)
* [Files](/files)
* [Execution logs](/logs-debugging/logging)
* [Self-hosted enterprise setup](/platform/enterprise/self-hosted)
