If you search dev.to for Vaultwarden, you'll find dozens of excellent guides: how to deploy it with Docker, how to put it behind a reverse proxy, how to back it up, how to do it for $3 a month. They all answer the same question — how do I stand this up?
This article answers a different one: what happens after it's running, for years, for other people?
That's the question behind Vaultwarden-Plus.
First, the obvious disclaimer
Vaultwarden has been my password manager of choice for years. It's lightweight, fast, reliable, and one of the best examples of what a community-driven open source project can achieve. Thousands of people use it every day to self-host their passwords while staying fully compatible with the official Bitwarden clients.
So why a fork?
The honest answer surprised even me: I wasn't looking for more features. I was looking for a project that prioritizes long-term operation.
Vaultwarden-Plus is not a replacement for upstream, and it's not an attempt to compete. Upstream is excellent and keeps moving the whole ecosystem forward. Plus just asks a narrower question:
What would a Vaultwarden distribution look like if every single decision were made from the perspective of the person who has to operate it?
From self-hosting to operating
Running a password manager for yourself is one thing. Running it for your family, your friends, or an organization changes the perspective completely.
Every update matters. Every config change matters. Every security improvement matters. And — most underrated of all — every unexpected behavior matters, because you're the one who gets the message at 23:00 that "the login is weird."
Over time I'd accumulated a growing pile of local patches: security hardening, CI changes, operational notes. Eventually it stopped being a personal patch set and started being a project. Vaultwarden-Plus is that project, made public.
The rules I actually maintain it by
1. The official client comes first
One rule is close to absolute:
If the official Bitwarden clients don't work, the feature is probably wrong.
Compatibility beats experimental functionality every time. You keep using the apps you already trust — browser extension, desktop, mobile, CLI — with no modified clients and no special workflows. A "cool feature" that only works in a patched client isn't a feature for an operator; it's a future support ticket.
2. Validation before implementation
Implementing everything is easy. Maintaining everything is not. So every proposed change runs the same gauntlet before a single line is written:
- Is there a real operational problem behind it?
- Does an upstream solution already exist?
- Does it improve security?
- How much maintenance cost does it add?
- Can it be reviewed independently?
- Can it be removed later without breaking unrelated things?
Sometimes the answer is a new feature. Sometimes the best engineering decision is to do nothing — and write down why.
3. Small changes scale better
Big rewrites look impressive in a changelog and are miserable to review and maintain three years later. Plus deliberately prefers focused, well-scoped additions. The features that exist today exist because an operator hit a real wall:
- Mail dispatch hardening — non-critical account notifications are dispatched outside latency-sensitive request paths, while critical OTP and security mails stay fail-closed. A slow SMTP server should never block a login; a security mail should never silently get dropped.
- DKIM signing for outgoing notification mail — because "your users' password-reset mail lands in spam" is an operational problem, not a UI one.
- AWS SES mail transport — SES as a first-class alternative to plain SMTP for people who already run their mail through it.
- Send email verification — require recipients to verify their address before they can open a Send.
- OpenDAL / S3 enhancements — better S3-compatible object storage for attachments and data.
- Passkey login (experimental) — passwordless sign-in via passkeys.
- 2026.5 client-compatibility updates — keeping pace with recent official Bitwarden client releases, so the "official client first" rule stays true in practice.
None of these turn the UI upside down. All of them make the service a little more predictable in production — which is exactly the property you care about when other people's passwords live on your box.
4. Documentation is part of the product
One lesson from years of running infrastructure: undocumented decisions eventually become forgotten decisions. Plus keeps a small set of canonical documents that evolve with the code — current project state, implemented functionality, upstream assessments, product goals, maintenance strategy. The docs are treated as part of the software, not an afterthought.
5. Upstream is a partner, not a competitor
The biggest risk for any long-lived fork is pointless divergence. So every upstream proposal gets continuously categorized into one of four buckets:
Implement · Watch · Defer · Reject
The goal is not to collect the most custom features. It's to stay small, understandable, and maintainable while adopting the improvements that give operators clear value.
What this means for you
Vaultwarden-Plus will probably never have the longest feature list. That's intentional. The focus stays on security, operational reliability, maintainability, reproducible releases, and compatibility with the official clients.
If you already run Vaultwarden, the switch is meant to be undramatic: same clients, same data model, same mental model — just decisions tuned for the person holding the pager. One small but telling example of that mindset: Plus does not recommend Rocket's built-in TLS for production. It expects TLS termination at an external reverse proxy (Traefik, Nginx, HAProxy, …) and the container to speak plain HTTP behind it — fewer moving parts in the crypto path, fewer surprises during an upgrade.
Try it
Stable container images are published to the project's own registry, so a Compose file is all you need:
services:
vaultwarden:
image: forgejo.sabolowitsch.org/stefansa/vaultwarden-plus:latest
container_name: vaultwarden
restart: unless-stopped
environment:
DOMAIN: "https://vw.domain.tld"
volumes:
- ./vw-data/:/data/
ports:
- 127.0.0.1:8000:80 # TLS terminates at your reverse proxy
The project lives here:
- 👉 Source, releases, issues & container registry: forgejo.sabolowitsch.org/StefanSA/vaultwarden-plus
One ground rule: report Plus-specific behaviour to the Plus tracker, not to upstream. If a bug reproduces on a stock Vaultwarden install, it belongs upstream. Keeping that boundary clean is part of being a good downstream citizen.
If you maintain self-hosted services or open source projects of your own, I'd genuinely like to hear how you approach long-term maintenance — the patches that never made it upstream, the "we decided to do nothing" calls, the docs you wish you'd written sooner. That's the conversation I'm hoping this starts.
Technical deep-dives on the individual hardening changes will follow. If that philosophy resonates, follow along. 🔐
