How to Set Up Vaultwarden on Docker - Beginner Guide

FTC Disclosure: This article contains affiliate links. If you purchase through these links, we may earn a commission at no additional cost to you.

Key Takeaways

Vaultwarden gives you a lightweight, Bitwarden-compatible password manager you can run on your own hardware with very modest resource needs.
For most homelabbers, the best starting point is a simple Docker deployment on your LAN first, then HTTPS and remote access once the basics are stable.
The setup itself is not the hard part. The important part is understanding why HTTPS, backups, updates, and signup restrictions matter before you trust it with your real credentials.
Your most important files live in Vaultwarden's data/ directory, so backup planning is part of the initial setup, not a future cleanup job.
If you want a self-hosted password manager without the heavier footprint of Bitwarden's full self-hosted stack, Vaultwarden is usually the right beginner choice.

If you have been meaning to move away from browser-saved passwords, random note files, or a pile of reused logins that somehow still power half your digital life, you are exactly the person this guide is for.

A self-hosted password manager sounds like one of those projects that should come later, after you learn Docker better, after you buy better hardware, after your homelab feels more "finished." In practice, it is one of the first services worth setting up properly because it helps protect everything else you are going to build.

That is why this matters.

When your lab grows, so does the number of credentials attached to it. Reverse proxies, DNS filters, router logins, NAS shares, VPN accounts, admin dashboards, SSH keys, API tokens, and two-factor recovery codes all start multiplying. If you keep that mess in your head or scatter it across text files, you are not building a lab. You are building future pain.

Vaultwarden fixes that problem in a way that still feels approachable for beginners. It is lightweight, it works with the official Bitwarden apps, and it fits nicely into the kind of Docker-based setup many homelabbers already use.

If you are still deciding whether self-hosting passwords is even the right move, read Self-Hosted Password Managers: Why You Need One and How to Get Started first. If your next concern is protecting the box you will run this on, pair this guide with SSH Hardening Guide: How to Secure Your Homelab Server Without Locking Yourself Out and How to Set Up Authelia SSO for Your Homelab: A Beginner's Complete Guide.

What Vaultwarden is, in plain English

Vaultwarden is a community-maintained, Bitwarden-compatible server written in Rust. The easiest way to think about it is this:

Bitwarden is the familiar app ecosystem people already know
Vaultwarden is a lighter self-hosted server that works with those same official clients
Docker makes deploying it feel more like plugging in an appliance than building one from scratch

If the official Bitwarden self-hosted deployment is a full-size server rack, Vaultwarden is the compact, efficient mini PC that still gets the job done.

That analogy matters because beginners often assume "lighter" means "cut-down" or "unsafe." It does not. It means you are choosing the tool that fits a personal lab or small household better.

A few reasons Vaultwarden is popular in homelabs:

it runs well on modest hardware
it works with Bitwarden desktop, mobile, and browser clients
it is easier to deploy than the heavier official self-hosted Bitwarden stack
it keeps your vault data under your control
it fits naturally into a Docker-first homelab

Official references worth bookmarking:

What you'll need

Before we touch commands, let me save you a beginner mistake.

People often think they need enterprise hardware to self-host something important. For Vaultwarden, that is usually not true. This service is lightweight. Reliability matters more than raw horsepower.

Here are three practical picks if you are building or upgrading a small host for services like Vaultwarden:

Beelink S12 Pro Mini PC - a quiet low-power box that is more than enough for Vaultwarden and a handful of other containers. Check price on Amazon
Samsung T7 Shield 1TB - useful for off-host backups of your Vaultwarden data/ directory and exported emergency copies. Check price on Amazon
APC BX1500M UPS - sudden power loss and password databases are a bad combination. A small UPS buys you clean shutdowns and calmer weekends. Check price on Amazon

You do not need all three to get started. But if Vaultwarden will live alongside other core services, these are the kinds of upgrades that quietly make self-hosting less fragile.

For the tutorial itself, you need:

an Ubuntu server or VM with internet access
a user account with sudo
Docker Engine and the Docker Compose plugin
a domain or subdomain later if you want proper HTTPS and remote access
a plan for backups before you import all your passwords

Step 1: Install Docker and Docker Compose

Why this matters:

Docker gives you a repeatable deployment. That means updates, migrations, and recovery are simpler later. You are not just trying to make Vaultwarden work today. You are trying to make future-you hate it less.

On Ubuntu, the safest beginner path is still the official Docker repository. The current Docker docs are here: Install Docker Engine on Ubuntu.

Run these commands:

sudo apt-get update
sudo apt-get install -y ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo \"$VERSION_CODENAME\") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt-get update
sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
sudo usermod -aG docker $USER
newgrp docker

Now verify the install:

docker --version
docker compose version

If those commands return versions without errors, you are ready for Vaultwarden.

