I Built BurnLink Because My Paranoia Was Justified
Confession: I got hacked. many times. This is what came after.
First breach: 2019. Got the notification email like everyone else. Password was there. Changed it everywhere (or thought I did). Still have no idea if it's floating around somewhere.
After the first breach, I got angry. Not at the hackers. At the system.
Why are we still emailing passwords? Why do we trust Google to delete things? Why is our only option "hope nobody gets hacked"?
So, I Built BurnLink. Not As a Feature. As Rage.
We didn't design it in a conference room. We designed it in a panic room, 3am, after firing someone who shouldn't have had access to credentials that shouldn't have existed in the first place.
The rule was simple: If I can't verify it's deleted, I won't use it. That's it. That's the entire philosophy.
What That Actually Looks Like:
Client-side encryption — I needed to know the server couldn't read it
Single-use links — I needed to know the damage was contained
60-second auto-delete — I needed to know nobody had time to copy it
Open source — I needed proof from strangers on the internet that I wasn't lying
Not because it's trendy. Because I've been breached way too many times and I'm not doing it again.
Here's The Weird Part
Building this made me realize: I was the problem.
Not the tools. Me. I was trusting the wrong people with the wrong data in the wrong ways.
BurnLink doesn't fix trust issues. It just makes them visible. And if you can see the problem, maybe you stop pretending it doesn't exist.
So What Is This?
It's not a startup. It's not a lifestyle business. It's not trying to raise funding or exit.
It's a tool I built because I had to. Open source. MIT licensed. You can deploy it on your own server if you don't trust me (you shouldn't).
Use it for:
Passwords that shouldn't exist
Credentials that should burn
Secrets that need to disappear
Things you're too paranoid about
Don't use it for:
Things you need to keep
Things you need to prove you sent
Replacing actual security practices
What I Actually Want
I don't want your money. I don't want you to be my customer.
I want you to look at how you're sharing sensitive data and ask: "Am I insane for trusting this?"
If the answer is yes, try BurnLink. Audit the code. Break it. Tell me what's wrong.
Build your own version. But please please stop emailing passwords. Stop trusting companies that say they'll delete your data in 30 days. They keep backups. They have logs. You can't verify any of it.
Visit : burnlink.page
Github : https://github.com/paperfrogs-hq/burnLink/
MIT License (actually yours, not mine)
P.S. — If BurnLink gets hacked, you'll know immediately. Because we'll tell you. Because we're not hiding from it. That's the difference.
founder of @BurnLink
Replies
@joy0x1 Since it's MIT licensed, can we easily white-label this for our own internal team dev tools?
BurnLink
@alice_hayes2 Absolutely! MIT license means you can fork it, modify it, rebrand it - whatever you need.
You can:
Customize the UI with your branding
Change the domain/URLs
Modify the encryption parameters (if you know what you're doing)
Deploy it on your own infrastructure
Remove features you don't need
Fair warning though:
You're responsible for security audits after modifications
If you change the crypto, you need to know what you're doing
Same abuse/moderation considerations apply
If you go that route, feel free to hit me up if you run into issues. Always happy to help teams that are taking this seriously.
(Also: open source means if you make improvements, sharing them back is awesome - but not required.)
How easy is it to customize the expiration times if i want something longer than 60 seconds on my own instance?
BurnLink
@adrian_stone2 Yep, totally customizable on your own instance. Just check the config and adjust the timeout values to whatever you need. It's straightforward if you're comfortable with code, not a GUI toggle, but not complicated either. If you fork it, the docs should cover the config options. If they don't, just ask and I'll point you in the right direction.
this hit hard because i went through something similar recently 😭 watching accounts get accessed in real time permanently changes how you think about “temporary” security compromises and trust
BurnLink
@qasimkhan Man, I feel that. There's nothing like watching it happen in real-time to make you realize how fragile everything is. Once you've seen the access logs, once you've realized someone else was in your account doing stuff, the concept of "temporary" anything becomes a joke. You can't unsee it.
That's exactly why I built this. Not as a feature. As a way to stop trusting temporary measures.
Glad you're thinking about this stuff now. Most people don't until it's too late.
@joy0x1 yeah that experience permanently changes how you think about security honestly
BurnLink
@qasimkhan Absolutely. Once you’ve watched it happen in real time, “temporary” security stops feeling temporary. It changes how you trust people and tools after that.
@joy0x1 yep, 100% agreed on this
@joy0x1 What happens if a Slack or Discord bot unfurls the link first—does it accidently burn it before the human clicks?
BurnLink
@brielle_marie Yes - BurnLink serves a neutral preview to known unfurl bots so they won't burn links. For extra safety, enable password protection.
@joy0x1 What stops a malicious actor from brute-forcing the short links to find active, unburned secrets?
BurnLink
@preston_daniel1 We protect against that several ways. The share token is 32 random bytes (256 bits) so brute‑forcing it is practically impossible. On top of that we enforce per‑IP rate limits and lockouts, run CAPTCHAs (Turnstile) when needed, and use an atomic, single‑use burn (race‑safe DB/RPC) so a successful probe is immediately invalidated. For extra safety enable password protection, monitor failed attempts, and block abusive IPs.
@joy0x1 Love the raw honesty here—what was the exact breaking point that made you stay up till 3 AM writing this?
BurnLink
@elodie_harper Long story short: pager went off at 2AM, I found a fired contractor happily holding prod API keys, spent an hour patching and cursing, then at 3AM rage + coffee + sleep‑deprived engineering happened and BurnLink was born. Engineers always get their best (and worst) ideas between midnight and regret :3
@joy0x1 What's the number one thing people are still stubbornly emailing instead of burning?
BurnLink
@callum_robert Passwords, especially shared account credentials and API keys. Everyone emails them because it's the quickest way, but that's the problem: quick = insecure. Use a one‑time, encrypted link (like BurnLink) for anything sensitive.
@joy0x1 Do you plan on building a CLI tool for this so developers can generate burn links straight from the terminal?
BurnLink
@kinsley_brooke Yep, plan's on the roadmap. A CLI that generates burn links from the terminal is next up; stay tuned or ping the repo if you want early access.