Bitwarden "no healthy upstream" Error: What It Means and How to Fix It

You open Bitwarden to grab a password and instead of your vault you get a blank page with three words: no healthy upstream. It looks alarming, but it is one of the more predictable errors on the web — and in most cases it has nothing to do with your account, your master password, or your data. Here is exactly what it means and how to fix it, whether you use Bitwarden's cloud or host it yourself.

What "no healthy upstream" actually means

"No healthy upstream" is not a Bitwarden message — it comes from the load balancer or reverse proxy sitting in front of Bitwarden's application servers (Bitwarden's cloud uses the Envoy proxy, which is where the exact wording comes from). In plain terms: the front door is open and answering, but every server behind it that is supposed to handle your request is failing its health check or is unreachable. The proxy has no "healthy" backend — no healthy upstream — so it returns an error instead of your vault.

The single most important consequence: this is a server-side availability problem, not an authentication or data problem. Your vault is not deleted, your master password is not wrong, and your account is not locked. Something between you and the database is temporarily down.

First step: is it Bitwarden, or is it you?

Before you change anything, figure out which side the problem is on. It takes thirty seconds.

  1. If you use Bitwarden's cloud (you log in at vault.bitwarden.com or vault.bitwarden.eu): open status.bitwarden.com. If there is an active incident, the error is on Bitwarden's end and there is nothing to fix — it typically clears within minutes. You can also check the community forum or Bitwarden's status account for confirmation.
  2. If you self-host (your own domain, Docker, or the Vaultwarden fork): the problem is on your side. Skip to the self-hosted section below.

Your passwords are still safe during this error

The Bitwarden desktop app, mobile app, and browser extension all keep an encrypted local cache of everything you have synced. Even while the server shows "no healthy upstream," passwords you already have will still autofill offline. You only lose the ability to sync new changes until the server is back — so don't panic and don't try to reset anything.

If you use Bitwarden cloud: what to do

When the status page shows an incident, the fix is simply to wait — but you can make the wait painless:

  1. Use your local cache in the app or extension in the meantime; your existing logins keep working.
  2. Do not uninstall the app, clear its data, or log out. Logging out wipes the local cache, and if the server is down you won't be able to log back in and re-sync.
  3. Retry the web vault after a few minutes. Cloud "no healthy upstream" incidents are almost always short.

If the status page is all-green but you still get the error, it is usually your own network or a caching layer in between. Try a different network (mobile data instead of Wi-Fi), a private/incognito window, or flush your DNS. A stale corporate proxy or a VPN that routes Bitwarden through a broken node can produce this too.

If you self-host Bitwarden or Vaultwarden: the real fixes

On a self-hosted install, "no healthy upstream" means your reverse proxy (Nginx, Traefik, Caddy, or the bundled proxy) can reach itself but not the Bitwarden backend container. Work through these in order — they are listed by how often they are the culprit.

1. The backend container is stopped or crash-looping

The most common cause. Check what is actually running:

docker ps -a
# look for the bitwarden / vaultwarden container —
# is it "Up", or is it "Exited" / "Restarting"?

If it is exited or restarting, read its logs to see why it died on startup:

docker logs --tail 100 vaultwarden
# or, for the official self-host stack:
docker logs --tail 100 bitwarden-app

Common startup killers: a full disk, a bad value in your .env / config file, or a database it can't reach. Fix the underlying issue, then bring the stack back up (docker compose up -d). A large share of cases are resolved simply by restarting a container that got stuck after a host reboot or an update.

2. The reverse proxy points to the wrong address or port

If the backend is running but the proxy still can't reach it, the proxy is aiming at the wrong place. Confirm the internal port the container exposes, then make sure your proxy's proxy_pass (Nginx), service loadbalancer port (Traefik), or reverse-proxy target (Caddy) matches it exactly. A container renamed during an upgrade, or a Docker network the proxy is no longer attached to, will both produce "no healthy upstream." Restart the proxy after any change.

3. An expired or mismatched TLS certificate

If your certificate expired, some proxy setups mark the upstream as unhealthy rather than serving an obvious certificate warning. Check your certificate's expiry and renew it (for Let's Encrypt, confirm the renewal cron/timer actually ran). This is a frequent cause on servers that were set up once and left alone for months.

4. A failed or half-finished update

If the error started right after you pulled a new image, an updated container may expect a migrated database or a new config key it didn't get. Check the logs (step 1), consult the release notes for breaking changes, and if needed roll back to the previous image tag while you sort out the migration. Always snapshot your data volume before upgrading a password manager.

Quick recovery checklist

  1. Check status.bitwarden.com (cloud) — if red, just wait.
  2. Keep using your local cache; don't log out or clear app data.
  3. Self-hosted: docker ps -a → is the backend up?
  4. docker logs the backend → find why it crashed.
  5. Verify the reverse proxy targets the right port and network.
  6. Check the TLS certificate hasn't expired.
  7. Restart the stack; roll back the image if an update broke it.

Frequently Asked Questions

What does "no healthy upstream" mean in Bitwarden?

It is an error from the load balancer or reverse proxy in front of Bitwarden saying it has no working backend server to send your request to. The proxy is up, but every application server it knows about is failing its health check or is unreachable. It is not a password or account problem.

Is it a Bitwarden outage or my fault?

If you use Bitwarden's cloud, check status.bitwarden.com — a transient "no healthy upstream" there almost always means a short outage that resolves on its own. If you self-host, the cause is on your side: a stopped container, a misconfigured reverse proxy, or an expired certificate.

How do I fix it on self-hosted Bitwarden or Vaultwarden?

Confirm the backend container is running (docker ps), check its logs for a crash on startup, verify your reverse proxy points to the correct internal port, and make sure the TLS certificate has not expired. Restarting the stack fixes it when the cause is a crashed or stuck container.

Can I still access my passwords during this error?

Yes. Bitwarden apps and browser extensions keep an encrypted local cache, so passwords you have already synced remain available offline even when the server returns "no healthy upstream." You just cannot sync new changes until the server is reachable again.

MC
Marcus Chen Software Troubleshooting Writer, Hovbi

Marcus writes step-by-step fixes for self-hosted apps, reverse proxies, and the everyday software errors that send people searching at the worst possible moment. He tests each fix on a real setup before publishing.

Still stuck on a different error?

Search for the exact message you're seeing and get targeted fixes.

Search error fixes