Step 2: Create a working directory and admin token

Why this matters:

Your future backups and updates become much easier if you keep every app in its own predictable folder. Think of this like giving every service its own labeled drawer instead of tossing tools into one giant junk box.

Create the project directory:

mkdir -p ~/apps/vaultwarden
cd ~/apps/vaultwarden

Now generate a long admin token:

openssl rand -base64 32

Copy that output somewhere safe. You will use it as your Vaultwarden admin token.

Create an .env file:

nano .env

Paste this and change the values:

VW_DOMAIN=http://localhost:8080
VW_ADMIN_TOKEN=replace-this-with-your-long-random-token

A quick note on VW_DOMAIN:

for a first LAN-only test, http://localhost:8080 is fine
for a real long-term deployment, use your final HTTPS URL such as https://vault.example.com

If you plan to expose Vaultwarden outside your LAN, do not stop at plain HTTP. The Vaultwarden project strongly recommends HTTPS before enabling sensitive admin access, and that is good advice, not paranoia.

Step 3: Create the Docker Compose file

Why this matters:

This file is the recipe for the whole service. If your server dies tomorrow, this compose file plus your data/ backup is the difference between "minor inconvenience" and "I guess I am resetting every password I own."

Create the file:

nano docker-compose.yml

Paste this:

services:
  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: unless-stopped
    environment:
      DOMAIN: ${VW_DOMAIN}
      SIGNUPS_ALLOWED: "true"
      ADMIN_TOKEN: ${VW_ADMIN_TOKEN}
      WEBSOCKET_ENABLED: "true"
    volumes:
      - ./data:/data
    ports:
      - "8080:80"

This compose pattern is intentionally simple. I validated the structure with docker compose config before publishing this article.

A few things worth understanding here:

./data:/data is where your persistent Vaultwarden data lives
8080:80 means you will reach the service at http://your-server-ip:8080
SIGNUPS_ALLOWED starts as true so you can create the first account
WEBSOCKET_ENABLED helps live updates work smoothly in clients

If you already run a reverse proxy, you can remove the direct port mapping later and proxy it internally instead. If you are not there yet, do not worry. Start simple.

Step 4: Start Vaultwarden and verify it works

Why this matters:

A lot of beginners jump straight to app setup screens without first checking whether the container itself is healthy. That is like hearing a car start and immediately driving onto the highway without checking whether the dashboard is on fire.

Start the stack:

docker compose up -d

Check container status:

docker compose ps

Check logs if something looks wrong:

docker compose logs -f

You can also test the HTTP response locally:

curl -I http://localhost:8080

If everything is healthy, open a browser and visit:

http://YOUR-SERVER-IP:8080

You should see the Vaultwarden web vault.

Step 5: Create your first account, then disable open signups

Why this matters:

Leaving public signup enabled on a password manager is like installing a strong front door and then leaving the side gate swinging open. During the first setup, it is convenient. After that, it is unnecessary risk.

In the web interface:

Create your first user account
Choose a strong master password
Log in and confirm the vault works

Once that account exists, edit your compose file so signups are disabled:

SIGNUPS_ALLOWED: "false"

Then restart the stack:

docker compose up -d

If you want to reach the admin panel later, it will be available at:

http://YOUR-SERVER-IP:8080/admin

Use the admin token you generated earlier.

Important: if you plan to expose the service publicly, move to HTTPS before you treat the admin page as normal operating territory. The official Vaultwarden admin-page docs make the same recommendation for good reason.

Step 6: Point your Bitwarden apps at your server

Why this matters:

This is the moment the project starts feeling real. The official Bitwarden clients are the familiar front end. Vaultwarden is the server behind them. Once you connect the two, your self-hosted setup feels like a normal password manager instead of a science fair project.

Install the client you want from the official Bitwarden downloads page:

browser extension
desktop app
Android app
iPhone app

When signing in, look for self-hosted or server URL options and enter your Vaultwarden URL.

Examples:

http://192.168.1.50:8080 for a LAN-only test
https://vault.example.com for a proper TLS-backed deployment

you can create a test login entry
you can log out and back in
your browser extension sees the same vault

This is also a good point to enable two-factor authentication inside your vault account.

Step 7: Move from "it runs" to "it is safe to depend on"

Why this matters:

Getting a container online is the easy part. The real skill in self-hosting is learning the difference between a demo and a dependable service.

Here are the first hardening steps I recommend.

Use HTTPS before remote exposure

If Vaultwarden is only on your private LAN while you test, HTTP is fine for the first few minutes. If you plan to use it across the internet, stop and add real TLS first.

Why this matters:

Bitwarden clients expect a properly trusted certificate for a smooth experience. More importantly, a password manager is exactly the kind of service where transport security is non-negotiable.

A common beginner pattern is:

