Getting started: Vault backend

This guide runs Everlock as a standalone password vault and connects an official Bitwarden client to it:

start Everlock with one vault instance on a public HTTPS vhost
point a Bitwarden client at your server and create an account
add an item and watch it sync
optionally, log in from the bw command-line client

The vault speaks the Bitwarden protocol, so you use the apps you already have — no plugins, no forks. The master password and the plaintext of your items never reach the server.

1. Start Everlock as a vault

The parts that trip people up:

--backend-vault-http enables the backend. On its own, --backend-vault-http-vhost only names the instance — without the enable flag the backend never starts and you only get the admin SSH surface. On a server that is already running, /backends enable vault-http in the admin console does the same and persists across restarts; the instance settings (vhost, store, signups) still come from the flags shown below or config/vault-http.toml.
All runtime flags go after the serve subcommand. A bare everlock --backend-vault-http-... fails with unexpected argument.
The vhost is the address clients actually use. The vault bakes it into its token issuer and into the URLs it hands back for attachments, so it must match the hostname you type into the client.

Point a domain's DNS A record at your host, open ports 80 and 443, and start Everlock. Port 80 is needed for the ACME HTTP-01 challenge; 443 serves the vault. Grab the binary for your platform from the download page; ports 80 and 443 are privileged, so grant the binary the bind capability once (sudo setcap cap_net_bind_service=+ep ./everlock) — or run it as a systemd service with socket activation, where systemd binds the ports and the process stays unprivileged.

./everlock serve \
  --frontend-http-listen-http 0.0.0.0:80 \
  --frontend-http-listen-https 0.0.0.0:443 \
  --backend-vault-http \
  --backend-vault-http-vhost vault.example.com \
  --backend-vault-http-store everlock-vault \
  --backend-vault-http-open-signups \
  --admin-user admin \
  --admin-password change-me

What this does:

starts the HTTP frontend on ports 80 and 443 (auto-enabled because an HTTP backend is on) and requests a Let's Encrypt certificate for vault.example.com
enables one vault instance reachable as https://vault.example.com
stores everything in the everlock-vault Everlock store
allows account registration (--backend-vault-http-open-signups) so you can create your account from the client — see the note in step 6
bootstraps an admin user for the SSH admin console

2. Connect a Bitwarden client and create your account

Account creation happens in the client — the server never sees your master password. Use any official Bitwarden app; the desktop app is shown here.

On the login screen, open the server / region settings (the gear or "Self-hosted" option) before logging in.
Set the Server URL to https://vault.example.com and save.
Choose Create account, and enter your email and a master password.
Log in with that email and master password.

The same flow works in the browser extension (Settings → self-hosted environment) and the mobile apps.

3. Add an item and watch it sync

In the app, create a login item — a name, username, and password — and save it. It is encrypted on the client and stored as ciphertext in the everlock-vault store.

To see sync working, open a second client — another browser's extension, your phone, or the bw CLI in step 4 — point it at the same server, log in, and the item is already there. Changes propagate over the vault's real-time notifications channel, so a new item on one device appears on the others without a manual refresh.

If the item saves on one client and shows up on another, your vault is working end to end:

HTTPS frontend with an ACME certificate
host dispatch by vhost
the Bitwarden identity + API + notifications surface
Everlock store-backed, encrypted persistence

4. Optional: the `bw` command-line client

The official CLI works against your server too. Create the account with a GUI client first (step 2); bw then logs into it.

bw config server https://vault.example.com
export BW_SESSION=$(bw login you@example.com --raw)   # prompts for the master password
bw sync
bw list items                                          # names/passwords come back decrypted

bw list items printing your items in cleartext confirms the whole chain: the server stored only ciphertext, and the client decrypted it locally.

5. What is happening under the hood

Current behavior:

frontend-http accepts the request on port 443, with a certificate it obtained and renews via ACME
backend-vault-http selects the instance by Host: vault.example.com
Everlock bypasses its HTTP Basic auth for the vault's vhost — Bitwarden clients speak their own master-password/token flow
the embedded apimeister-vault router handles the identity, API, and notification endpoints
records are stored in the everlock-vault store, one file per account, item, and folder, with every write a Git commit
names, usernames, passwords, and notes are stored only as the client's encrypted CipherStrings; the master password never reaches the server

6. Operator notes

Registration. --backend-vault-http-open-signups lets anyone who can reach the vhost register. A clean pattern is to enable it, create your account(s), then remove the flag and restart to close registration. Left off (the default), the vault is invite-gated; an Everlock-user-backed provisioning policy that ties account creation to the identity registry is planned.
Tokens survive restarts. The RS256 signing key is generated once and kept in the store (token-key.pem), so clients stay logged in across restarts.
The vhost is load-bearing. Change it and existing tokens (issued for the old hostname) stop validating; clients re-authenticate against the new one.
Multi-instance setups live in config/vault-http.toml; once that file exists it is the source of truth and the CLI bootstrap flags are no longer needed. Instance changes require a restart.
Store-backed. Heavy vault use produces many store commits — that is what gives you full, auditable history and point-in-time recovery.