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.
- If you use Bitwarden's cloud (you log in at
vault.bitwarden.comorvault.bitwarden.eu): openstatus.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. - 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:
- Use your local cache in the app or extension in the meantime; your existing logins keep working.
- 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.
- 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
- Check
status.bitwarden.com(cloud) — if red, just wait. - Keep using your local cache; don't log out or clear app data.
- Self-hosted:
docker ps -a→ is the backend up? docker logsthe backend → find why it crashed.- Verify the reverse proxy targets the right port and network.
- Check the TLS certificate hasn't expired.
- 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.
Still stuck on a different error?
Search for the exact message you're seeing and get targeted fixes.
Search error fixes