Temporary Uploads Need Retention Rules

“Temporary upload” is a promise with homework.

It sounds clear: the user uploads a file, the system uses it briefly, then it goes away. Great. But systems are not a single place. The file may pass through the browser, edge cache, application server, object storage, queue, model runtime, retry worker, thumbnail generator, CDN, support tool, and logs.

If temporary means temporary only in the main database, the promise is too thin. Users care about the file, not your schema diagram.

A retention policy for temporary uploads should cover originals, resized versions, masks, previews, thumbnails, retry payloads, failed jobs, output delivery URLs, caches, and logs. It should say what is created, why it exists, how long it lives, and what remains afterward.

This does not mean every temporary file has to vanish instantly. Some systems need short-lived delivery links. Some need brief retry windows. Some need content-blind records for billing or abuse prevention. The important thing is that the retention behavior is deliberate and explained.

Temporary also needs failure handling. If a generation crashes halfway through, does the upload remain? If the worker times out, is the source image kept for debugging? If the user cancels, what happens to partial outputs? Failure paths are where temporary promises become accidental storage.

The safest approach is to reduce copies. Fewer copies mean fewer retention rules and fewer cleanup jobs. A short-lived Generation Session that receives content, processes it, returns the result, and drops sensitive material is easier to reason about than a product that scatters upload variants like confetti.

Temporary is not a word you paste into UI. It is an engineering claim.

Further reading: How to think about ephemeral compute without the cloud jargon, Unexposed data storage, and OpenAI’s API data controls.