NodeWarden: a Bitwarden-compatible server that lives entirely in Cloudflare Workers

The problem NodeWarden addresses: no server to patch

Self-hosting a password manager normally means owning a machine. Vaultwarden, the Rust reimplementation the README credits as a reference, is a single binary but still expects a host you patch, back up and keep reachable. NodeWarden takes the other route: the server is a Cloudflare Worker, state lives in D1 and attachments in R2 or KV, and there is no operating system for you to maintain. The target reader is someone who already pays for or is willing to use Cloudflare and would rather not run a VPS for a handful of users. The README is explicit about scope: 'This project is for learning and discussion purposes only. Please back up your vault regularly.' That is a disclaimer, not marketing, and it should shape how you read everything else on the page.

How the Worker, D1 and R2 fit together

The architecture is visible in the repository layout rather than in a design document. Two Wrangler configs exist, `wrangler.toml` and `wrangler.kv.toml`, and the README states they define binding names. That is the whole deployment contract: bindings point the Worker at a D1 database and either an R2 bucket or a KV namespace, and the deploy scripts differ only in which config is used. Schema management is handled at runtime. The README says the Worker 'initializes the D1 schema on first request - no manual SQL upload.' That is convenient and also the first thing to think about: migrations happen as a side effect of traffic, so a failed first request is a failed migration. Clients talk to the Worker over the Bitwarden API surface, which is why the tested list includes Windows desktop, mobile, browser extension and Linux desktop. Encryption stays client-side, consistent with the zero-knowledge topic tag; the server stores what the clients send it.

Deploying with npm run deploy and the secrets you must set

The CLI path is short. Clone the repository, then `npm install`, then `npx wrangler login`, then `npm run deploy` for the default R2 mode or `npm run deploy:kv` for KV. Local work uses `npm run dev` and `npm run dev:kv`. The dashboard path is the same code with Cloudflare doing the build: fork the repository, connect it through Workers and Pages, set the build command to `npm run build` and the deploy command to `npm run deploy` (or `npm run deploy:kv`). Two configuration items matter. First, `JWT_SECRET` must exist as a Worker secret; the README asks for a random string of at least 32 characters and warns against temporary or example values. Second, `HIDE_WEB_VAULT` set to `1` as a text variable makes server-hosted frontend pages and static assets return `404 Not Found` while login, sync, attachment, icon and notification endpoints keep serving Bitwarden clients. An already installed or cached PWA keeps working from its local frontend. Deleting the variable, or setting it to anything other than `1`, restores the hosted vault.

The storage choice is a real fork in the road

R2 and KV are not interchangeable, and the README's own table makes the trade-off plain. R2 requires a card on file and allows a single attachment or Send file up to 100 MB as a soft, adjustable limit, with 10 GB free. KV needs no card but caps a single file at 25 MiB, a Cloudflare limit rather than a NodeWarden one, with 1 GB free. So KV mode is the no-billing-relationship option and R2 is the large-attachment option. If your vault contains disk images, database dumps or video, KV will reject them and no amount of configuration fixes that. Pick before you migrate data, not after.

What the feature table leaves out

Two rows are marked as not implemented: organizations, collections and roles, and SSO, SCIM and directory integration. Everything else in the comparison is present, including TOTP with `steam://` support, passkey login, YubiKey as a second factor, API keys for the CLI, recovery codes, push sync, WebDAV and S3 incremental backups, and a `POST /fill-assist` endpoint. Multi-user exists through invite-code registration, which is a different model from an organization: it gives several people their own vaults on one server, not shared collections with role assignments. For a family or a small group of colleagues each holding separate credentials, that is enough. For a company that needs to revoke a departing employee's access to a shared collection, it is not. Treat the two missing rows as the boundary of the product, not as a roadmap promise.

Verified clients, unverified clients, and the macOS gap

The tested list is short and honest: Windows desktop, mobile app, browser extension and Linux desktop are checked, while macOS desktop is marked 'not fully verified yet.' Since the entire value proposition is that official Bitwarden clients work unmodified against this server, an unverified client is a genuine risk rather than a footnote. The README also warns that the default Workers hostname may be unreachable on some networks and suggests attaching a custom domain in Workers settings. Both items point the same way: compatibility here is a claim about the API, and the only proof is your own client on your own network. Test the sync cycle on the device you rely on before you move a real vault onto it.

Maintenance, upgrades and the licence discrepancy

Upgrades are git-shaped. The README describes a manual flow: open your fork on GitHub, click Sync fork, then Update branch when the sync banner appears. Releases arrive frequently enough that this is not a theoretical concern; v1.8.0, v1.7.4 and v1.7.3 all landed within roughly two months in 2026, with titles naming deployment control, session reliability, password tools and two-step login changes. Every sync is a deploy, and because the schema is initialized on first request, you are trusting the new code to migrate your D1 database correctly. Back up before you sync. On licensing, the material disagrees with itself: the repository metadata reports NOASSERTION while the README badge and License section state LGPL-3.0. LGPL-3.0 is a copyleft licence with obligations that matter if you distribute a modified server, so read the actual LICENSE file rather than the badge. This is not legal advice.

NodeWarden against Vaultwarden, and who should pick which

The README credits Vaultwarden as a server implementation reference, and the two solve the same problem from opposite directions. Vaultwarden is a Rust binary you run on a machine you control, which means you own patching, TLS, backups and uptime, and in exchange you get a server that does not depend on a third party's free tier or billing relationship. NodeWarden inverts that: Cloudflare owns the runtime and the availability, you own almost no operational surface, and the cost is that your vault lives inside one vendor's platform and its quotas. Vaultwarden's project has organizations support; NodeWarden's table says organizations are not implemented. If you want the smallest possible operational footprint and a personal or small-group vault, NodeWarden is the shorter path. If you want feature parity with the official server or you distrust the dependency on Cloudflare, the binary-on-a-box model is the one to take.

Editorial conclusion

Adopt NodeWarden if you want a personal or small-team Bitwarden-compatible vault without operating a server, and if the feature table's two red rows (organizations, SSO/SCIM) do not apply to you. Do not adopt it if you need collections, roles, or directory integration, and do not treat the README's 'learning and discussion purposes only' disclaimer as boilerplate. Before you trust a vault to it, verify three things yourself: that the clients you actually use are covered (macOS desktop is marked not fully verified), that your chosen storage mode fits your attachment sizes (KV caps a single file at 25 MiB, R2's soft limit is 100 MB), and that you have read the LICENSE file, since the repository metadata reports NOASSERTION while the README states LGPL-3.0.

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. shuaiplus/nodewarden on GitHub