Ephemeral by design: TTL, auto-expiry, and why nothing is kept
There is a simple truth behind a lot of good security: data you never store can never leak. Most breaches, subpoenas, and accidental exposures are about information that was kept longer than it needed to be. Ephemeral systems take the opposite bet — they treat stored data as short-lived by default and let it delete itself. This guide explains TTL and automatic expiry, why a short lifetime is a security property in its own right, and where the honest limits are.
The core idea: don't keep what you don't need
The cheapest, most reliable way to protect a piece of data is to not have it. You cannot lose, leak, or be compelled to produce something that no longer exists. "Ephemeral" simply means short-lived and automatically deleted — the data has a built-in end date, and reaching it is the normal outcome, not an error.
This inverts the usual habit of software, which is to store things forever unless someone remembers to clean up. Ephemeral design flips the default: deletion is automatic, and keeping something is the deliberate exception.
What TTL actually is
TTL stands for time-to-live: a deadline attached to a stored item. When you write the item, you also write how long it may exist. Once that deadline passes, the storage system deletes the item on its own — no cron job to remember, no cleanup script to run, no human to press a button.
TTL is a familiar mechanism. A DNS record carries a TTL that tells resolvers how long to cache it. A login session has a TTL after which you are signed out. A cache entry expires so stale data does not linger. In each case the value is the same: the system enforces the deadline for you, consistently, without relying on anyone to intervene. Expiry becomes a property of the store, not a task on a to-do list.
How classified uses TTL
classified shares encrypted notes and files that are meant to be read once and then vanish. TTL is what makes "then vanish" automatic rather than aspirational.
- Encrypted blobs with native TTL. Each share is stored as ciphertext in Cloudflare KV using the store's native time-to-live. The deadline is set at the storage layer, so expiry is handled by the infrastructure itself.
- You choose the window. Pick an expiry from 5 minutes to 24 hours. A five-minute hand-off and a next-day note get different lifetimes, and you set the shortest one that works.
- Destroyed on first read. A share is destroyed on its first view or download. Once it has done its job, it is gone.
- Purged if never opened. Any unopened share is automatically purged at its deadline by the storage layer, whether or not anyone ever looks at it.
Because the servers only ever hold ciphertext and an opaque id — no content and no file names are stored or logged — expiry is not deleting readable data. It is discarding a scrambled blob that was never legible on the server in the first place.
Why ephemerality is itself a security property
Encryption protects data you are keeping. Ephemerality reduces how much you keep at all, and that is a separate, compounding benefit. A shorter lifetime helps in three concrete ways.
- A smaller window to intercept. An attacker can only grab a share while it exists. A five-minute lifetime offers a five-minute opportunity; a permanent copy offers an unlimited one.
- A smaller store to breach. Whatever has already expired is not in the database to steal. The blast radius of any incident is limited to what happens to be live at that moment, not the entire history of everything ever shared.
- Less to hand over. A request or demand can only reach data that still exists. If it expired last week, there is nothing to produce.
This is the practical face of data minimisation — the principle that you should collect and retain only what a task genuinely requires, and no more. Ephemeral storage is minimisation applied to time: it keeps data for as long as it is useful and not one moment longer.
Retention is a liability, not an asset. Every item you keep is something you now have to secure, account for, and potentially disclose. Deleting on a deadline is not losing data — it is retiring a risk the moment it stops earning its keep.
What still persists, honestly
Ephemeral content does not mean zero records everywhere, and it would be dishonest to imply otherwise. For account holders, some data is deliberately kept while the account exists:
- Account data — your email, an optional name, and a salted hash of your password (never the password itself).
- Usage counts and a share audit log — a record of size, times, and status only. It never includes the content of a share or its file names.
That account data is deleted when you delete the account. Separately, transient edge request logs (IP address, timestamp, user-agent) are kept only briefly, for security and abuse prevention. The point is the boundary: the secret is ephemeral, while a minimal set of records about the account and its activity persists for as long as it is genuinely needed — and no readable content lives in either place.
Designing your own retention
The same thinking applies whenever you build or configure a system that stores data. A few rules travel well.
- Pick the shortest TTL that still does the job. Start from the question "how long does this actually need to exist?" rather than "how long could we keep it?" The answer is usually shorter than the default.
- Default to deletion. Make expiry automatic and retention the explicit choice, so that forgetting to clean up fails safe instead of accumulating forever.
- Separate content from records. The message, the file, the secret — delete these fast. The records you are obliged to keep, such as invoices or an audit trail, belong in a different store with its own, deliberate retention. Mixing the two forces you to keep everything as long as the thing you keep longest.
The trade-off: expiry is irreversible
There is a real cost, and it is the honest one. Because classified holds no keys and stores no readable content, an expired or destroyed share is unrecoverable. There is no "undo", no support recovery, no backup to restore from — the data is genuinely gone.
That is not a flaw to be patched; it is the guarantee working as intended. A system that could bring an expired secret back would, by definition, still be holding it. The irreversibility is what makes "it expired" mean something. Send with that in mind: keep your own copy of anything you may need later, and let the ephemeral copy do the one job it is built for.
- Ephemeral means short-lived and automatically deleted — data you never keep can never leak.
- TTL is a deadline on a stored item; the storage system deletes it on its own when the time passes.
- A shorter lifetime is its own security property: less to intercept, less to breach, less to hand over.
- Content is ephemeral, but a minimal set of account records persists while the account exists — and expiry is irreversible.
classified puts this to work: encrypted notes and files stored with a TTL you choose, destroyed on first read and purged at their deadline — with nothing readable kept on our servers.
Try classified free