Bitwarden Self-Hosted: Deploying a Private Vault With Docker in NZ

Running your own credential server keeps every encrypted vault file, master key and file attachment on hardware you control, rather than in a provider’s shared cloud. For privacy-minded New Zealanders, IT teams and homelab hobbyists, that is the whole appeal of a self-hosted password manager: the same zero-knowledge encryption most people already rely on, but with the database sitting on a mini-PC, home server or private cloud instance you own. This guide explains how the official Bitwarden self-hosted stack works, what changed with the new single-container “Lite” build, and the exact stages — Docker, HTTPS, hardening and backups — needed to run it safely from Aotearoa.

What a Self-Hosted Password Manager Actually Is

A self-hosted password manager is a deployment model where the server software, the database and the cryptographic handshakes all run on hardware you own or lease, instead of on a vendor’s multi-tenant cloud. Your apps still authenticate against a server, but that server is your own network node rather than a data centre in the United States or Europe. Crucially, the platform keeps its zero-knowledge design: your master password is turned into an encryption key on your device, and your vault is decrypted client-side, so even the server never sees your plaintext.

The practical payoff is control. You decide where the data physically lives, who can create an account, how backups are handled, and which email server sends invitations and alerts. You can run the software on a low-power box tucked in a cupboard, an on-premises office server, or an isolated virtual private server (VPS). The trade-off is responsibility — the uptime, patching and backups that a commercial provider normally handles quietly in the background now become your job. If that sounds like more than you want to take on, a hosted account on Bitwarden’s own cloud remains a perfectly private option; self-hosting simply moves the trust boundary onto your own equipment.

Standard vs Lite: the Architecture Has Changed

For years, self-hosting the official server meant running a heavy stack of around a dozen separate containers to handle the API, identity, admin, events and background jobs, backed by a bundled Microsoft SQL Server (MSSQL) database. That “standard” deployment still exists and suits large organisations, but it is demanding on hardware. Bitwarden’s newer build — launched in beta as “Unified” and renamed Bitwarden Lite when it reached general availability in December 2025 — folds the whole service into a single Docker image and adds a choice of lightweight databases. For a household or small team, Lite is now the sensible starting point.

The headline difference is efficiency. A personal Lite instance using an on-disk SQLite database can idle in a couple of hundred megabytes of RAM, which is why it runs comfortably on a Raspberry Pi or a repurposed old laptop — something the multi-container standard stack could never do.

The Core Blueprint: Deploying Bitwarden With Docker

Docker is the most stable and reproducible way to run the server. It wraps the application in an isolated, sandboxed environment, keeping it clear of library conflicts with your host operating system, and it makes updates a simple matter of pulling a fresh image. Bitwarden publishes its official Lite production image through the GitHub Container Registry (GHCR) at ghcr.io/bitwarden/lite, so your instance tracks verified upstream releases rather than an unofficial fork.

Before you begin, the host needs a clean install of Docker Engine (version 26 or newer) and the Docker Compose plugin. The server will run on Windows or macOS through their virtualisation layers, but a dedicated Linux host — a tidy Ubuntu Server or Debian instance — is the recommended base for uptime and security. You will also need one free item from Bitwarden: a personal installation ID and key, generated at no cost from bitwarden.com/host, which authenticate your self-hosted build to the licensing endpoint.

Preparing the Configuration File

Lite is driven by a plain-text settings file (commonly named settings.env) that holds every operational parameter. Rather than editing code, you set environment variables that tell the container how to behave. The essential ones are:

• BW_DOMAIN — the domain name your vault will answer on, for example vault.yourdomain.nz.
• BW_DB_PROVIDER — the database engine: sqlite, postgresql, mysql or sqlserver.
• BW_DB_FILE — the path to the SQLite file (only when you choose the SQLite provider; it is created automatically if it does not exist).
• BW_INSTALLATION_ID and BW_INSTALLATION_KEY — the values issued from the Bitwarden host page above.
• SMTP settings (globalSettings__mail__smtp__host, port, username and password) — required so the server can send verification emails, invitations and admin logins.

