A Password Pusher alternative where the server holds no keys
One architectural difference — which Password Pusher documents itself — and an honest account of what it does better.
Password Pusher has been running since 2011 and is one of the most candid projects in this category about what it does and does not protect against. The architectural difference between it and this service is real and worth understanding — but it is a difference Password Pusher documents itself, in plain language, rather than one you have to uncover.
What Password Pusher does well
Start with the thing most comparison pages would bury. Password Pusher's own security documentation states that it does not offer client-side encryption, and says so without hedging: that the browser does not encrypt data with a key unknown to the service before sending, that this is what "zero-knowledge encryption" means, and that if your requirements demand end-to-end encryption then Password Pusher might not meet your organisation's needs.
That is an unusual thing for a product to publish about itself, and it deserves credit rather than a gotcha. A tool that tells you its own boundary is more trustworthy than one that markets a guarantee it does not implement.
It is Apache-2.0 licensed, self-hostable via Docker, Compose, Kubernetes and Helm, and has fifteen years of production history. Its expiry controls are genuinely richer than ours: both a day count and a view count, each admin-configurable, plus optional passphrases, a one-click retrieval step and manual early expiry. It also offers a "Request" flow — asking someone else to send you a secret — which we do not have at all.
The architectural difference
Password Pusher encrypts your secret on its server, at rest, using a key the server holds. The link you share contains a random identifier in the URL path — /p/<token> — which is transmitted to the server on every request, as all paths are. It is a lookup identifier, not a decryption key.
This service does the opposite: your browser generates a 256-bit key, encrypts before anything is sent, and places the key after the # in the link. Browsers never transmit that fragment. The practical consequence is not about which is "more secure" in the abstract — it is about who could read your secret if compelled. With server-side encryption, the operator holds the key and can be ordered to use it. With the key in the fragment, there is nothing to order: we hold ciphertext and no key.
If you self-host Password Pusher, set your own encryption key. The project ships a hardcoded default master key in config/initializers/lockbox.rb, and the file's own comments say so and recommend replacing it. An instance running on the shipped default is encrypted with a value published in a public repository. This is documented by the project, not a hidden flaw — but it is easy to miss when a deployment "just works".
Side by side
Checked against the Password Pusher repository, documentation and pricing page on 30 July 2026.
| Criterion | Password Pusher | notekill.com |
|---|---|---|
| Open source | ✔ Apache-2.0, since 2011 | ✘ No — hashes published, source not |
| Self-hostable | ✔ Yes — Docker, Compose, Kubernetes, Helm | ✘ No |
| Expiry controls | ✔ Days and views, both configurable; optional passphrase | Time and view count, fixed set of durations |
| Ask someone to send you a secret | ✔ Yes — "Requests" | ✘ No |
| Audit log of views | ✔ Yes, by design | ✘ No — we keep no record of who opened what |
| Encryption in the browser | ✘ No — server-side, stated in its own docs | ✔ Yes — AES-256-GCM before anything is sent |
| Decryption key out of the operator's hands | ✘ No — the server holds the key | ✔ Yes — the key lives only in the link fragment |
| Files encrypted before storage | ✘ No — its docs state file uploads are not encrypted by the application; an encrypting storage backend is recommended | ✔ Yes — contents, filename and type all encrypted in your browser |
| File size | ✔ Effectively unlimited self-hosted; 4 GB tested. On pwpush.com, file transfer is a paid-tier feature | 25 MB, free |
| Chat | ✘ No | ✔ Yes (/chat) |
| IP logging, hosted service | Its privacy policy states servers may log IP address, browser, pages visited, time and date | ✔ Access logging is switched off; see /privacy |
| Price | ✔ Free without an account; Premium $25/mo or $250/yr for files, email delivery, custom domain; Pro $49/mo | ✔ Free |
About the CVE count
Password Pusher has five published advisories, three with assigned CVE identifiers, covering an authentication bypass, a session-token issue, a rate-limiter bypass and a cross-site scripting flaw. It would be easy to present that as a scoreboard. It is not one.
Those numbers exist because the code is public, researchers can read it, and the maintainers publish and patch what is found. A closed-source service with zero disclosed vulnerabilities has not demonstrated that it has fewer — only that nobody outside can look. We have no published CVEs either, and that fact says nothing good about us that it does not also say about every other unaudited closed tool. Judge disclosure processes, not disclosure counts.
Which should you use?
Use Password Pusher if you need per-view audit trails, a "request a secret" flow, fine-grained expiry policy across a team, files far larger than 25 MB, or a tool you can self-host and control end to end. Those are real requirements and it serves them better than we do.
Use this service if the operator being technically unable to read your data is the requirement — because the key never reaches us, there is nothing for anyone to compel us to hand over. Also if you need encrypted files and ephemeral chat under the same model, with no account and nothing to pay.
Our residual risk, stated as plainly as Password Pusher states its own: the encryption code is served by our server on each visit, so whoever controls that server could serve altered code to future visitors. Already-encrypted data stays sealed, and the change is detectable, because the hashes at /integrity.json can be archived and compared, and /verify runs that comparison in your browser. It does not reach zero. Full detail on /security.
Try it
Write a note at notekill.com, or start with how to choose between these tools. Other comparisons: Privnote, Onetime Secret, Yopass.