Stop emailing passwords. Use twn.cx

People leak sensitive information every day through the most boring attack vector imaginable: their email's sent items folder.

A new hire starts Monday, so their manager receives the password in an email.

A friend needs the Wi-Fi password for your Airbnb, so it goes in iMessage.

A security researcher hands off a disclosure package with PoC code, so it sits as a zip attachment in a thread that'll be retained for the next seven years.

An accountant sends a tax file number over Gmail because there was no better option in the moment.

Every one of those is sensitive data sitting in a mailbox or chat history indexed by search, backed up nightly, and accessible to whoever compromises that account later.

Retention policies for mail and messaging platforms are almost always longer than the useful life of the secret. The password you sent in 2023 is still sitting there in 2026, waiting to be found.

We got tired of the dance, so we run our own one-time secret and file sharing service for anyone who needs to quickly share something without it persisting forever. No login. No account. No "start your free trial."

It's called Enclosed, and it lives at:

• https://enclosed.twnstack.com
• https://twn.cx

All three are the same service. Pick whichever URL you like.

What it does

Paste a secret, upload a file, or both. You get a link. The recipient opens it, reads or downloads the payload, and it's gone. No accounts. No login. No "create a workspace" flow. Open the page, drop in what you want to share, send the link.

You can set:

• Expiration — anywhere from one hour to several weeks. After that, the blob is wiped.
• Password — a second factor for the payload, because the URL itself should never be the only secret.
• Self-destruct on read — first viewer wins, the link burns on access.
• Max views — share with a small group, the link dies after N accesses.
• File attachments — not just text. Config exports, zip archives, screenshots, disclosure packages.

The content is encrypted in the browser before it ever hits our servers. We can't read your secrets even if we wanted to — the decryption key lives in the URL fragment, which browsers don't send to the origin. We just store the ciphertext.

Who it's for

Anyone who has ever typed a password into a chat window and immediately regretted it. A few scenarios we and others use it for:

Credential handoff for new accounts. Provisioning an M365 tenant, a database user, a VPS root password, a VPN profile — anything where you need to hand a credential to someone once and never have it persist. 24-hour expiry, password-protected link, self-destruct on read. The credential doesn't live in anyone's inbox.

Login details for new users. New staff, new contractors, new clients. They get a link, retrieve the credentials once, change them on first login, done. No plaintext password sitting in their sent items for the next seven years.

Security disclosure packages. When disclosing CVEs or vulnerabilities — PoC code, reproduction steps, screenshots, write-ups — zip the lot, upload to Enclosed, set a password, send the link. Password goes over a different channel (Signal, a phone call, whatever the vendor has published). The vendor downloads, the link expires, no disclosure material sits on any third-party service long-term.

File transfers that shouldn't persist. Config exports, log bundles for vendor escalations, one-off debug dumps, scanned documents. Anything you'd rather not leave sitting in SharePoint or a shared drive indefinitely.

Personal stuff. Wi-Fi passwords for house guests. An ID document for a rental agent. A keyfile for a family member. You don't need a "professional" reason to want a secret to self-destruct.

How it's built

Enclosed is an open-source project by Corentin Thomasset.

Our fork lives at github.com/TWN-Systems/enclosed. We run it (FOR FREE) on Cloudflare Workers with Workers KV as the storage backend.

Why this stack:

• Workers puts the endpoint at every Cloudflare edge location. It's fast from Launceston, it's fast from Jakarta, it's fast from Frankfurt.
• KV is a key-value store with TTL. You set an expiration on write, Cloudflare wipes the entry when it's up. No cron jobs, no cleanup scripts, no forgetting to prune the database.
• Zero servers for us to manage. Which means zero servers for us to patch, zero servers for us to misconfigure, zero servers for an attacker to pivot through.
• Free tier handles our volume comfortably. Workers gives you 100k requests/day free, KV storage is cheap in the extreme. Running this service costs us effectively nothing.

Deploying it was a wrangler deploy, a KV namespace, and three domain routes. The whole thing is version-controlled alongside the rest of our infrastructure.

Use it from the terminal

If you're scripting credential handoffs, log-dump workflows, or anything that benefits from a pipe, Corentin also maintains an official CLI as an npm package. Point it at our instance and you can pipe secrets straight from your terminal:

npm install -g @enclosed/cli

# point the CLI at our instance
enclosed config set instance-url https://twn.cx

# basic note
enclosed create "secret goes here"

# pipe from stdin
cat credentials.json | enclosed create --stdin

# attach files with full options
enclosed create \
  --file backup.tar.gz \
  --password "out-of-band-password" \
  --ttl 3600 \
  --deleteAfterReading \
  "Here's the config dump you asked for"

# view a note back (handy for scripts)
enclosed view <note-url>

That means Enclosed drops cleanly into provisioning scripts, CI pipelines, Ansible playbooks, or anywhere you'd otherwise be piping secrets to a less-secure channel. It's the difference between "send this password securely" being a manual browser task and being one line in a shell script.

Why self-host it

There's already prior art here. onetimesecret.com has been around for years and does this well.

1Password has one-time secrets. PrivateBin has public instances. Password Pusher exists. If you just need to send one password right now, any of them will work.

We run our own for two reasons:

We wanted something we fully control. The source is in our GitLab and mirrored publicly at TWN-Systems/enclosed.

If upstream abandons the project, pivots, or merges something we don't like, we keep moving. If a client needs a patch, we patch it.

We run on Cloudflare Workers today, so yes; if Cloudflare has a bad day, so do we. No point pretending otherwise.

But the code isn't locked to Workers. We can redeploy on Bun, Node, Deno, or stick it behind Caddy on a VPS if we ever need to.

Migrating off a hosted SaaS means rebuilding the workflow from scratch; migrating this means changing a deploy target.

We wanted it branded under TWN. twn.cx is short, memorable, and clearly ours. Clients who've been trained to be suspicious of random URLs — correctly — recognise our domain. A link on someRandomSecretService.io doesn't get the same trust. This is the same reason we run our own mail, our own DNS, our own everything where it makes sense.

It's not about avoiding dependencies entirely. Cloudflare is a dependency, DNS is a dependency, the upstream project is a dependency. It's about which dependencies we accept and whether we can swap them without rebuilding the workflow.

That's the whole pitch. We didn't reinvent the wheel — Corentin's project already did the hard part. We took it, deployed it under our domains, and now it's part of how TWN operates.

Go use it

Open https://twn.cx, paste a secret or drop a file, share the link. No account, no telemetry, no tracking. You don't need to tell us who you are.

If you're still sending passwords, files, or anything sensitive in plaintext email or chat, there's no excuse for that in 2026. The tooling is free, client-side encryption means you don't even have to trust the operator, and the link dies on its own.

Pick something. Use it. Stop leaving sensitive data in places it doesn't need to be.