One-Time Secret alternative
One-Time Secret is the go-to for sharing credentials in DevOps workflows. It works — but the server can read every secret you pass through it. VoidNote gives you the same one-shot sharing with encryption that happens before the request leaves your terminal.
How One-Time Secret works
One-Time Secret stores your plaintext (or server-encrypted text) on their server. When the link is opened, the server retrieves and returns the content, then deletes it. The self-destruct is reliable. But the secret travels to and from the server in a form the server can read.
This means One-Time Secret (or anyone who has breached their infrastructure) can log, copy, or inspect every secret that flows through the service. Their privacy policy governs this — not cryptographic impossibility.
For DevOps and engineering teams handling database passwords, deploy keys, and API credentials, that's a meaningful risk. Especially if your threat model includes supply-chain compromise of third-party services.
The VoidNote difference for DevOps
VoidNote is designed for the same workflows — sharing credentials within a team, passing secrets to a new colleague, handing a deploy key to a CI pipeline — but with encryption that makes server-side reading impossible.
Every note is encrypted with AES-256-GCM before it leaves your machine. The decryption key is embedded in the URL fragment — which HTTP clients never send to the server. We store a tokenId and an encrypted blob. Even a full database dump from our servers yields nothing readable.
# Share a database password with a teammate
$ echo "postgres://user:hunter2@prod-db/app" | voidnote create
https://voidnote.net/n/abc123#secretkey
# Teammate opens link — note decrypts in their browser, then burns
# VoidNote servers saw: encrypted blob. Nothing else.
The CLI integrates directly into terminal workflows. Pipe any command output into a note, get a link back. Share that link over Slack, email, or a ticket — wherever the receiver is — and know the content is gone after one view.
Self-hosting One-Time Secret vs using VoidNote
One-Time Secret is open source and can be self-hosted, which some teams do to avoid the third-party trust issue. Self-hosting shifts the trust to whoever runs your infrastructure — still server-side encryption, still a human who could technically read your secrets.
VoidNote's zero-knowledge model means there's nobody to trust on the server side — not us, not your ops team, not the cloud provider. The secret never exists in plaintext outside of the creating and consuming devices.
Feature comparison
| Feature | One-Time Secret | VoidNote |
|---|---|---|
| Destroys after reading | ✓ | ✓ |
| Client-side encryption (zero-knowledge) | ✗ | ✓ |
| Server cannot read your content | ✗ | ✓ |
| Password protection | ✓ | ✓ |
| Custom TTL / expiry | ✓ | ✓ |
| CLI tool | ✗ | ✓ |
| API / SDK | ✓ | ✓ |
| Encrypted file vault | ✗ | ✓ |
| Live encrypted streams | ✗ | ✓ |
| AI agent integration (SDK) | ✗ | ✓ |
| Open source | ✓ | ✓ |
| Self-hostable | ✓ | ✗ |
Get started
The VoidNote CLI is the fastest way to drop it into your existing workflow. One command, one link, one view — and the CLI has a native pipe mode for scripting.
# Install
brew install quantum-encoding/tap/voidnote
# Create a note from stdin
echo "my-secret" | voidnote create
# Or read it back
voidnote read https://voidnote.net/n/abc123#key