Building and Launching the Container

With the settings file saved in your working directory, you can either run the image directly or, more maintainably, describe it in a docker-compose.yml file and start it with a single command. In broad strokes the launch sequence is:

• Create a dedicated, non-privileged directory on the host to keep the application files away from the root of your operating system.
• Point a persistent volume — a host folder such as ./bwdata mapped to /etc/bitwarden inside the container — so your database and keys survive container rebuilds.
• Reference the settings.env file and the ghcr.io/bitwarden/lite image, then bring the stack up in detached mode with docker compose up -d.

Because all of your user data lives in that mounted volume, you can safely stop, delete and recreate the container itself at any time without losing a single vault entry.

Mandatory Security: HTTPS and a Reverse Proxy

One rule cannot be skipped: Bitwarden refuses to work over an unencrypted connection. The Web Crypto APIs that browser extensions and mobile apps use for client-side decryption only run in a secure context, so pointing an app at a plain http:// address produces immediate login failures. SSL is required — either enabled directly inside the container, or, more commonly, handled by an SSL-terminating reverse proxy sitting in front of it.

A reverse proxy is a small service that receives inbound web requests, presents a valid certificate and forwards clean traffic to the hidden container port. Nginx, Caddy and Traefik are the usual choices. For home users and small teams, Caddy is the friendliest option because it obtains and renews free Let’s Encrypt TLS certificates automatically, with almost no configuration. Whichever you pick, the proxy also acts as a useful first line of defence, keeping the container off the open internet.

Linking the Official Apps to Your Server

Once the proxy is live and serving HTTPS on your domain, connecting devices is straightforward — and you do not need any modified or unofficial client. The genuine apps on the App Store, Google Play and the browser extension stores all include a built-in setting for self-hosted servers. Before you type any email address or master password:

• Open the app or extension and, on the first login screen, tap the region or server selector (often shown as a globe or cog icon).
• Choose the “self-hosted” option and enter your server URL, for example https://vault.yourdomain.nz.
• Save the setting, then log in or create your account exactly as you would on the cloud version.

From that point the app syncs against your private node instead of Bitwarden’s cloud, while every other feature — the password generator, autofill, secure notes and organisations — behaves normally.

Hardening the Perimeter

Self-hosting hands you total control, which also means every default now matters. An exposed server with loose settings is exactly what automated botnets scan for, so lock it down as soon as your own account exists. The single most important step is to switch off open registration, so strangers who find your domain cannot create accounts on your hardware.

• Disable public sign-ups: set globalSettings__disableUserRegistration=true in your settings file to block new account creation.
• Protect the admin portal correctly: Bitwarden’s System Administrator Portal is not guarded by a static token. Instead you list authorised email addresses in adminSettings__admins, and each login is a one-time magic link sent to that inbox — which is why a working SMTP server is essential. (The ADMIN_TOKEN approach some tutorials describe belongs to the unofficial Vaultwarden project, not to official Bitwarden.)
• Enforce two-factor authentication: require every account to use an authenticator app (TOTP) or a hardware security key such as a YubiKey.
• Add intrusion protection: put Fail2ban or a Cloudflare access layer on the host to throttle and block IP addresses that repeatedly fail logins.

These four settings turn a public, discoverable service into a private one that only you and your invited users can reach — a core habit in wider cyber security hygiene.

Critical Infrastructure: An Offsite Backup Strategy

The biggest risk of self-hosting is losing the one copy of your vault. Because the platform is zero-knowledge, nobody — not even Bitwarden — can recover your data if the disk fails or the storage volume corrupts and you have no backup. Your credentials would simply be gone.

The safeguard is the industry-standard 3-2-1 rule: keep three copies of your data, on two different types of media, with at least one copy stored offsite. A Lite instance makes this easy: the SQLite database file can be copied while the server is running, so a short scheduled script can archive the database, your keys and any attachments into a timestamped, compressed file ready to be pushed to offsite storage. Encrypt those archives before they leave the building, and test a restore occasionally — an untested backup is only a hope, not a plan.

