Setting up your own BitWarden password manager and VaultWarden sync server

dave — Fri, 20 Aug 2021 23:30:13 +0000

Blog tags

docker-compose

docker

rust

BitWarden

password keeper

privacy

security

Vaultwarden

dave Sat 21/08/2021 - 11:30

One of the key requirements of pursuing Good Digital Hygiene is using strong passwords, and a different strong password for every application. This is relatively easy to do in theory, with the aid of clever software, but it's something desperately few people do well in practice. I'm going to explain how I've addressed this issue of digital hygiene for myself, and how you can do it for yourself, and your entire family, social circle, or community.

Password Managers (or keepers or safes) have emerged as that "clever software". A good password manager has to do a bunch of things to be really useful:

It needs to store your passwords somewhere in an encrypted form (so if someone gets your password database, they can't work out your entire collection of passwords). You only need to remember one really strong password/phrase to unlock all of them.
It needs to work in whatever context you need a password. Like
1. your desktop/laptop, where you need to remember logins for a variety of apps and services,
2. in your browser (for web apps that require authentication), and
3. on your mobile platforms (because most services you use via apps or browsers require authentication)
It needs to be cross platform
1. must support Windows, MacOS, and Linux OSs,
2. must support extensions for many browsers like Firefox, Chrome/Chromium, Safari, and others, and
3. must support mobile OSs like iOS and Android.
It needs to sync data in a timely manner among all the different contexts in which a given user needs it.

That's a lot of requirements. There're quite a few efforts that have had a crack at solving this.

The KeePassX community has been addressing this for ages and has created a comprehensive (if variable) ecosystem of apps which work across all of the required platforms, but only with a lot of work.

In the proprietary world, there're many options, with a few front runners like 1Password and LastPass. The former doesn't work on Linux, so it only gets a passing reference and no link :) (update 2019-05-31 - 1Password has added Linux support). The latter, which I used (grudgingly, mostly because I couldn't get KeePassX to work for me) for a few years, works across all the platforms relevant to me, but it was becoming progressively more invasive and annoying to use. Also, because it has a lot of users, and stores everything (albeit, encrypted) in a centralised cloud repository, it's a big target. Also, with its largely proprietary code, I wasn't happy trusting it.

Then I heard about BitWarden. They offered a commercial service (with a free tier) that I could quickly try... they supported all the OSs, mobile and desktop, and browsers that I use... and they release their entire codebase (server and clients) under open source licenses. I tried it, it worked for me, I was sold!

Update 2020-12-20: here's a nice explanation of why you'd want a password manager and even a comparison between widely used (proprietary) LastPass and (open source) BitWarden. People reading this might also be interested in learning how websites check your password... without storing a copy of your password! Thanks for providing your CC-BY-SA licensed works for us all Kev!

Then I decided I wanted to run my own BitWarden server, rather than use their commercial centralised cloud platform (because, as with LastPass, it's a tempting target). That's when I found out the server of BitWarden was written using Microsoft technologies, C# (yeah, it's mostly open source, but it's dirty to me due to its Microsoft legacy), and MS SQL Server, which is a nasty proprietary dependency (especially given how basic the database requirements for this sort of application are).

So I was devastated that I couldn't set up my own server without compromising my iron-clad anti-Microsoft position (I've managed to maintain it for the past 25 years)... until another Free and Open Source Software aficionado pointed me at Daniel Garcia's work! Daniel has implemented a full (unofficial) BitWarden work-alike using a fully FOSS stack: the Rust language, storing data in SQLite, and (quite thoughtfully) re-using other open source licensed components of the BitWarden system that don't have proprietary dependencies, including the website code and layout (which is part of the server). (he calls the server he's developed VaultWarden to distinguish it from the BitWarden code base. The front-end BitWarden apps talk to VaultWarden the same way!)

Daniel's server implementation also unlocks all the "premium" services that BitWarden offers through their hosted service, too... so that's a nice bonus.

Another open source developer, mpasil, has created a "fork" of Daniel's project from which he maintains an up-to-date Docker container on hub.docker.com. Thanks to both Daniel Garcia and mpasil's efforts, it turns out to be quite straightforward to set up your own Docker-based BitWarden-compatible service!

Creating your own BitWarden Service

Set up a Virtual Server

The first step is to get yourself an entry-level virtual server or compute instance somewhere. I generally use DigitalOcean (I have no affiliation with the company), but there are many other commodity hosting services (check out Vultr or Linode, for example) around the world which offer comparably (or better) spec'd servers for USD5.00/month, or USD60.00/year - I encourage you to do a bit of research. For that you get a Gigabyte (GB) of RAM, a processor, and 40GB of SSD (Static Storage Device = faster) storage. That's oodles of grunt for what this application requires.

I suggest you create an account for yourself (and I encourage you to use Two Factor Authentication, aka 2FA) and create an Ubuntu 18.04 (or the most recent LTS version - the next will be 20.04, in April 2020 :) ) in the zone nearest to you. You'll need to note the server's IP address (it'll be a series of 4 numbers, 0-254, separated by full stops, e.g. 103.99.72.244). With that, you can log into it via SSH.

Get your Domain lined up

You will want to have a domain to point at your server, so you don't have to remember the IP number. There're are thousands of domain "registrars" in the world who'll help you do that... You just need to "register" a name, and you pay yearly fee (usually between USD10-30 depending on the country and the "TLD" (Top Level Domain. There're national ones like .nz, .au, .uk, .tv, .sa, .za, etc., or international domains (mostly associated with the US) like .com, .org, .net, and a myriad of others. Countries decide on how much their domains wholesale for and registrars add a margin for the registration service).

Here in NZ, I use the services of Metaname (they're local to me in Christchurch, and I know them personally and trust their technical capabilities). If you're not sure who to use, ask your friends. Someone's bound to have recommendations (either positive or negative, in which case you'll know who to avoid).

If you want to use your domain for other things besides your BitWarden instance, I'd encourage you to use a subdomain, like (my usual choice) is "safe.domainname", namely the subdomain "safe" of "domainname".

Once you have selected and registered your domain, you can set up (usually through a web interface provided by the registrar) an "A Record" which associates your website's name to the IP address of your server. So you should just be able to enter your server's IP address, the domain name (or sub-domain) you want to use for your BitWarden service, and that's it. For a password safe, I tend to use the subdomain "safe", so, for example, safe.mydomain.nz or similar.

You might be asked to set a "Time-to-live" (which has to do with the length of time Domain Name Servers are asked to "cache" the association that the A Record specifies) in which case you can put in 3600 seconds or an hour depending on the time units your interface requests... but in most cases that'll be set to a default of an hour automatically.

You should be able to test that your A Record has been set correctly by SSHing to your domain name rather than the IP address. It should (after you accept the SSH warning that the server's name has changed) work the same way your original SSH login did.

Set up a Docker Server

Once I've first logged into it as the "root" (full admin) user, here's what I usually do:

I create an "unprivileged user", either with my name "dave" or sometimes an "ubuntu" user (some hosting providers create a default unprivileged user of "ubuntu" when you create an Ubuntu-based virtual machine. Some create a "debian" user for Debian-based VMs, etc.) via
adduser ubuntu
I install a few core applications: my preferred editor vim (nano is another easy option and comes pre-installed on Ubuntu), version control system, git, and a very handy configuration tracker, etckeeper:
apt-get update && apt-get install vim git etckeeper
I do some basic configuration of git (replace the [tokens] with the real values for you, minus the []):
git config --global user.email "[your email]" git config --global user.name "[your full name, e.g. Jane Doe]"
Initialise etckeeper - it will track configuration changes you make to your system which can be invaluable in replicating a server or working out what's changed if something breaks.
etckeeper init etckeeper commit -m "initial commit of BitWarden host"
Install Docker dependencies:
apt-get install apt-transport-https ca-certificates curl software-properties-common pwgen
Install secure key needed to add the docker.com package repository to your system
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
Confirm the key is valid
apt-key fingerprint 0EBFCD88
(you should see something like "uid [ unknown] Docker Release (CE deb) <docker@docker.com>" among the 4 lines)
Add the repository for your Ubuntu version (this will pick it automatically)
add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"
Update the package repository to include the packages from docker.com
apt-get update
Install the Community Edition of the Docker service
apt-get install docker-ce
Add your unprivileged user ("ubuntu" in this case - substitute the unprivileged user you created!) to a new "docker" group and add that user to other useful groups:
groupadd docker adduser ubuntu adduser ubuntu sudoers adduser ubuntu admin
adduser ubuntu docker
Create an SSH key for your unprivileged user and allow logins for that user from external connection:
sudo -Hu ubuntu ssh-keygen -t rsa cp /root/.ssh/authorized_keys /home/ubuntu/.ssh/ chown ubuntu:ubuntu /home/ubuntu/.ssh/ adduser ubuntu ssh
Install the Python packaging system, "pip" to allow you to install and maintain the Docker Compose framework for managing collections of Docker containers:
apt install python-pip pip install -U pip pip install docker-compose
Set a convenience variable for [your domain] here (note: it'll only be recognised for this session, i.e. until you log out):
DOMAIN=[your domain] USER=[unprivileged user, e.g. ubuntu]
Below, anytime you see $DOMAIN in a command, it'll be replaced by whatever you put in for [your domain] and similarly $USER...
Create directories to hold both the Docker Compose configurations and the persistent data you don't want to lose if you remove your Docker containers (namely your password database and configuration information):
mkdir -p /home/docker/$DOMAIN && mkdir -p /home/data/$DOMAIN chown -R ${USER}:${USER} /home/data /home/docker/
Install the NGINX (pronounced "Engine X") webserver which will act as a reverse proxy for the BitWarden service and terminate the encryption via HTTPS:
apt-get install nginx-full
Configure the server's firewill and make an exception for SSH and NGINX services
ufw allow OpenSSH ufw allow "Nginx Full" ufw enable
Check that its running via
ufw status
Create a directory for including files for NGINX
cd /etc/nginx
mkdir includes
Choose your text editor for editing files. Here're options for Vim or Nano - you can install and select others. Setting the EDIT shall variable allows you to copy and paste these commands regardless of which editor you prefer as it'll replace the value of $EDIT with the full path to your preferred editor.
EDIT=`which nano` or EDIT=`which vim`
To support encrypted data transfer between external devices and your server using HTTPS, you need a valid SSL certificate. Until recently, these were costly and hard to get. With Let's Encrypt, they've become a straightforward and essential part of any good (user-respecting) web site or service. To facilitate getting and periodically renewing your SSL certificate, you need to create the file letsencrypt.conf:
$EDIT includes/letsencrypt.conf
and enter the following content:
############################################################################# # Configuration file for Let's Encrypt ACME Challenge location # This file is already included in listen_xxx.conf files. # Do NOT include it separately! ############################################################################# # # This config enables to access /.well-known/acme-challenge/xxxxxxxxxxx # on all our sites (HTTP), including all subdomains. # This is required by ACME Challenge (webroot authentication). # You can check that this location is working by placing ping.txt here: # /var/www/letsencrypt/.well-known/acme-challenge/ping.txt # And pointing your browser to: # http://xxx.domain.tld/.well-known/acme-challenge/ping.txt # # Sources: # https://community.letsencrypt.org/t/howto-easy-cert-generation-and-renewal-with-nginx/3491 # # Rule for legitimate ACME Challenge requests location ^~ /.well-known/acme-challenge/ { default_type "text/plain"; # this can be any directory, but this name keeps it clear root /var/www/letsencrypt; } # Hide /acme-challenge subdirectory and return 404 on all requests. # It is somewhat more secure than letting Nginx return 403. # Ending slash is important! location = /.well-known/acme-challenge/ { return 404; }
Now you need to create the directory described in the letsencrypt.conf file:
mkdir /var/www/letsencrypt
Create "forward secrecy & Diffie Hellman ephemeral parameters" to make your server more secure... The result will be a secure signing key stored in /etc/ssl/certs/dhparam.pem (note, getting enough "entropy" to generate sufficient randomness to calculate this will take a few minutes!):
openssl dhparam -out /etc/ssl/certs/dhparam.pem 4096
and then you need to create the reverse proxy configuration file as follows:
cd ../sites-available

and fill it with this content, replacing all [tokens] with your relevant values:
# # HTTP does *soft* redirect to HTTPS # server { # add [IP-Address:]80 in the next line if you want to limit this to a single interface listen 0.0.0.0:80; server_name [your domain]; root /home/data/[your domain]; index index.php; # change the file name of these logs to include your server name # if hosting many services... access_log /var/log/nginx/[your domain]_access.log; error_log /var/log/nginx/[your domain]_error.log; include includes/letsencrypt.conf;

# redirect all HTTP traffic to HTTPS. location / { return 302 https://[your domain]$request_uri; } }
and make the configuration available to NGINX by linking the file from sites-available into sites-enabled (you can disable the site by removing the link and reloading NGINX)
ln -sf sites-available/bitwarden sites-enabled/bitwarden
Check to make sure NGINX is happy with the configuration
nginx -t
If you don't get any errors, you can restart NGINX
service nginx restart
and it should be configured properly to respond to requests at http://[your domain]/.well-known/acme-challenge/ which is required for creating a Let's Encrypt certificate.
$EDIT sites-available/bitwarden
So now we can create the certificate. You'll need to install the letscencrypt scripts:
apt-get install letsencrypt
You will be asked to enter some information about yourself, including an email address - this is necessary so that the letsencrypt service can email you if any of your certificates are not successfully updated (they need to be renewed every few weeks - normally this happens automatically!) so that you site and users aren't affected by an expired SSL certificate (a bad look!). Trust me, these folks are the good guys.
You create a certificate for [your domain] with the following command (with relevant substitutions):
letsencrypt certonly --webroot -w /var/www/letsencrypt -d $DOMAIN
If the process works, you should see a "Congratulations!" message.
Edit the nginx configuration file for the BitWarden service again
$EDIT sites-available/bitwarden
and add the following to the bottom of file (starting the line below the final "}") # # HTTPS # # This assumes you're using Let's Encrypt for your SSL certs (and why wouldn't # you!?)... https://letsencrypt.org server {     # add [IP-Address:]443 ssl in the next line if you want to limit this to a single interface     listen 0.0.0.0:443 ssl;     ssl on;     ssl_certificate /etc/letsencrypt/live/[your domain]/fullchain.pem;     ssl_certificate_key /etc/letsencrypt/live/[your domain]/privkey.pem;     ssl_protocols TLSv1 TLSv1.1 TLSv1.2;     # to create this, see https://raymii.org/s/tutorials/Strong_SSL_Security_On_nginx.html     ssl_dhparam /etc/ssl/certs/dhparam.pem;     keepalive_timeout 20s;
    server_name [your domain];     root /home/data/[your domain];     index index.php;
    # change the file name of these logs to include your server name     # if hosting many services...     access_log /var/log/nginx/[your domain]_access.log;     error_log /var/log/nginx/[your domain]_error.log;

    location /notifications/hub/negotiate {         proxy_pass http://127.0.0.1:8080;         proxy_set_header Upgrade $http_upgrade;         proxy_set_header Connection "upgrade";         proxy_set_header Host $http_host;         proxy_set_header X-Real-IP $remote_addr;         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;         proxy_set_header X-Forwarded-Host $server_name;         proxy_set_header X-Forwarded-Proto https;         proxy_connect_timeout 2400;         proxy_read_timeout 2400;         proxy_send_timeout 2400;     }
    location / {         proxy_pass http://127.0.0.1:8080;         proxy_set_header Upgrade $http_upgrade;         proxy_set_header Connection "upgrade";         proxy_set_header Host $http_host;         proxy_set_header X-Real-IP $remote_addr;         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;         proxy_set_header X-Forwarded-Host $server_name;         proxy_set_header X-Forwarded-Proto https;         proxy_connect_timeout 2400;         proxy_read_timeout 2400;         proxy_send_timeout 2400;     }
    location /notifications/hub {         proxy_pass http://127.0.0.1:3012;         proxy_set_header Upgrade $http_upgrade;         proxy_set_header Connection "upgrade";     }     #     # These "harden" your security     add_header 'Access-Control-Allow-Origin' "*"; }
You should now be able to run
nginx -t
again, and it you haven't got an accidental errors in the files, it should return no errors. You can restart nginx to make sure it picks up your SSL certificates...
service nginx restart

Now everything is read to set up your BitWarden Docker containers!

Setting up your BitWarden "rust" service

Before we start this part, you'll need a few bits of information. First, you'll need a 64 character random string to be your "admin token"... you can create that like this:
pwgen -y 64 1

copy the result (highlight the text and hit CTRL+SHIFT+C) and paste it somewhere so you can copy-and-paste it into the file below later.

Also, if you want your BitWarden server to be able to send out emails, like for password recovery, you'll need to have an "authenticating SMTP email account"... I would recommend setting one up specifically for this purpose. You can use a random gmail account or any other email account that lets you send mail by logging into an SMTP (Simple Mail Transfer Protocol) server, i.e. most mail servers. You'll need to know the SMTP [host name], the [port] (usually 465 or 587), the [login security] (usually "true" or "TLS"), and your authenticating [username] (possibly this is also the email address) and [password]. You'll also need a "[from email] like bitwarden@[your domain] or similar, which will be the sender of email from your server.

You're going to be setting up your configuration in the directory we created earlier, so run
cd /home/docker/$DOMAIN

and there
$EDIT docker-compose.yml

copy-and-pasting in the following, replacing the [tokens] appropriately:

version: "3" services: app: image: vaultwarden/server environment: - DOMAIN=https://[your domain] - WEBSOCKET_ENABLED=true - SIGNUPS_ALLOWED=false - LOG_FILE=/data/bitwarden.log - INVITATIONS_ALLOWED=true - ADMIN_TOKEN=[admin token] - SMTP_HOST=[host name] - SMTP_FROM=[from email] - SMTP_PORT=[port] - SMTP_SSL=[login security] - SMTP_USERNAME=[username] - SMTP_PASSWORD=[password] volumes: - /home/data/[your domain]/data/:/data/ ports: - "127.0.0.1:8080:80" - "127.0.0.1:3012:3012" restart: unless-stopped

Note that the indentation has to be exact in this file - Docker Compose will complain otherwise.

With the docker-compose file completed, you're ready to "pull" your package!

docker-compose pull

This will download the BitWarden Docker container from hub.docker.com. Then all you need to do is start it:

docker-compose up -d && docker-compose logs -f

the "up -d" option actually starts the container called "app" which is actually your BitWarden rust server in "daemon" mode, which means it'll keep running unless you tell it to stop. If that's successful, it automatically then shows you the logs of that container. You can exit at any time with CTRL-C which will put you back on the command prompt. If you do want the container to stop, just run

docker-compose stop

If your start up was successful, you should see a message like this (albeit your version number could be higher - 1.9.0 is the current version of the Rust implementation at the time of writing):

/--------------------------------------------------------------------\ | Starting Bitwarden_RS | | Version 1.9.0 | |--------------------------------------------------------------------| | This is an *unofficial* Bitwarden implementation, DO NOT use the | | official channels to report bugs/features, regardless of client. | | Report URL: https://github.com/dani-garcia/bitwarden_rs/issues/new | \--------------------------------------------------------------------/

You should now be able to point your browser at http://[your domain] which, in turn, should automatically redirect you to https://[your domain] and you should see the BitWarden web front end similar to that shown in the attached screen shot!

First Login!

To do your initial login by going to https://[your domain]/admin/ and you'll be asked to provide your "admin token" (a random string you created earlier for your docker-compose.yml file, where you should be able to find it) to create a first user with administration privileges. That will allow you to create your initial personal user and other useful stuff.

For additional info on setting up these services - and new options as Daniel and his co-developers add them in - consult the repository pages and issues and for Docker-specific questions, look at mpasil's pages.

Sending Emails

It'll be worth testing if your email services work, like by requesting a password hint! You should be able to see what the server's doing via the

docker-compose logs -f

Tips

I recommend not including your login credentials to your BitWarden instance in your BitWarden database ;) that's the one thing you need to remember. If you need to write it down somewhere, then do so (but make sure you don't include all the info needed to log in on the same piece of paper, that's just asking for trouble).

Also, you can easily configure all the BitWarden clients - browser plugins, mobile apps, or the desktop app - to use your server rather than BitWarden's default hosted service. Just click the "gear" settings icon on each app's interface, and set the "Self-Hosted Environment" Server URL to be your server, i.e. https://[your domain]

Backing it all up

I've created a SQLite backup script (which maintains automatic versioned hourly, daily, weekly, monthly, and yearly database dumps, the content in which is encrypted) described in more detail in another post...

Two Factor Authentication

This configuration should allow you to simply turn on Two Factor Authentication for any given BitWarden user.

Keeping it up-to-date

One of the best things about this Docker configuration is that it's very straightforward to upgrade your installation to Daniel's (via mpasil's Docker work) latest server version. Just log into the server as your unprivileged user,

cd /home/docker/[your domain] docker-compose pull docker-compose up -d && docker-compose logs -f

The whole process shouldn't take much more than a minute, with a few seconds downtime only as your new Docker BitWarden container is being created...

Hope this helps a few folks! If you find any of the above doesn't work, please let me know in the comments. I'll do my best to make sure this how-to is accurate and up-to-date, and I'll do my best to assist people if they're having trouble.

Have (secure and private) fun!

Blog comments

Excellent blog

cocoonkid (not verified) Wed 09/10/2019 - 00:19

Really appreciate the document.

Would love to see these too:

To do your initial login, I believe (I'll test this and update this howto!) you'll be asked to provide your "admin token" to create a first user with administration privileges.

I'll add information on my SQLite backup scripts (which maintain automatic versioned hourly, daily, weekly, monthly, and yearly database dumps, the content in which is encrypted)...

Thanks!

Fair call! Leave it with me…

dave Tue 22/10/2019 - 21:47

Fair call! Leave it with me...

Backup script update...

dave Fri 14/02/2020 - 11:07

I've published a new post which describes the SQLite backup script and points to the publicly visible git repo, linked in the article now. I've also updated the question of the admin code...

Thank You!

SS (not verified) Tue 08/09/2020 - 07:06

This is the best tutorial I've come across for getting BitWarden up and running on a Pi.

It worked the first time through. There a couple nice things that aren't obvious to the newbie that I tracked down after everything was up and running. Setting a docker restart policy for the BW container that ensures that the container comes up after a power interruption was a pleasant surprise.

One thing that isn't clear to the absolute newbie is that it's probably better to set up on a subdomain rather than a domain if you want to use NGINX for serving other things. I wasn't thinking about that when I did the initial setup, and that's leading to rework... Ideally, I'd like to have BitWarden sitting on a nonobvious subdomain, and serve up other things on the obvious ones, like the bare domain or www.example.xyz.

Again, thanks for a great post.

Use a subdomain!

dave Fri 11/09/2020 - 14:46

Thanks for the suggestion, SS - I've added a note regarding using subdomains! And thanks for the positive feedback - hope your BitWarden is providing you with what you need!

Login

Daniel Lamb (not verified) Fri 11/09/2020 - 04:20

Hello,
sorry might be being thick here but trying to login after follwing the setup guide and dont know what I should put in the username, I am using the token generated and in the yaml file.

Daniel

First login...

dave Fri 11/09/2020 - 14:44

Hi Daniel,

Sorry that I wasn't clear - to be honest, I'm not sure what the latest versions use for the first login, but from memory, the very first visitor to a new BitWarden site sees a special login form asking them to enter their Admin Token which then allows them to set up their normal user login details (an email address and passphrase)... If you don't see something like that, then I would expect you could remove the Sqlite db file forcing a reinitialisation of the system.

Can you update this for…

Terry (not verified) Sun 13/12/2020 - 04:54

Can you update this for Ubuntu 20.xx and Python3? I've tried to deploy, and failed.

Hi Terry, If you want to…

dave Sun 13/12/2020 - 10:14

Hi Terry,

If you want to use Python3 for Docker Compose, it's easy enough (although it's confusing depending on which distro you're running and whether Python3 is default or has to be designated as python3 ... assuming you've got Python3 already installed, you can install pip via sudo apt-get install python3-pip and then you might need to use "pip3" installed by the package manager to install "pip"... e.g. pip3 install pip via the python package (which is independent of your package manager). You should then be able to install and update docker-compose via pip, e.g. sudo pip install docker-compose or, to upgrade, sudo pip install -U docker-compose. And if you want to upgrade pip itself, if you've previously installed pip via pip3, you can use sudo pip install -U pip. It's tricky when you have distro-managed installs and python-installed stuff, but hopefully you can get to the bottom of it - might require a bit of fiddling depending precisely which version/distro of Linux you're using.

Turns out it wasn't anything…

Terry (not verified) Tue 15/12/2020 - 01:20

Turns out it wasn't anything to do with python3 or pip, I had previously managed to have them installed & working properly.
Looks like it was something with the docker images host on the weekend when I was doing this as the docker pull command always errored out. I just did it now (Monday morning) and the pull worked, and docker up was successful.
Thanks for the great tutorial!

I'm pleased to hear it all…

dave Tue 15/12/2020 - 08:00

I'm pleased to hear it all worked out for you! Enjoy!

we've set up our own locally…

Jeff (not verified) Thu 18/03/2021 - 04:21

we've set up our own locally hosted bitwarden, "oursite.bitwarden.com" but want to either block or redirect our users from being able to inadvertently go to the main web-based bitwarden.com can you provide suggestions?

Interesting question... I'm…

dave Thu 18/03/2021 - 07:33

Interesting question... I'm afraid I can't think of an easy way to achieve that... :/ I'd say the best thing is to create BW users for your users and install and configure their clients for them. That way, they won't be able to lot into the bitwarden.com service with the same credentials....

Anybody who has the URL can…

Philippe (not verified) Tue 24/08/2021 - 14:09

Anybody who has the URL can open an Bitwarden account on a self hosted installation. How do I control who can create a new account?

If you log in as an admin …

dave Tue 24/08/2021 - 14:12

If you log in as an admin (use the /admin URL - the password is in your docker-compose.yml file) you can disable random sign-ups (e.g. and make it invite-only). You can also disable any existing accounts you don't want there.

BitWarden

Setting up your own BitWarden password manager and VaultWarden sync server

Blog tags

Creating your own BitWarden Service

Set up a Virtual Server

Get your Domain lined up

Set up a Docker Server

Setting up your BitWarden "rust" service

First Login!

Sending Emails

Tips

Backing it all up

Two Factor Authentication

Keeping it up-to-date

Blog comments

Add new comment