Temporary File Links That Actually Self-Destruct

Permanent links are a security liability. The share URL you sent your accountant in 2022 is probably still working today on services that don't auto-expire. Permanent equals "indefinitely searchable, scrapable, leakable."

Temporary links flip that. The link works for a defined window. After it expires, the file is deleted from storage and the URL stops resolving. Less risk of stale links going where they shouldn't.

How temporary links work on Zippd

Every uploaded file gets two limits at creation time:

1. An expiry timestamp. 7 days for anonymous uploads, 30 days for registered. Files self-delete from storage after this.
2. An optional download cap. "Allow N downloads, then kill the link." Set to 1 for a strict one-time link.

Both limits run on the server. A scheduled job sweeps every hour, deletes expired ciphertext from storage, and marks the database record as expired. The share URL returns "file is gone" after that.

Why expiry matters more than people think

Three things break when share links live forever:

• Drift. Six months later, the file's still there, but the context (who you sent it to, why) is gone. If it leaks, you have no idea who saw it.
• Search exposure. Long-lived URLs end up indexed when someone accidentally pastes them in a public Notion, ticket, or chat.
• Storage as liability. Files you don't need shouldn't sit on someone else's server. If they get breached, your old transfers are part of the dump.

Default-expire-soon is the right policy for most transfers. Long retention is the exception.

Combining expiry with download caps

Time-based expiry catches "I forgot to revoke this link." Download caps catch "the link got shared further than I intended."

Use both for sensitive sends:

• One-time strict — Cap at 1 download. Even if the URL is forwarded, only the first click works.
• Small group — Cap at 5–10 downloads for a known recipient list. Anyone trying to scrape past that bounces.
• Open distribution — No cap, but rely on the 7- or 30-day expiry to limit the window.

"Temporary" vs "self-destructing" — the technical reality

Some services market "self-destruct" links but only delete the metadata. The underlying file lingers in cold storage or backup archives for months. Others delete the file but keep logs containing enough information to reconstruct who sent what when.

Zippd's design:

• Expired ciphertext is deleted from S3-compatible storage. No cold tier. No backup pool with retained copies.
• The database row is marked expired (not deleted) so the public ID can't be re-used. But the storage object is gone.
• Logs retain only hashed identifiers and timestamps for 30 days. The file content was never logged in the first place because we never had it.

That's as close to actually self-destructing as architecture allows.

When to set a custom expiry

The defaults work for most cases. Manual choices matter when:

• You're sending to someone who downloads on a delay. Long-haul flight, time zone gap, holiday weekend. Default 7-day might be too tight.
• The file is highly sensitive. Pair an aggressive expiry (24h on registered, set via API or future feature) with a 1-download cap.
• You're distributing publicly for a campaign window. A 30-day window matches a typical launch cycle.

Comparison: expiry across services

FAQ

What happens at the exact moment a link expires?

The share page returns a "file is gone" message instead of the download UI. The next cleanup sweep (hourly) deletes the ciphertext from storage.

Can I extend an existing link?

Not in the public UI today. Registered users can re-upload the file to get a new link. We may add an "extend" action — let us know if you need it.

Does the recipient know how long they have?

Yes — the share page shows the expiry timestamp prominently. They can plan accordingly.

Are download caps strict?

Yes. Once the cap is hit, the file enters expired state immediately, regardless of the time-based expiry.

Is one-time-link enough for sensitive material?

Combined with end-to-end encryption, yes. The recipient downloads, the link dies, and even if logs were subpoenaed, the file content was never on our servers in plaintext.

Try a one-time link

Upload a file. Look for the download-limit option after upload completes to set a strict one-shot link.