I had a screenshot to send. Nothing secret — a stack trace from a side project — but it had an internal hostname, a file path with my username, and a chunk of a config file in the terminal behind it. The fast move is to drag it onto a free image host and paste the link. I sat there with my cursor over the upload button and couldn't do it.

Because I know what happens next. That image lives on someone else's infrastructure, indefinitely, behind a URL I don't control, and I have no idea who else can reach it. For a throwaway screenshot, that's a permanent record I never agreed to. So I closed the tab and built a thing instead. It's called tmpdrop, and it's ~500 lines of Node.

The threat model

The problem with public file hosts isn't that they're evil. It's the gap between what you intend ("share this once, with one person") and what the platform delivers ("store this forever, serve it to anyone who finds the link").

A few specific things go wrong:

• Retention. "Temporary" hosts keep your files long after you've forgotten them. There's no expiry you can trust, and deletion is usually best-effort.
• Predictable URLs. Plenty of hosts use sequential or short IDs. Scrapers walk the keyspace and hoover up everything. Your "private" link was never private.
• Stored XSS via uploads. If a host serves an uploaded .html or .svg file inline with a permissive content type, an attacker can ship JavaScript that runs in your browser, in the host's origin. Your file host becomes an XSS delivery service.
• Abuse vectors. No rate limit means the box is a free CDN for whatever someone wants to dump on it — malware, spam payloads, the works.

So the design goal wasn't "another uploader." It was: close each of those gaps, then stop.

What I built

tmpdrop is a single Fastify server backed by SQLite. The whole defensive surface is small enough to hold in your head:

• Unguessable URLs. Slugs are 9 random bytes, base64url-encoded — 72 bits of entropy. You cannot enumerate them.
• A TTL reaper. Every upload gets a 1h or 24h lifespan. A loop runs every 60 seconds, deletes expired files from disk and the DB row. There's no soft-delete and no recycle bin — when it's gone, it's gone.
• A CSP sandbox on every download. Each file is served with Content-Security-Policy: default-src 'none'; sandbox plus X-Content-Type-Options: nosniff. Even if you upload an HTML file full of scripts, the browser refuses to execute it. text/html is additionally forced to download rather than render, because it's the one type worth quarantining outright.
• Hashed IPs. The DB stores a truncated SHA-256 of the uploader's IP, never the raw address — enough to reason about abuse, nothing that identifies a person.
• A 30 req/min per-IP rate limit and a 25 MB cap, so the box can't be turned into someone else's storage bucket.

The use I didn't plan for: a file clipboard for an AI agent

Here's where it got interesting. I run an AI coding agent (Claude Code) that works inside a sandbox or a remote box, and it constantly produces files it can't hand me directly — a screenshot from a browser test, a generated PDF, a debug log, a QA recording. It has the artifact and nowhere to put it.

So I gave the agent a one-line escape hatch: curl -F file=@shot.png <my-tmpdrop>/upload, and it pastes the returned link straight back into the chat. It turned out to be the perfect clipboard between an agent and a human — one public endpoint, no auth to fumble, self-hosted so the artifacts never touch a third party. And the 1-hour TTL means my disk doesn't slowly fill with debug screenshots I'll never open again. The agent's one rule: never upload anything with secrets in it, because the URL is the only access control — exactly the threat model the rest of the design already assumes.

Stack notes

Node + SQLite + Docker, deliberately boring. Fastify because the multipart, rate-limit, and static plugins are first-party and I didn't want to assemble middleware. SQLite (via better-sqlite3) because the data model is one table — there is no universe where this needs Postgres, and "one file on disk" is the whole backup story. Docker so anyone can docker run it behind their own Caddy or Cloudflare Tunnel and be done.

Just as important is what's intentionally out of scope: no user accounts, no folders, no sharing permissions, no encryption-at-rest. tmpdrop is for the thing you want gone in an hour. The moment you want to organize files, you want a different tool, and bolting that on would wreck the property that makes this one safe — that everything disappears.

One design call worth flagging: I accept any MIME type and gate only on size. The earlier version had a strict allowlist, but the CSP sandbox makes the content type irrelevant to safety, and an allowlist just annoys honest users. Defense at the serving layer beat defense at the gate.

A note on how it was built, and an ask

I pair-programmed tmpdrop with Claude Code — it wrote a lot of the plumbing while I drove. But the threat model, the scope boundaries, and every security decision above are mine, and I'd rather say that plainly than pretend a person typed every line.

Which is also the ask: I want this attacked. If you can find a way to make an uploaded file execute, guess a slug, slip past the reaper, or turn the box into an abuse relay, please open an issue — security feedback is the most useful thing you can give me.

• Code: github.com/rogerhokp/tmpdrop
• Live demo: tmpdrop.solardev.online

It's MIT. Run your own, and stop handing your screenshots to strangers.