DNS-pointer for detecting on-site Bitwarden

Feature Requests Password Manager
19

Hi everyone — I’d like to pick up the topics discussed here: https://community.bitwarden.com/t/dns-pointer-for-detecting-on-site-bitwarden/888 and see if the idea below could be a good solution to the same need. Tagging folks from that closed thread for visibility: @kspearrin and @bw-admin.

Many orgs would love auto-discovery of a self-hosted Bitwarden server based on the user’s email domain. DNS SRV/TXT would be a natural fit on paper, but extensions can’t perform raw DNS lookups, so that approach can’t cover the browser clients.

Suggestion: add an HTTP(S) discovery endpoint using the “.well-known” convention.

How it would work (client flow)

  1. User enters email user@company.tld.
  2. Client (desktop, mobile, browser extension) performs a GET to:
    https://company.tld/.well-known/bitwarden
  3. If present and valid, the client pre-configures the server URL(s) and asks the user to confirm (or auto-applies, depending on policy).

Minimal JSON schema (example)

{
  "version": 1,
  "server": "https://vault.company.tld",
  "services": {
    "api": "https://vault.company.tld/api",
    "identity": "https://vault.company.tld/identity",
    "icons": "https://vault.company.tld/icons"
  },
  "displayName": "Company Bitwarden"
}
  • version — for future compatibility.
  • server — the base URL to populate in the client’s “Self-hosted” field.
  • services — optional overrides for specific endpoints if needed.
  • displayName — optional, shown in the UI as a friendly label.

Why .well-known?

  • Works everywhere: pure HTTPS fetch, so it functions in browser extensions (no DNS APIs required).
  • Simple to deploy: a static file on the organization’s web root or reverse proxy.
  • Predictable and cacheable: standard path, easy to manage with CDNs.

Security considerations

  • HTTPS only (hard-fail on HTTP).
  • User confirmation on first discovery (TOFU), or enforce via enterprise policy/MAM/MDM.
  • Optional origin pinning: if the discovered URL uses a different domain, the client can warn the user.
  • Optional signature field for organizations that want to sign the JSON with a known public key (advanced, can be a v2+ enhancement).

Backwards compatibility & deployment

  • If the file is missing or invalid, the client falls back to current manual entry/policy methods.
  • Enterprises can roll this out incrementally without breaking existing clients.
  • Admins can continue to use desktop data.json, browser policies, or MDM today; .well-known simply reduces friction for first-time setup.

Acceptance criteria (for implementation)

  • When a user enters an email, clients attempt GET https://<domain>/.well-known/bitwarden.
  • Valid JSON response pre-populates the self-hosted server URL in the UI.
  • Failure modes are silent and non-blocking; no change to current behavior.
  • Feature can be enabled/disabled by policy.
  • Desktop, mobile, and browser extension parity.

This would give organizations a standards-based way to guide users to the right server without relying on DNS capabilities that extensions don’t have.

Best regards,

Bjoern