start with direct port access on the LAN
confirm Vaultwarden works
place it behind your reverse proxy
switch VW_DOMAIN to the final https:// URL
restart the stack

If you are still building those pieces, Pi-hole vs AdGuard Home and How to Set Up a Self-Hosted Docker Registry: A Complete Beginner's Guide are helpful follow-up reads because they reinforce the same DNS and container management habits.

Back up the `data/` directory

Why this matters:

Your passwords are not stored in the compose file. They live in the persistent data. If you do not back that up, you are trusting your digital life to a single folder on a single machine.

A simple manual backup looks like this:

cd ~/apps/vaultwarden
mkdir -p ~/backups

tar czf ~/backups/vaultwarden-$(date +%F).tar.gz data

That is the bare minimum. Better than nothing, not enough forever.

A healthier habit is to copy those backups to another device or external drive. Think of it like keeping your house key in a safe place outside the house. A backup stored only on the same server protects you from mistakes, but not from disk failure, theft, or fire.

Keep updates boring

Why this matters:

With infrastructure, boring is success. You want updates to feel like changing batteries, not defusing explosives.

To update Vaultwarden:

cd ~/apps/vaultwarden
docker compose pull
docker compose up -d

Then verify:

docker compose ps
docker compose logs --tail=50

Do not update without a recent backup. That is one of those lessons people only need to learn once, but it is a rough lesson.

Common mistakes

These are the mistakes I see beginners make most often with Vaultwarden.

1. Exposing it publicly before HTTPS is ready

If your password manager is internet-facing, TLS is not optional cleanup work.

2. Forgetting to disable signups

Leaving SIGNUPS_ALLOWED on forever is unnecessary risk, especially if the service later becomes externally reachable.

3. Treating backups as a future project

Your first backup should happen before you import your real vault, not after you get comfortable.

4. Changing the domain later without updating configuration

If you move from http://localhost:8080 to https://vault.example.com, update VW_DOMAIN and restart the stack. Mismatched URLs create confusing client behavior.

5. Hosting it on a box you never maintain

A password manager is core infrastructure. If the host is unstable, never updated, or constantly power-cycled without warning, that risk becomes your vault's problem too.

FAQ

Is Vaultwarden the same thing as Bitwarden?

Not exactly. Vaultwarden is a Bitwarden-compatible server implementation. You still use the official Bitwarden clients, but the server is your own lightweight self-hosted deployment.

Can I run Vaultwarden without HTTPS?

You can for a short LAN-only test, but you should not expose it to the public internet without proper HTTPS. A password manager is one of the last places to compromise on transport security.

How much hardware does Vaultwarden need?

Very little compared to many homelab services. A small VM or low-power mini PC is usually enough. Reliability, storage health, and backups matter more than CPU muscle.

What exactly should I back up?

Back up the Vaultwarden data/ directory. That is where the important persistent data lives. Keep at least one copy off the host itself.

Should I choose Vaultwarden or the full self-hosted Bitwarden stack?

For most individual homelabbers and households, Vaultwarden is the easier and more practical starting point. If you need enterprise-specific features or official vendor support, the full Bitwarden stack may make more sense.

What to learn next

Once Vaultwarden is stable, the next useful skills are not flashy. They are foundational.

Learn how to secure SSH properly with SSH Hardening Guide
Add central auth patterns with Authelia SSO for Your Homelab
Improve your DNS and local service access by comparing Pi-hole vs AdGuard Home
Build better backup habits before you trust more services with important data

If your lab still feels overwhelming, that is normal. Homelabbing gets easier when each service teaches you one repeatable lesson. Vaultwarden is a good early lesson because it teaches three important habits at once: run services predictably, secure them before convenience wins, and back up what matters before you need the backup.

That is a much better foundation than hoping your browser remembered the password you meant to save six months ago.

Key Takeaways

What Vaultwarden is, in plain English

What you'll need

Step 1: Install Docker and Docker Compose

Step 2: Create a working directory and admin token

Step 3: Create the Docker Compose file

Step 4: Start Vaultwarden and verify it works

Step 5: Create your first account, then disable open signups

Step 6: Point your Bitwarden apps at your server

Step 7: Move from "it runs" to "it is safe to depend on"

Use HTTPS before remote exposure

Back up the data/ directory

Keep updates boring

Common mistakes

1. Exposing it publicly before HTTPS is ready

2. Forgetting to disable signups

3. Treating backups as a future project

4. Changing the domain later without updating configuration

5. Hosting it on a box you never maintain

FAQ

Is Vaultwarden the same thing as Bitwarden?

Can I run Vaultwarden without HTTPS?

How much hardware does Vaultwarden need?

What exactly should I back up?

Should I choose Vaultwarden or the full self-hosted Bitwarden stack?

What to learn next

Back up the `data/` directory