# Can you delete temporary files sooner?

> [!Warning]
> **Important Change**: Due to our migration to Cloudflare R2 storage, custom purging settings for periods **less than 24 hours are no longer supported** for files already stored there. Selecting No Save can prevent new results from being stored, but does not immediately delete existing R2 objects. For immediate access to your files, we recommend adding explicit export steps (such as `/s3/store`, `/azure/store`, etc.) to your *Templates*. [Read more about this change](/blog/2025/10/r2-migration-temporary-file-purging.md).

You can configure data retention settings to control temporary storage. These settings can be
configured at both the **workspace level** (affecting all Templates in that workspace) and the
**Template level** (overriding workspace settings for specific Templates).

<span aria-hidden="true" id="configuration-options"></span>



## Configuration Options

**Temporary Files**: No Save prevents new output files from being uploaded to temporary storage when an
*Assembly* ends, instead of retaining them for the default 24 hours. Files already stored in R2 remain subject to its minimum 24-hour lifecycle.

**Assembly Status JSON**: You can configure how long to retain Assembly Status JSON data with
options including:

* No Save (not retained at all)
* 1 day
* 7 days
* 30 days
* 90 days (default)

<span aria-hidden="true" id="warnings"></span>



## Warnings

Before enabling immediate deletion of temporary files, consider these potential issues:

1. **Re-import and Moderation Workflows**: Some customers use temporary files to import them again
   in new *Assemblies* for additional processing, or to show files to moderation teams
   before persisting them to their own storage. Immediate deletion will break these workflows.

2. **Assembly Replay Functionality**: If an *Assembly* crashes and needs to be
   auto-replayed, it imports the uploaded files from our temporary result bucket. If files are
   deleted immediately, replays will not work.

3. **Support and Debugging**: When you submit support tickets for encoding issues, we need access to
   the uploaded and encoded files for debugging.

> [!Important]
> Regardless of retention settings, temporary storage must **never** be used to serve
> files to end users or as a CDN. See [temporary storage restrictions](/docs/faq/temporary-purge.md) for details.

<span aria-hidden="true" id="security-note"></span>



## Security Note

Temporary filenames are cryptographic hashes, so if you don't expose the file locations publicly, it
would take much longer to correctly guess a filename than the file will exist, even with the default
24-hour retention.