Yopass: self-hosted secret sharing where the key never reaches the server

The problem Yopass solves: credentials that outlive their welcome

Passwords pasted into chat, email or a ticket system stay there. They sit in the recipient's message history, in the sender's sent folder, in search indexes and in backups, long after the handover is done. Yopass targets that specific moment: a one-off transfer of a password, an API key, a private key file or a short configuration snippet between two people who already have some other channel to exchange a link.

The intended user is an operator or a small team that wants to run the service themselves. The README is explicit that the public demo at share.yopass.se is for testing and that you should self-host when sharing sensitive information. There are no accounts in the standard flow, which is the point: nothing to provision, nothing to deprovision, no directory integration to negotiate before you can send someone a credential. The repository dates the project to 2014 and lists Spotify among the organizations using it, which tells you the design has survived a long time without acquiring a user-management layer.

How the browser-side OpenPGP flow keeps ciphertext on the server

The README lays out four steps, and the ordering matters. First, Yopass generates a random decryption key and encrypts the secret in the browser using OpenPGP. Second, the server stores the encrypted message with an expiration time and cannot read it. Third, the link that gets generated carries the decryption key in the URL fragment. Fourth, the recipient's browser downloads the encrypted message and decrypts it locally, and a one-time secret is removed after its first retrieval.

The URL fragment is the load-bearing detail. Fragments are not sent to the server as part of an HTTP request, so the key travels from the sender's browser to the recipient's browser without passing through the Yopass process. That is what makes the claim about the server being unable to read secrets more than a slogan, and it is also why the README insists on HTTPS in production: the web application and the encrypted payload must not be modifiable in transit. A network attacker who can rewrite the served JavaScript can exfiltrate the key regardless of how the storage layer is configured.

On the backend, the Go module in go.mod pulls in gomemcache, go-redis, and the AWS SDK v2 S3 client, matching the README's statement that storage is Redis or Memcached and that files can go to disk or an S3-compatible backend. Configuration runs through pflag and viper, which is why the README says flags and environment variables are interchangeable, with environment names uppercased and dashes replaced by underscores. The server binary is built as yopass-server and the client as yopass, per the Dockerfile, which builds both from cmd/ and then copies them into a distroless base image running as user 1000.

Installing Yopass with Docker and creating a first secret

The README's quick start needs Docker and nothing else. It creates a network, starts Memcached on it, then starts Yopass pointed at that Memcached instance and publishes port 1337 on loopback only:

docker network create yopass
docker run -d --name yopass-memcached --network yopass memcached
docker run -d --name yopass --network yopass \
  -p 127.0.0.1:1337:1337 \
  jhaals/yopass --memcached=yopass-memcached:11211

Open http://localhost:1337 and the web interface is served from the same container. Type a secret, pick an expiration, and the browser produces a link. Send that link over whatever channel you already trust. The recipient opens it once and the secret is gone from storage. The README notes this arrangement binds to 127.0.0.1 without TLS and is meant for local testing or for sitting behind a TLS-terminating reverse proxy.

If you prefer Redis over the default Memcached, the configuration section gives the flag form directly:

yopass-server --database redis --redis redis://localhost:6379/0

For anything real, the repository ships deployment examples rather than asking you to assemble one: deploy/docker-compose/with-nginx-proxy-and-letsencrypt for automatic certificates, deploy/docker-compose/insecure for an existing reverse proxy, and deploy/yopass-k8.yaml for Kubernetes. The TLS guide covers built-in TLS plus Nginx, Caddy and Traefik configurations.

Argon2id key derivation and the CSP directive it forces on your proxy

Password-protected secrets can derive their key with Argon2id instead of the default, enabled with the --argon2 flag. The README is unusually candid about the operational consequence: Argon2id requires the 'wasm-unsafe-eval' CSP directive. If your reverse proxy rewrites or replaces the Content-Security-Policy header, it has to allow that directive or the feature breaks.

This is the kind of detail that turns into a confusing bug report. The server starts, the page loads, secrets work, but password-protected secrets fail for reasons that look like a client problem. Anyone running Yopass behind a hardened proxy that injects its own CSP should decide up front whether they want Argon2id, because enabling it later means revisiting proxy configuration. The README points to a dedicated server-options page for the full flag and environment variable reference rather than enumerating everything inline.

