Yopass

Last reviewed Sep 13, 2026 · 792 words

Yopass does one thing: it turns "here's the database password" typed into a chat window into a link that opens once, decrypts in the recipient's browser, and then no longer exists. It is not a password manager, it stores nothing you would ever want to retrieve twice, and it runs in 64 MB. Those limits are the point. If you already have Vaultwarden and wonder why you would add this, the answer is the coworker or client who is not in your vault and never will be.

How the encryption actually works

The browser generates a random key, encrypts the secret with OpenPGP.js, and posts the ciphertext to the server with a time-to-live. The server stores the blob in Memcached or Redis with that TTL and returns an ID. The link you send is https://yopass.example.com/#/s/<id>/<key>: the key rides in the URL fragment, which browsers never send to the server. So the server holds ciphertext it cannot read, the transport is HTTPS, and the recipient's browser does the decryption. A one-time secret is deleted on first fetch; a timed one expires at 1 hour, 1 day or 1 week.

Two consequences follow. Your Yopass server is never the interesting target, because it has nothing readable to steal; the chat log where you pasted the link is the weak spot, and the one-time setting protects against that log being read later. And there is a checkbox to leave the key out of the URL and send it through a second channel, which is what you should do for anything that matters: link over email, key over Signal.

The deployment is a 12-line compose file

services:
  yopass:
    image: jhaals/yopass:latest
    restart: unless-stopped
    command: ["--database=memcached", "--memcached=memcached:11211", "--port=1337"]
    ports:
      - "1337:1337"
    depends_on:
      - memcached
  memcached:
    image: memcached:alpine
    restart: unless-stopped
    command: ["-m", "64"]

Put a reverse proxy with TLS in front on a subdomain, and that is the whole install. Use --database=redis --redis=redis://redis:6379/0 if you would rather secrets survive a container restart; with Memcached, a restart wipes every pending secret, which some people consider a feature. There is also a Helm chart for Kubernetes and a static binary for anywhere else. --max-length caps secret size (file uploads are supported up to a configurable limit), and --force-onetime stops users from choosing multi-view links, which I set on any work instance.

Where it fits in a stack

A typical self-hoster uses it in three places. Onboarding: the first password for a new account goes out as a one-time Yopass link rather than in the welcome email. Support: a client sends you an API key the same way, on your instance, so it never sits in their sent folder. Ops: the yopass CLI lets you pipe from a terminal, so cat cert.key | yopass --api https://yopass.example.com produces a link without touching a browser.

The author runs a public instance at yopass.se with the same code, and the client-side encryption means it is not less safe than yours. Self-hosting buys you two things over it: a domain your recipients recognise, which matters when you are training people not to click strange links, and independence from a free service that could vanish. Both are worth 64 MB.

PrivateBin covers the neighbouring use case, a longer paste with the same client-side encryption, and Hemmelig sits between the two with a fuller feature set. Yopass is the smallest and the least configurable, which for a tool whose value is that you trust it, I count as a merit.

What it will not do

It does not authenticate senders, so a public instance will be used by strangers; either put it behind your VPN or accept that and cap the TTL. It has no audit log of who opened what, only that a secret was consumed. It is not a place to store recovery codes, because they expire. And it does not replace anything in the password manager category for a secret with a second retrieval.

What I'd do

Run it beside your other services on a secrets. subdomain, Memcached backend, --force-onetime on, TLS from the proxy, and reachable from the internet, since the recipients are the people who cannot reach your LAN. Send keys separately for anything you would regret leaking. Tell the people you work with that this is how credentials arrive from you, and stop pasting them into Slack. The whole thing costs one weekend hour and 64 MB, and it removes the single most common way secrets leak from small teams.