Maintenance and the Container Lifecycle

Keeping the server patched is what protects you from newly discovered exploits, and with Docker the routine is quick. Because your data sits in the persistent volume, you can update the software without touching a single stored password. A sensible monthly check looks like this:

• Pull the latest image with docker compose pull.
• Recreate the container using docker compose up -d, which swaps in the new image and leaves your volume intact.
• Update the host operating system and your reverse proxy, then confirm your TLS certificate is still valid and renewing.

If anything goes wrong, you can roll back to the previous image because your vault data was never inside the container in the first place.

Running the Setup From New Zealand

When you host locally in Aotearoa, latency is worth a thought. If you run the container on a home box on fast fibre or 5G from Spark, One NZ or 2degrees, sync is effectively instant on your own network. If you prefer a cloud VPS, choose a provider with nodes close to home — Auckland-based facilities, or the nearby Sydney and Melbourne regions of the large cloud platforms — to keep sync and large attachment downloads snappy.

A well-tuned private vault is a fast, fully private hub for the accounts New Zealanders use every day:

• Online banking: store credentials for ANZ, ASB, BNZ, Westpac NZ and Kiwibank, with autofill that never touches a third-party cloud.
• Government portals: keep access details for RealMe, the IRD’s myIR and ACC organised and secure.
• Investing platforms: protect logins for Sharesies, Hatch, Kernel and similar services.
• Everyday sites: speed up sign-ins across Trade Me, retail accounts and Kiwi news subscriptions.

Trade-offs to Weigh First

Total autonomy has a cost in effort and resilience. Running your own server is an ongoing, hands-on commitment: host patching, verifying that offsite backups actually ran, and watching logs for unusual activity. And because the vault is decoupled from a commercial cloud, a power cut or hardware fault at home means your devices cannot sync new items until the server is back. A few habits make the setup dependable:

• Put the server and router on an uninterruptible power supply (UPS) so a brief outage does not take the vault offline.
• Keep the offline cache enabled in each client app, so you can still read existing passwords when the server is unreachable.
• Watch the reverse proxy logs to be sure Let’s Encrypt certificates renew before they expire.

Weighed against those responsibilities is the reward: your encrypted database lives entirely on hardware you control, out of reach of large-scale cloud breaches. If you are still deciding between hosting it yourself and a paid cloud plan, our breakdown of Bitwarden pricing and plans puts the numbers side by side. For most people a managed cloud account is simpler; for those who value data sovereignty above convenience, a hardened Lite deployment delivers it without giving up the official apps.

Frequently Asked Questions

Is it legal to self-host my own password server in New Zealand?

Yes. Bitwarden’s server code is open source, and there is nothing in New Zealand law that stops an individual or business from running it on their own hardware. You are simply hosting software you are licensed to use.

Can Bitwarden see my passwords if I run their official image?

No. The platform uses a zero-knowledge model: your vault is encrypted on your own device with a key derived from your master password before anything syncs. The server — whether it is Bitwarden’s or your own — only ever holds encrypted data.

Why does my app show an error when I connect to the server?

Almost always because the connection is not secured with HTTPS. Bitwarden deliberately blocks logins over unencrypted links, so you need a reverse proxy presenting a valid TLS certificate on your domain before the apps will connect.

What is the difference between the standard and Lite deployments?

The standard deployment runs around a dozen containers and a bundled MSSQL database, needing at least 2 GB of RAM. The Lite deployment packs everything into one image, runs on as little as 200 MB of RAM, and lets you use SQLite, PostgreSQL, MySQL/MariaDB or MSSQL.

How much does it cost to run a self-hosted server each year?

On your own hardware, such as a Raspberry Pi or an old PC, the only ongoing cost is the electricity it uses. On a cloud VPS, a basic virtual server typically runs from roughly NZ$5 to NZ$12 a month, depending on the provider and specifications.