What the open source edition leaves out, and the 1 MB file ceiling

The README splits the feature list cleanly. The open source edition gives end-to-end encryption for text and files, one-time links, automatic expiration, optional password protection, no accounts, Redis or Memcached storage, disk and S3-compatible file storage, split read/write deployments with read-only mode, Prometheus metrics, and multiple languages.

The business license adds OpenID Connect authentication with email-domain restrictions, custom themes and branding, structured audit logging, secret requests, read receipts, signed webhooks, and file uploads larger than 1 MB. That last item is the sharpest constraint in the whole document. If your use case involves moving a build artifact, a database dump or a certificate bundle, the open source edition's file size ceiling rules it out, and no amount of self-hosting changes that. The same applies to audit logging: an organization that needs a record of who created or opened which secret has to look at the licensed tier, not the Apache-2.0 code.

Read-only mode is worth noting for a different reason. The README lists split read/write deployments, which lets you expose a retrieval-only instance separately from the one that accepts new secrets. That is a real architectural option for teams that want the write path confined to an internal network while recipients fetch from a public endpoint. The README does not document rollback behavior for a secret that was retrieved but never read by a human, so treat one-time semantics as retrieval-based rather than read-confirmed unless you buy the read receipts feature.

Yopass compared with a hosted secret-sharing service

The obvious alternative for many teams is a hosted service such as OneTimeSecret, where you paste a secret into someone else's web application and get a link back. The difference is not the encryption primitive so much as who operates the endpoint. With a hosted service you accept that a third party serves the JavaScript that performs the encryption, which is the same trust problem Yopass has with its own frontend, except you cannot inspect or pin the operator's deployment.

Self-hosting Yopass moves that trust boundary inside your perimeter. You control the served bundle, the storage backend, the TLS terminator and the retention window. The cost is operational: a Memcached or Redis instance to run, a reverse proxy with certificates, upgrades to track, and the knowledge that a misconfigured proxy can silently break password protection. For a team already running Kubernetes, deploy/yopass-k8.yaml makes that cost small. For someone who sends a password twice a year, the hosted route is less work and the trust difference may not matter.

A second alternative worth naming is simply not using a link service at all and exchanging secrets through an existing end-to-end encrypted channel your team already operates. Yopass exists because that channel often has history, search and retention problems, but if yours does not, adding a service is adding attack surface.

Maintenance, licensing and what to check before you commit

The repository is not archived, and the last push was on 2026-09-23. Releases have been frequent: 14.10.0 on 2026-09-18, 14.9.0 on 2026-08-20, and 14.8.0 on 2026-07-28. That cadence suggests version churn worth planning for. The Dockerfile builds from golang:1.27-bookworm and node:22, so a self-hosted build pipeline needs both toolchains current, though pulling the published jhaals/yopass image avoids that entirely. The distroless runtime image means no shell inside the container, which is good for attack surface and mildly annoying for debugging.

Licensing is Apache-2.0 for the open source edition. The features behind the business license are a separate commercial arrangement, and the README does not describe how that license is applied to a deployment. If you plan to use OIDC, audit logging, theming or larger uploads, confirm the licensing terms with the vendor before you build a dependency on them. Nothing here is legal advice; the point is that the feature table in the README is also a licensing boundary, and it is easy to prototype against a documented feature and only later discover it is not in the Apache-2.0 code.

On upgrade cost, the practical risk is configuration drift rather than schema migrations, since storage is Memcached, Redis or S3 and the README describes no migration tooling. Pin an image tag, read the release notes between versions, and keep your deployment example in version control next to the compose file you copied from deploy/.

Editorial conclusion

Adopt Yopass if you need a self-hosted one-time link service and your secrets are small text or files under 1 MB, because the browser-side OpenPGP encryption means the server only ever holds ciphertext. Do not adopt it if you need accounts, audit logging, read receipts or large file transfers, all of which the README places behind a business license. Before rolling it out, verify three things on your own instance: that HTTPS terminates in front of it, that your reverse proxy does not strip the 'wasm-unsafe-eval' directive if you enable Argon2id, and which storage backend you will run, since the default Memcached container keeps secrets only in memory.

Frequently asked questions

Official sources

1. jhaals/yopass on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases