The problem
Secrets fossilise in chat history
A password pasted into a chat lives there forever, in every backup and every export. A one-time link exists exactly as long as it needs to.
kaicorplabs.com / projects / secretdrop
project open source · self-hosted
A password that stops existing once it is read.
Paste a credential, send the link, and it destroys itself on reading. Encrypted before it leaves your browser — the server never holds the key.
Who it is for
Anyone handing over a credential
The receiving side needs no account, ever — asking the person you are helping to register would defeat the point.
Your data
The key never reaches us
Encryption is AES-256-GCM in your browser; the key travels in the URL fragment, which browsers do not send to servers. We store ciphertext and an IV — a full compromise of the machine would read nothing.
Honest limits
Write needs an account; read never does
Creating secrets requires sign-in (this instance: by invitation). Global quotas — 100 MiB and 1000 active secrets — keep the store honest. One instance.
Run your own copy
Without OIDC configured it serves existing links but nobody can create secrets — deliberate, not a misconfiguration.
docker pull ghcr.io/ulzuhan/secretdrop:latest # or: clone the repo and `docker compose up -d --build` # DEPLOYMENT.md in the repository covers the rest.
The image is built from a tagged commit by CI, scanned for known vulnerabilities before release, and published with provenance and an SBOM. Or use ours: open secret.kaicorplabs.com and ask for an account — a person approves it.