Introducing Pwdly: zero-knowledge password management for teams

I'll start with a confession. For more than a year, my team's passwords lived in a Google Sheet. AWS keys, Stripe live credentials, the database root password — all of it sitting in a spreadsheet that had been "shared with 12 people" and quietly forwarded who-knows-where. Every time someone joined or left, my stomach dropped. I'd go through the motions of rotating a few obvious things, then go back to pretending the rest was fine.

I'm a developer. I knew exactly how wrong it was. I'd tried the big-name password managers — more than once. They were either too clunky for a real team to actually use, too opinionated about how I should organize my work, or, worst of all, they asked me to take an awful lot on faith. "Trust us," they said. "We can't see your data." But somewhere in their architecture, somebody very much could.

That's the paradox at the heart of this industry. Tools sold on the promise of "eliminating the need for trust" quietly demand an enormous amount of it — in their employees, their infrastructure, their marketing copy, their definition of "military-grade." I got tired of hoping. So I built Pwdly.

Security as architecture, not a promise

The thing I wanted didn't exist: a password manager where I, as the person running the platform, mathematically could not see my users' data. Not "shouldn't." Not "have policies against." Could not. If a court order arrived tomorrow, the honest answer would be a shrug and a copy of some encrypted blobs that nobody on my side has the key to.

That single constraint shapes everything. In Pwdly, every credential you store — a client's production database password, a shared social media login, an SSH key — is encrypted in your browser before it ever leaves your machine. The encryption happens in libsodium running as WebAssembly, using XChaCha20-Poly1305 for the data and Argon2id to derive your key. By the time anything reaches our servers, it's noise. We forward noise. We back up noise. We can't read it, and that is by design.

Two gates instead of one

Most password managers conflate two very different things: knowing who you are, and being allowed to read your secrets. Pwdly splits them apart.

Your email and password get you into the Pwdly dashboard. That's it. They prove identity — that you're the person who owns this account — and unlock the parts of the app that don't involve secrets: settings, billing, team membership, audit logs.

The vault is a separate gate. To open it, you need your three-word recovery phrase. Those three words generate roughly 128 bits of entropy, which Argon2id then stretches into the symmetric key that actually decrypts your data. The phrase never leaves your device. It isn't stored, hashed, or escrowed on our side — if it were, the whole point would collapse. The flip side of that promise is the one thing I will not sugarcoat: if you lose those three words, we cannot get your vault back. Nobody can. That's not a limitation of the product, it's the reason the product is worth using.

Built around how teams actually work

The other reason that Google Sheet stuck around so long was that nothing else mapped to how my team actually operated. We didn't think in "vaults" and "folders." We thought in projects. The Acme rebuild had its own AWS account, its own Stripe, its own database, its own designer needing temporary access. The internal tools project had different people and different credentials. When a contractor wrapped up, I needed to revoke their access to one project — not nuke their entire account or hand-rotate every secret in the company.

So Pwdly is built around projects from the ground up. Each project gets its own keypair. When you invite a teammate, their public key is used to seal a copy of that project's key just for them — a sealed-box handshake that, again, your browser performs and our servers only relay. When someone leaves, you rotate the project key client-side, re-seal it for the remaining members, and the person who walked out the door is left holding ciphertext they can no longer open.

It's the offboarding flow I wished I had every time someone in our orbit moved on. No spreadsheet diff. No frantic Slack message asking if anyone remembers what the old DB password was. Just a button, a key rotation, and a clear audit trail of who could see what, and when.

Small on purpose

Pwdly is mostly a solo mission. I bring in trusted developers and DevOps folks from the industry to review and stress-test the security-critical pieces, but the day-to-day is me, a long list of attacker-mindset questions, and a refusal to ship anything I can't defend. The big password managers have thousands of employees and quarterly feature targets. They ship roadmaps. I'd rather ship guarantees.

Being small is the superpower here. There's no product committee asking us to add a "convenient" backdoor for enterprise sales. There's no growth team quietly relaxing the threat model so a new feature can ship by Friday. Every change goes through the same question: how could this be exploited? If I can't answer that confidently, it doesn't go out.

What you can do today

Pwdly is live. You can sign up, set your three-word recovery phrase, spin up a project, and invite a teammate in a few minutes. You'll get the kind of vault I was clearly never going to build inside a spreadsheet: per-project keys, fast client-side encryption, fine-grained sharing, an audit trail you can actually read, and a recovery model that doesn't quietly hand the keys to a vendor.

If you're a developer, a small agency, or a team currently doing some version of the thing I'm too embarrassed to admit we did for a year — I built this for you. You shouldn't have to choose between a tool that fits how you work and a tool you can actually trust. With Pwdly, that trade-off is the bug we set out to fix.

— David, founder of Pwdly