I Built Zero-Knowledge .env Sharing

Hey everyone,

Small disclaimer upfront: English is not my native language. This post was translated/polished with the help of AI, but the words and meaning are 100% mine.

I run a small software development agency in Germany. Every week, the same thing happens: >A client needs to send us database credentials >A freelancer needs API keys >Someone new joins and needs the .env file

And every time, the same pattern:

>Pasted into Slack

>Sent via email

>Dropped into a Google Doc called “keys for dev”

>Shared with “anyone with the link” enabled

Not because people are careless. Because there was no easy alternative.

Proper vault setups take time. Enterprise secret managers are overkill for many small projects. CLI tools are powerful, but nobody installs them unless forced to.

What I needed was simple:

Upload a file → share a link → done. But encrypted before it ever leaves the browser.

So I built SecretDrop.dev.

What it does

1. Client-side encrypted file sharing

Files are encrypted in the browser using AES-256-GCM Key derived via PBKDF2 (600k iterations) Encryption happens before any data touches the server Recipient enters the password → file decrypted in their browser

The server never sees:

>The file contents

>The password

>The decrypted file

>The filename

Everything runs on WebCrypto. No third-party crypto libraries.

2. Zero-knowledge architecture

The server stores only encrypted blobs and minimal metadata required for routing.

It cannot read:

>File content

>Passwords

>Decrypted filenames

The threat model is simple: If the server is compromised, attackers still cannot decrypt the files without the password.

3. Direct end-to-end transfer (Premium)

For workflows where passwords are annoying:

>Select recipients by email

>Files encrypted with their public key (ECIES)

>No shared password required

>Only the intended recipient can decrypt

>Sender identity verified via digital signature

This removes the “send password via Signal” step entirely.

4. Auto-expiry & access analytics

Expiration after time or download count Basic access visibility (without breaking zero-knowledge model)

Why I made the free tier free

Password-protected encrypted sharing is free. No credit card. No trial. No artificial limits.

Because securely sharing a .env file shouldn’t be a paid feature. Security in code should be normal, not enterprise-priced.

Why not just use XYZ Tool or Vault?

Good question.

There are great tools out there. But in many small dev teams:

>Nobody wants to set up a full Vault instance

>Secret managers are too heavy for quick one-off sharing

>People default to Slack because it's frictionless

The real competitor isn’t a vault.

It’s “paste in Slack.”

So I optimized for:

>Zero setup

>No account required (for password mode)

>One link, done

What’s next

I’m exploring two things:

VSCode extension Right-click .env → “Share via SecretDrop” → get link.

CLI tool secretdrop share .env --expires 24h

Both are early ideas. I want to integrate into real dev workflows instead of forcing a new one.

If either would be useful for you, I’d love to understand how you’d use it.

Questions for the HN crowd

>What would make this useful in your workflow?

>Any concerns about the security model?

>Would you prefer Argon2 over PBKDF2 in the browser?

>What attack vectors am I overlooking?

>What would make you trust this enough to use it in production?

I built this because I was tired of seeing secrets floating around in Slack threads. I use it daily inside my own agency.

If you want to rip apart the crypto model, architecture, or UX decisions — please do.

Curious to hear what you think.

Cheers Aleks