MirrorHub/bitwarden_rs
0
0
Fork 0
mirror of https://github.com/dani-garcia/vaultwarden synced 2024-05-18 04:43:49 +02:00
Code Issues Releases Wiki Activity

Project renaming

Daniel García 2021-04-27 23:41:57 +02:00
parent 8aceb9d8f8
commit 3bbd0b6de0
48 changed files with 349 additions and 349 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

12
Backing-up-your-vault.md

@ -1,12 +1,12 @@
## Overview
bitwarden_rs data should be backed up regularly, preferably via an automated process (e.g., cron job). Ideally, at least one copy should be stored remotely (e.g., cloud storage or a different computer). Avoid relying on filesystem or VM snapshots as a backup method, as these are more complex operations where more things can go wrong, and recovery in such cases can be difficult or impossible for the typical user. Adding an extra layer of encryption on your backups would generally be a good idea (especially if your backup also includes config data like your [[admin token|Enabling-admin-page]]), but you might choose to skip this step if you're confident that your master password (and those of your other users, if any) is strong.
vaultwarden data should be backed up regularly, preferably via an automated process (e.g., cron job). Ideally, at least one copy should be stored remotely (e.g., cloud storage or a different computer). Avoid relying on filesystem or VM snapshots as a backup method, as these are more complex operations where more things can go wrong, and recovery in such cases can be difficult or impossible for the typical user. Adding an extra layer of encryption on your backups would generally be a good idea (especially if your backup also includes config data like your [[admin token|Enabling-admin-page]]), but you might choose to skip this step if you're confident that your master password (and those of your other users, if any) is strong.
## Backing up data
By default, bitwarden_rs stores all of its data under a directory called `data` (in the same directory as the `bitwarden_rs` executable). This location can be changed by setting the [[DATA_FOLDER|Changing-persistent-data-location]] environment variable. If you run bitwarden_rs with SQLite (this is the most common setup), then the SQL database is just a file in the data folder. If you run with MySQL or PostgreSQL, you will have to dump that data separately -- this is beyond the scope of this article, but a web search will turn up many other tutorials that cover this topic.
By default, vaultwarden stores all of its data under a directory called `data` (in the same directory as the `vaultwarden` executable). This location can be changed by setting the [[DATA_FOLDER|Changing-persistent-data-location]] environment variable. If you run vaultwarden with SQLite (this is the most common setup), then the SQL database is just a file in the data folder. If you run with MySQL or PostgreSQL, you will have to dump that data separately -- this is beyond the scope of this article, but a web search will turn up many other tutorials that cover this topic.
When running with the default SQLite backend, the bitwarden_rs `data` directory has this structure:
When running with the default SQLite backend, the vaultwarden `data` directory has this structure:
```
data
@ -38,7 +38,7 @@ Each set of files is discussed in more detail next.
_**Backup required.**_
The SQLite database file (`db.sqlite3`) stores almost all important bitwarden_rs data/state (database entries, user/org/device metadata, etc.), with the main exception being attachments, which are stored as separate files on the filesystem.
The SQLite database file (`db.sqlite3`) stores almost all important vaultwarden data/state (database entries, user/org/device metadata, etc.), with the main exception being attachments, which are stored as separate files on the filesystem.
You should generally use the `.backup` command in the SQLite CLI (`sqlite3`) to back up the database file. This command uses the [Online Backup API](https://www.sqlite.org/backup.html), which SQLite documents as the [best way](https://www.sqlite.org/howtocorrupt.html#_backup_or_restore_while_a_transaction_is_active) to back up a database file that may be in active use. If you can ensure the database will not be in use when a backup runs, you can also use other methods such as the `.dump` command, or simply copying all the SQLite database files (including the `-shm` and `-wal` files, if present).
@ -76,7 +76,7 @@ This directory won't be present if no Send attachments have ever been created.
_**Backup recommended.**_
If you use the admin page to configure your bitwarden_rs instance and don't have your configuration backed up some other way, then you probably want to back up this file so you don't have to figure out your preferred configuration all over again.
If you use the admin page to configure your vaultwarden instance and don't have your configuration backed up some other way, then you probably want to back up this file so you don't have to figure out your preferred configuration all over again.
Keep in mind that this file does contain some data in plaintext that could be considered sensitive (admin token, SMTP credentials, etc.), so make sure to encrypt this data if you're concerned that someone else might be able to access to it (e.g., when uploaded to cloud storage).
@ -94,7 +94,7 @@ The icon cache stores [website icons](https://bitwarden.com/help/article/website
## Restoring backup data
Make sure bitwarden_rs is stopped, and then simply replace each file or directory in the `data` dir with its backed up version.
Make sure vaultwarden is stopped, and then simply replace each file or directory in the `data` dir with its backed up version.
It's a good idea to run through the process of restoring from backup periodically, just to verify that your backups are working properly. When doing this, make sure to move or keep a copy of your original data in case your backups do not in fact work properly.

24
Building-binary.md

@ -1,4 +1,4 @@
This page is primarily for those interested in bitwarden_rs development, or who have a specific reason for wanting to build their own binary.
This page is primarily for those interested in vaultwarden development, or who have a specific reason for wanting to build their own binary.
Typical users should either [[deploy via Docker|Which-container-image-to-use]], [[extract the pre-built binaries|Pre-built binaries]] from the Alpine-based Docker images, or look for a [[third-party package|Third-party-packages]].
@ -18,7 +18,7 @@ Typical users should either [[deploy via Docker|Which-container-image-to-use]],
```sh
# Compile with all backends and run
cargo run --features sqlite,mysql,postgresql --release
# or just compile with all backends (binary located in target/release/bitwarden_rs)
# or just compile with all backends (binary located in target/release/vaultwarden)
cargo build --features sqlite,mysql,postgresql --release
```
@ -26,21 +26,21 @@ cargo build --features sqlite,mysql,postgresql --release
```sh
# Compile with sqlite backend and run
cargo run --features sqlite --release
# or just compile with sqlite (binary located in target/release/bitwarden_rs)
# or just compile with sqlite (binary located in target/release/vaultwarden)
cargo build --features sqlite --release
```
### MySQL backend
```sh
# Compile with mysql backend and run
cargo run --features mysql --release
# or just compile with mysql (binary located in target/release/bitwarden_rs)
# or just compile with mysql (binary located in target/release/vaultwarden)
cargo build --features mysql --release
```
### PostgreSQL backend
```sh
# Compile with postgresql backend and run
cargo run --features postgresql --release
# or just compile with postgresql (binary located in target/release/bitwarden_rs)
# or just compile with postgresql (binary located in target/release/vaultwarden)
cargo build --features postgresql --release
```
@ -53,7 +53,7 @@ A compiled version of the web vault can be downloaded from [dani-garcia/bw_web_b
If you prefer to compile it manually, follow these steps:
*Note: building the Vault needs ~1.5GB of RAM. On systems like a RaspberryPI with 1GB or less, please [enable swapping](https://www.tecmint.com/create-a-linux-swap-file/) or build it on a more powerful machine and copy the directory from there. This much memory is only needed for building it, running bitwarden_rs with vault needs only about 10MB of RAM.*
*Note: building the Vault needs ~1.5GB of RAM. On systems like a RaspberryPI with 1GB or less, please [enable swapping](https://www.tecmint.com/create-a-linux-swap-file/) or build it on a more powerful machine and copy the directory from there. This much memory is only needed for building it, running vaultwarden with vault needs only about 10MB of RAM.*
- Clone the git repository at [bitwarden/web](https://github.com/bitwarden/web) and checkout the latest release tag (e.g. v2.1.1):
```sh
@ -85,8 +85,8 @@ npm run dist
*Note: You might be asked to run ```npm audit fix``` to fix vulnerability. This will automatically try to upgrade packages to newer version, which might not be compatible and break web-vault functionality``` Use it at your own risk, if you know what you are doing. We do use this on our own releases btw!*
Finally copy the contents of the `build` folder into the destination folder:
- If you run with `cargo run --release`, it's `bitwarden_rs/web-vault`.
- If you run the compiled binary directly, it's next to the binary, in `bitwarden_rs/target/release/web-vault`.
- If you run with `cargo run --release`, it's `vaultwarden/web-vault`.
- If you run the compiled binary directly, it's next to the binary, in `vaultwarden/target/release/web-vault`.
## Configuration
The available configuration options are documented in the default `.env` file, and they can be modified by uncommenting the desired options in that file or by setting their respective environment variables. See the Configuration section of this wiki for the main configuration options available.
@ -94,8 +94,8 @@ The available configuration options are documented in the default `.env` file, a
Note: the environment variables override the values set in the `.env` file.
## More information for deployment
- [Configuring your reverse proxy](https://github.com/dani-garcia/bitwarden_rs/wiki/Proxy-examples)
- [Setting up Autostart via systemd](https://github.com/dani-garcia/bitwarden_rs/wiki/Setup-as-a-systemd-service)
- [Configuring your reverse proxy](https://github.com/dani-garcia/vaultwarden/wiki/Proxy-examples)
- [Setting up Autostart via systemd](https://github.com/dani-garcia/vaultwarden/wiki/Setup-as-a-systemd-service)
## How to recreate database schemas for the sqlite backend (for developers)
Install diesel-cli with cargo:
@ -121,7 +121,7 @@ diesel migration redo
```
## How to migrate from SQLite backend to MySQL backend (for developers)
Refer to [using the MySQL backend](https://github.com/dani-garcia/bitwarden_rs/wiki/Using-the-MySQL-Backend) if you want to migrate from SQLite.
Refer to [using the MySQL backend](https://github.com/dani-garcia/vaultwarden/wiki/Using-the-MySQL-Backend) if you want to migrate from SQLite.
## How to migrate from SQLite backend to PostgreSQL backend (for developers)
Refer to [using the PostgreSQL backend](https://github.com/dani-garcia/bitwarden_rs/wiki/Using-the-PostgreSQL-Backend) if you want to migrate from SQLite.
Refer to [using the PostgreSQL backend](https://github.com/dani-garcia/vaultwarden/wiki/Using-the-PostgreSQL-Backend) if you want to migrate from SQLite.

12
Building-your-own-docker-image.md

@ -2,27 +2,27 @@ Clone the repository, then from the root of the repository run to build with def
```sh
# Build the docker image:
docker build -t bitwarden_rs .
docker build -t vaultwarden .
```
To build with MySQL backend run:
```sh
# Build the docker image:
docker build -t bitwarden_rs --build-arg DB=mysql .
docker build -t vaultwarden --build-arg DB=mysql .
```
To build with Postgresql backend run:
```sh
# Build the docker image:
docker build -t bitwarden_rs --build-arg DB=postgresql .
docker build -t vaultwarden --build-arg DB=postgresql .
```
in docker-compose.yml it looks like
```...
bitwarden:
# image: bitwardenrs/server-postgresql:latest
image: bitwarden_rs
# image: vaultwarden/server-postgresql:latest
image: vaultwarden
build:
context: bitwarden_rs
context: vaultwarden
args:
DB: postgresql
```

4
Caddy-2.x-with-Cloudflare-DNS.md

@ -44,7 +44,7 @@ https://[YOUR-DOMAIN]:443 {
# Proxy the Root directory to Rocket
reverse_proxy bitwarden:80 {
# Send the true remote IP to Rocket, so that bitwarden_rs can put this in the
# Send the true remote IP to Rocket, so that vaultwarden can put this in the
# log, so that fail2ban can ban the correct IP.
header_up X-Real-IP {remote_host}
}
@ -58,7 +58,7 @@ version: '3'
services:
bitwarden:
image: bitwardenrs/server
image: vaultwarden/server
restart: always
volumes:
- $PWD/bw-data:/data

8
Changing-persistent-data-location.md

@ -7,7 +7,7 @@ docker run -d --name bitwarden \
-e DATA_FOLDER=/persistent \
-v /bw-data/:/persistent/ \
-p 80:80 \
bitwardenrs/server:latest
vaultwarden/server:latest
```
Notice, that you need to adapt your volume mount accordingly.
@ -22,7 +22,7 @@ docker run -d --name bitwarden \
-v /bw-data/:/data/ \
-v /bw-database/:/database/ \
-p 80:80 \
bitwardenrs/server:latest
vaultwarden/server:latest
```
Note, that you need to remember to mount the volume for both database and other persistent data if they are different.
@ -37,7 +37,7 @@ docker run -d --name bitwarden \
-v /bw-data/:/data/ \
-v /bw-attachments/:/attachments/ \
-p 80:80 \
bitwardenrs/server:latest
vaultwarden/server:latest
```
Note, that you need to remember to mount the volume for both attachments and other persistent data if they are different.
@ -52,7 +52,7 @@ docker run -d --name bitwarden \
-v /bw-data/:/data/ \
-v /icon_cache/ \
-p 80:80 \
bitwardenrs/server:latest
vaultwarden/server:latest
```
Note, that in the above example we don't mount the volume locally, which means it won't be persisted during the upgrade unless you use intermediate data container using `--volumes-from`. This will impact performance as bitwarden will have to re-download the icons on restart, but might save you from having stale icons in cache as they are not automatically cleaned.

2
Changing-the-API-request-size-limit.md

@ -7,5 +7,5 @@ docker run -d --name bitwarden \
-e ROCKET_LIMITS={json=10485760} \
-v /bw-data/:/data/ \
-p 80:80 \
bitwardenrs/server:latest
vaultwarden/server:latest
```

4
Changing-the-number-of-workers.md

@ -1,4 +1,4 @@
When you run bitwarden_rs, it spawns `2 * <number of cpu cores>` workers to handle requests. On some systems this might lead to low number of workers and hence slow performance, so the default in the docker image is changed to spawn 10 threads. You can override this setting to increase or decrease the number of workers by setting the `ROCKET_WORKERS` variable.
When you run vaultwarden, it spawns `2 * <number of cpu cores>` workers to handle requests. On some systems this might lead to low number of workers and hence slow performance, so the default in the docker image is changed to spawn 10 threads. You can override this setting to increase or decrease the number of workers by setting the `ROCKET_WORKERS` variable.
In the example below, we're starting with 20 workers:
@ -7,5 +7,5 @@ docker run -d --name bitwarden \
-e ROCKET_WORKERS=20 \
-v /bw-data/:/data/ \
-p 80:80 \
bitwardenrs/server:latest
vaultwarden/server:latest
```

16
Configuration-overview.md

@ -1,34 +1,34 @@
## Configuration methods
In bitwarden_rs, you can perform configuration either via environment variables or an [[admin page|Enabling-admin-page]] (which writes settings to a `config.json` file under your data directory). It's important to note that each setting in `config.json` overrides the corresponding environment variable setting (if it exists). For example, if you set the environment variable `DOMAIN=https://bitwarden.example.com`, but your `config.json` includes `"domain": "https://bw.example.com"`, then bitwarden_rs will generate various links based on what's in the config file (`https://bw.example.com`).
In vaultwarden, you can perform configuration either via environment variables or an [[admin page|Enabling-admin-page]] (which writes settings to a `config.json` file under your data directory). It's important to note that each setting in `config.json` overrides the corresponding environment variable setting (if it exists). For example, if you set the environment variable `DOMAIN=https://bitwarden.example.com`, but your `config.json` includes `"domain": "https://bw.example.com"`, then vaultwarden will generate various links based on what's in the config file (`https://bw.example.com`).
A common source of confusion is enabling the admin page (which creates the `config.json` file), changing some settings via the admin page (which sets the corresponding values in `config.json`), then later trying to change those settings via environment variable (which doesn't work because `config.json` overrides env vars). To avoid this confusion, it's highly recommended to stick to one configuration method or the other; that is, configure entirely via environment variables, or entirely via `config.json` (whether using the admin page or editing `config.json` directly).
Note that config settings under the `Read-Only Config` section of the admin page can only be set via environment variables, so you must restart bitwarden_rs to make changes to them. If you keep these environment variables in a file named `.env`, you can load them as follows:
Note that config settings under the `Read-Only Config` section of the admin page can only be set via environment variables, so you must restart vaultwarden to make changes to them. If you keep these environment variables in a file named `.env`, you can load them as follows:
* With standalone bitwarden_rs, by putting `.env` in the current working directory. bitwarden_rs will attempt to load this file on startup.
* With Docker, by using `docker run --env-file <env-file> ...` (to have Docker load the env file) or `docker run -v /path/to/.env:/.env` (to have bitwarden_rs load the `.env` file from inside the container).
* With standalone vaultwarden, by putting `.env` in the current working directory. vaultwarden will attempt to load this file on startup.
* With Docker, by using `docker run --env-file <env-file> ...` (to have Docker load the env file) or `docker run -v /path/to/.env:/.env` (to have vaultwarden load the `.env` file from inside the container).
* With Docker Compose, by using the [`env_file`](https://docs.docker.com/compose/environment-variables/#the-env_file-configuration-option) directive.
## Configuration options
You can find the list of environment variables you can set at
https://github.com/dani-garcia/bitwarden_rs/blob/master/.env.template
https://github.com/dani-garcia/vaultwarden/blob/master/.env.template
If you enable the [[admin page|Enabling-admin-page]], that will also show the full list of config options.
In case there are any errors or omissions, the source of truth is
https://github.com/dani-garcia/bitwarden_rs/blob/master/src/config.rs (search for `make_config! {`)
https://github.com/dani-garcia/vaultwarden/blob/master/src/config.rs (search for `make_config! {`)
Or you can use this direct link if your (Chromium-based) browser supports text fragments:
https://github.com/dani-garcia/bitwarden_rs/blob/master/src/config.rs#LC290:~:text=make_config!%20%7B,-folders
https://github.com/dani-garcia/vaultwarden/blob/master/src/config.rs#LC290:~:text=make_config!%20%7B,-folders
## Setting the domain URL
Make sure to set the `DOMAIN` environment variable (or `domain` in the config file) to the URL you use to access your bitwarden_rs instance. If you don't, it's likely that various functionality will break mysteriously. Some examples:
Make sure to set the `DOMAIN` environment variable (or `domain` in the config file) to the URL you use to access your vaultwarden instance. If you don't, it's likely that various functionality will break mysteriously. Some examples:
* `https://bitwarden.example.com`
* `https://bitwarden.example.com:8443` (non-default port)

14
Deployment-examples.md

@ -10,23 +10,23 @@ This page is an index of standalone deployment examples. If adding a new example
* https://github.com/icicimov/kubernetes-bitwarden_rs
Sets up a fully functional and secure `bitwarden_rs` application in Kubernetes behind [nginx-ingress-controller](https://github.com/kubernetes/ingress-nginx) and AWS [ELBv1](https://aws.amazon.com/elasticloadbalancing/features/#Details_for_Elastic_Load_Balancing_Products). It provides a little bit more than just simple deployment but you can use all or just part of the manifests depending on your needs and setup.
Sets up a fully functional and secure `vaultwarden` application in Kubernetes behind [nginx-ingress-controller](https://github.com/kubernetes/ingress-nginx) and AWS [ELBv1](https://aws.amazon.com/elasticloadbalancing/features/#Details_for_Elastic_Load_Balancing_Products). It provides a little bit more than just simple deployment but you can use all or just part of the manifests depending on your needs and setup.
* https://github.com/Skeen/helm-bitwarden_rs
Sets up a fully functional and secure `bitwarden_rs` application in Kubernetes behind an nginx controller of your choice. It works well and is tested with the [microk8s](https://microk8s.io/) setup. There is support for generating SSL certificates via [cert-manager](https://github.com/jetstack/cert-manager) too.
Sets up a fully functional and secure `vaultwarden` application in Kubernetes behind an nginx controller of your choice. It works well and is tested with the [microk8s](https://microk8s.io/) setup. There is support for generating SSL certificates via [cert-manager](https://github.com/jetstack/cert-manager) too.
## Raspberry Pi
* https://github.com/martient/bitwardenrs-ansible
Ansible deployment for bitwarden_rs on raspberry pi
Ansible deployment for vaultwarden on raspberry pi
## Shared hosting
* https://github.com/jjlin/bitwardenrs-shared-hosting
Sample config for running `bitwarden_rs` on [DreamHost](https://www.dreamhost.com/), but should be readily adaptable to many other shared hosting services.
Sample config for running `vaultwarden` on [DreamHost](https://www.dreamhost.com/), but should be readily adaptable to many other shared hosting services.
* https://lab.uberspace.de/guide_bitwarden.html
@ -34,8 +34,8 @@ This page is an index of standalone deployment examples. If adding a new example
## NixOS (by tklitschi)
There's a example bitwarden config for NixOS. It's not very complex, you have the backend option, for the type of Database you wanna use, the Backupdir for a dedicated Backup systemdserive, the option to enable it and the config Option. For the Config Option you simply pass the .env Variables [from the .env template](https://github.com/dani-garcia/bitwarden_rs/blob/1.13.1/.env.template) in nix syntax.
See [Proxy Examples](https://github.com/dani-garcia/bitwarden_rs/wiki/Proxy-examples) for a nixos-nginx example config.
There's a example bitwarden config for NixOS. It's not very complex, you have the backend option, for the type of Database you wanna use, the Backupdir for a dedicated Backup systemdserive, the option to enable it and the config Option. For the Config Option you simply pass the .env Variables [from the .env template](https://github.com/dani-garcia/vaultwarden/blob/1.13.1/.env.template) in nix syntax.
See [Proxy Examples](https://github.com/dani-garcia/vaultwarden/wiki/Proxy-examples) for a nixos-nginx example config.
<details>
<summary>Example Config</summary><br/>
@ -79,6 +79,6 @@ See [Proxy Examples](https://github.com/dani-garcia/bitwarden_rs/wiki/Proxy-exam
}
```
If you have any Questions about this part, feel Free to contact me. I on @litschi:litschi.xyz on matrix an litschi on IRC (hackint and freenode) or simply ask in the bitwarden_rs matrix.org chanel.
If you have any Questions about this part, feel Free to contact me. I on @litschi:litschi.xyz on matrix an litschi on IRC (hackint and freenode) or simply ask in the vaultwarden matrix.org chanel.
</details>

2
Differences-from-the-upstream-API-implementation.md

@ -12,6 +12,6 @@ Invited users that aren't registered yet will show up in the Organization admin
## Running on unencrypted connection
It is strongly recommended to run bitwarden_rs service over HTTPS. However the server itself while [[supporting it|enabling-https]] does not strictly require such setup. This makes it a bit easier to spin up the service in cases where you can generally trust the connection (internal and secure network, access over VPN,..) or when you want to put the service behind HTTP proxy, that will do the encryption on the proxy end.
It is strongly recommended to run vaultwarden service over HTTPS. However the server itself while [[supporting it|enabling-https]] does not strictly require such setup. This makes it a bit easier to spin up the service in cases where you can generally trust the connection (internal and secure network, access over VPN,..) or when you want to put the service behind HTTP proxy, that will do the encryption on the proxy end.
Running over HTTP is still reasonably secure provided you use really strong master password and that you avoid using web Vault over connection that is vulnerable to MITM attacks where attacker could inject javascript into your interface. However some forms of 2FA might not work in this setup and [Vault doesn't work in this configuration in Chrome](https://github.com/bitwarden/web/issues/254).

2
Disable-admin-token.md

@ -7,5 +7,5 @@ docker run -d --name bitwarden \
-e DISABLE_ADMIN_TOKEN=true \
-v /bw-data/:/data/ \
-p 80:80 \
bitwardenrs/server:latest
vaultwarden/server:latest
```

2
Disable-invitations.md

@ -6,5 +6,5 @@ docker run -d --name bitwarden \
-e INVITATIONS_ALLOWED=false \
-v /bw-data/:/data/ \
-p 80:80 \
bitwardenrs/server:latest
vaultwarden/server:latest
```

4
Disable-registration-of-new-users.md

@ -5,7 +5,7 @@ docker run -d --name bitwarden \
-e SIGNUPS_ALLOWED=false \
-v /bw-data/:/data/ \
-p 80:80 \
bitwardenrs/server:latest
vaultwarden/server:latest
```
Note that when `SIGNUPS_ALLOWED=false`, the `Create Account` button will still be shown in the web vault UI, but actually attempting to create an account will result in an error message. Upstream Bitwarden isn't designed to allow disabling signups, so this can't be worked around easily.
@ -27,4 +27,4 @@ You may also want to set `SIGNUPS_VERIFY=true`, which would require email verifi
## Invitations via the admin page
The bitwarden_rs admin can invite anyone via the [[admin page|Enabling-admin-page]], regardless of any of the restrictions above.
The vaultwarden admin can invite anyone via the [[admin page|Enabling-admin-page]], regardless of any of the restrictions above.

8
Disabling-or-overriding-the-Vault-interface-hosting.md

@ -1,11 +1,11 @@
As a convenience bitwarden_rs image will also host static files for Vault web interface. You can disable this static file hosting completely by setting the WEB_VAULT_ENABLED variable.
As a convenience vaultwarden image will also host static files for Vault web interface. You can disable this static file hosting completely by setting the WEB_VAULT_ENABLED variable.
```sh
docker run -d --name bitwarden \
-e WEB_VAULT_ENABLED=false \
-v /bw-data/:/data/ \
-p 80:80 \
bitwardenrs/server:latest
vaultwarden/server:latest
```
Alternatively you can override the Vault files and provide your own static files to host. You can do that by mounting a path with your files over the `/web-vault` directory in the container. Just make sure the directory contains at least `index.html` file.
@ -14,7 +14,7 @@ docker run -d --name bitwarden \
-v /path/to/static/files_directory:/web-vault \
-v /bw-data/:/data/ \
-p 80:80 \
bitwardenrs/server:latest
vaultwarden/server:latest
```
Note that you can also change the path where bitwarden_rs looks for static files by providing the `WEB_VAULT_FOLDER` environment variable with the path.
Note that you can also change the path where vaultwarden looks for static files by providing the `WEB_VAULT_FOLDER` environment variable with the path.

26
Enabling-HTTPS.md

@ -1,9 +1,9 @@
For proper operation of bitwarden_rs, enabling [HTTPS](https://en.wikipedia.org/wiki/HTTPS) is pretty much required nowadays, since the Bitwarden web vault uses [web crypto APIs](https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto) that most browsers only make available in HTTPS contexts.
For proper operation of vaultwarden, enabling [HTTPS](https://en.wikipedia.org/wiki/HTTPS) is pretty much required nowadays, since the Bitwarden web vault uses [web crypto APIs](https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto) that most browsers only make available in HTTPS contexts.
There are a few ways you can enable HTTPS:
* (Recommended) Put bitwarden_rs behind a [reverse proxy](https://en.wikipedia.org/wiki/Reverse_proxy) that handles HTTPS connections on behalf of bitwarden_rs.
* (Not recommended) Enable the HTTPS functionality built into bitwarden_rs (via the [Rocket](https://rocket.rs/) web framework). Rocket's HTTPS implementation is relatively immature and limited. This method also does not support [[WebSocket notifications|Enabling-WebSocket-notifications]].
* (Recommended) Put vaultwarden behind a [reverse proxy](https://en.wikipedia.org/wiki/Reverse_proxy) that handles HTTPS connections on behalf of vaultwarden.
* (Not recommended) Enable the HTTPS functionality built into vaultwarden (via the [Rocket](https://rocket.rs/) web framework). Rocket's HTTPS implementation is relatively immature and limited. This method also does not support [[WebSocket notifications|Enabling-WebSocket-notifications]].
Refer to the [Enabling HTTPS](#enabling-https) section for more details on these options.
@ -25,7 +25,7 @@ There are quite a few reverse proxies in common use; some example configurations
:warning: This method is not recommended.
To enable HTTPS in `bitwarden_rs` itself, set the `ROCKET_TLS` environment variable, which has the following format:
To enable HTTPS in `vaultwarden` itself, set the `ROCKET_TLS` environment variable, which has the following format:
```
ROCKET_TLS={certs="/path/to/certs.pem",key="/path/to/key.pem"}
```
@ -40,7 +40,7 @@ Notes:
> `[ERROR] environment variable ROCKET_TLS={certs="/ssl/ecdsa.crt",key="/ssl/ecdsa.key"} could not be parsed`
(There's nothing wrong with the format of the environment variable itself; it's the cert/key contents that Rocket can't parse.)
* If running under Docker, remember that bitwarden_rs will be parsing the `ROCKET_TLS` value when running inside the container, so make sure the `certs` and `key` paths are how they would appear inside the container (which may be different from the paths on the Docker host system).
* If running under Docker, remember that vaultwarden will be parsing the `ROCKET_TLS` value when running inside the container, so make sure the `certs` and `key` paths are how they would appear inside the container (which may be different from the paths on the Docker host system).
```sh
docker run -d --name bitwarden \
@ -48,7 +48,7 @@ docker run -d --name bitwarden \
-v /ssl/keys/:/ssl/ \
-v /bw-data/:/data/ \
-p 443:80 \
bitwardenrs/server:latest
vaultwarden/server:latest
```
You need to mount ssl files (-v argument) and you need to forward appropriate port (-p argument), usually port 443 for HTTPS connections. If you choose a different port number than 443 like for example 3456, remember to explicitly provide that port number when you connect to the service, example: `https://bitwarden.local:3456`.
@ -69,11 +69,11 @@ docker run -d --name bitwarden \
-v /etc/letsencrypt/:/ssl/ \
-v /bw-data/:/data/ \
-p 443:80 \
bitwardenrs/server:latest
vaultwarden/server:latest
```
#### Check if certificate is valid
When your bitwarden_rs server is available to the outside world you can use https://comodosslstore.com/ssltools/ssl-checker.php to check if your SSL certificate is valid including the chain. Without the chain Android devices will fail to connect.
When your vaultwarden server is available to the outside world you can use https://comodosslstore.com/ssltools/ssl-checker.php to check if your SSL certificate is valid including the chain. Without the chain Android devices will fail to connect.
You can also use https://www.ssllabs.com/ssltest/analyze.html to check, but that one does not support custom ports. Also please remember to check the "Do not show the results on the boards" checkbox, else your system will be visible in the "Recently Seen" list.
@ -107,9 +107,9 @@ A bit further in the output you should see the base64-encoded certificates from
[Let's Encrypt](https://letsencrypt.org/) issues SSL/TLS certificates for free.
For this to work, your bitwarden_rs instance must have a DNS name (i.e., you can't simply use an IP address). Let's Encrypt is easier to set up if your bitwarden_rs is reachable on the public Internet, but even if your instance is private (i.e., only reachable on your LAN), it's still possible to get Let's Encrypt certs via [DNS challenge](Running-a-private-bitwarden_rs-instance-with-Let's-Encrypt-certs).
For this to work, your vaultwarden instance must have a DNS name (i.e., you can't simply use an IP address). Let's Encrypt is easier to set up if your vaultwarden is reachable on the public Internet, but even if your instance is private (i.e., only reachable on your LAN), it's still possible to get Let's Encrypt certs via [DNS challenge](Running-a-private-vaultwarden-instance-with-Let's-Encrypt-certs).
If you already own or control a domain, then just add a DNS name for the IP address of your bitwarden_rs instance. If you don't, you can either buy a domain name, try getting one for free at [Freenom](https://www.freenom.com/), or use a service like [Duck DNS](https://www.duckdns.org/) to get a name under an existing domain (e.g., `my-bitwarden.duckdns.org`).
If you already own or control a domain, then just add a DNS name for the IP address of your vaultwarden instance. If you don't, you can either buy a domain name, try getting one for free at [Freenom](https://www.freenom.com/), or use a service like [Duck DNS](https://www.duckdns.org/) to get a name under an existing domain (e.g., `my-bitwarden.duckdns.org`).
Once you have a DNS name for your instance, use an [ACME client](https://letsencrypt.org/docs/client-options/) to get certs for your DNS name. [Certbot](https://certbot.eff.org/) and [acme.sh](https://github.com/acmesh-official/acme.sh) are two of the most popular standalone clients. Some reverse proxies like [Caddy](https://caddyserver.com/) also have built-in ACME clients.
@ -117,8 +117,8 @@ Once you have a DNS name for your instance, use an [ACME client](https://letsenc
[Cloudflare](https://www.cloudflare.com/) provides free service for individuals. If you trust them to proxy your traffic and serve as your DNS provider, you can let them handle issuance of your SSL/TLS certs as well.
Once you've enrolled your domain and added a DNS record for your bitwarden_rs instance, log into the Cloudflare dashboard and select `SSL/TLS`, then `Origin Server`. Generate an origin certificate (you can select a validity period up to 15 years) and configure bitwarden_rs to use it. If you've selected the 15-year validity period, you won't have to renew this origin certificate for the foreseeable future.
Once you've enrolled your domain and added a DNS record for your vaultwarden instance, log into the Cloudflare dashboard and select `SSL/TLS`, then `Origin Server`. Generate an origin certificate (you can select a validity period up to 15 years) and configure vaultwarden to use it. If you've selected the 15-year validity period, you won't have to renew this origin certificate for the foreseeable future.
Note that the origin certificate is used only to secure communications between Cloudflare and bitwarden_rs. Cloudflare will automatically handle issuance and renewal of the certificate used for communicating between clients and Cloudflare.
Note that the origin certificate is used only to secure communications between Cloudflare and vaultwarden. Cloudflare will automatically handle issuance and renewal of the certificate used for communicating between clients and Cloudflare.
Also, if you're using the Rocket HTTPS server built into bitwarden_rs, make sure to select `RSA` as the private key type for the origin certificate, as Rocket doesn't currently support ECC/ECDSA certs.
Also, if you're using the Rocket HTTPS server built into vaultwarden, make sure to select `RSA` as the private key type for the origin certificate, as Rocket doesn't currently support ECC/ECDSA certs.

6
Enabling-U2F-authentication.md

@ -1,14 +1,14 @@
To enable U2F authentication, you must be serving bitwarden_rs from an HTTPS domain with a valid certificate (Either using the included
To enable U2F authentication, you must be serving vaultwarden from an HTTPS domain with a valid certificate (Either using the included
HTTPS options or with a reverse proxy). We recommend using a free certificate from Let's Encrypt.
After that, you need to set the `DOMAIN` environment variable to the same address from where bitwarden_rs is being served:
After that, you need to set the `DOMAIN` environment variable to the same address from where vaultwarden is being served:
```sh
docker run -d --name bitwarden \
-e DOMAIN=https://bw.domain.tld \
-v /bw-data/:/data/ \
-p 80:80 \
bitwardenrs/server:latest
vaultwarden/server:latest
```
Note that the value has to include the `https://` and it may include a port at the end (in the format of `https://bw.domain.tld:port`) when not using `443`.

8
Enabling-WebSocket-notifications.md

@ -1,6 +1,6 @@
WebSocket notifications are used to inform the browser and desktop Bitwarden clients that some event of interest has occurred, such as when an entry in the password database has been modified or deleted. Upon receiving the notification, the client can take an appropriate action, such as refetching the modified entry, or removing the deleted entry from its local copy of the database. In this notification scheme, the Bitwarden client establishes a persistent WebSocket connection with the Bitwarden server (bitwarden_rs in this case). Whenever the server has an event to report, it sends it to the client via this persistent connection.
WebSocket notifications are used to inform the browser and desktop Bitwarden clients that some event of interest has occurred, such as when an entry in the password database has been modified or deleted. Upon receiving the notification, the client can take an appropriate action, such as refetching the modified entry, or removing the deleted entry from its local copy of the database. In this notification scheme, the Bitwarden client establishes a persistent WebSocket connection with the Bitwarden server (vaultwarden in this case). Whenever the server has an event to report, it sends it to the client via this persistent connection.
Note that WebSocket notifications are not applicable to the mobile (Android/iOS) Bitwarden clients. These clients use the native push notification service instead ([FCM](https://firebase.google.com/docs/cloud-messaging) for Android, [APNs](https://developer.apple.com/go/?id=push-notifications) for iOS). bitwarden_rs does not currently support push notifications to mobile clients.
Note that WebSocket notifications are not applicable to the mobile (Android/iOS) Bitwarden clients. These clients use the native push notification service instead ([FCM](https://firebase.google.com/docs/cloud-messaging) for Android, [APNs](https://developer.apple.com/go/?id=push-notifications) for iOS). vaultwarden does not currently support push notifications to mobile clients.
To enable WebSockets notifications, an external reverse proxy is necessary, and it must be configured to do the following:
- Route the `/notifications/hub` endpoint to the WebSocket server, by default at port `3012`, making sure to pass the `Connection` and `Upgrade` headers. (Note the port can be changed with `WEBSOCKET_PORT` variable)
@ -9,7 +9,7 @@ To enable WebSockets notifications, an external reverse proxy is necessary, and
Example configurations are included in [[Proxy examples|proxy-examples]].
Then you need to enable WebSockets negotiation on the bitwarden_rs side by setting the `WEBSOCKET_ENABLED` variable to `true`:
Then you need to enable WebSockets negotiation on the vaultwarden side by setting the `WEBSOCKET_ENABLED` variable to `true`:
```sh
docker run -d --name bitwarden \
@ -17,7 +17,7 @@ docker run -d --name bitwarden \
-v /bw-data/:/data/ \
-p 80:80 \
-p 3012:3012 \
bitwardenrs/server:latest
vaultwarden/server:latest
```
Note: The reason for this workaround is the lack of support for WebSockets from Rocket (though [it's a planned feature](https://github.com/SergioBenitez/Rocket/issues/90)), which forces us to launch a secondary server on a separate port.

4
Enabling-Yubikey-OTP-authentication.md

@ -4,7 +4,7 @@ If `YUBICO_SERVER` is not specified, it will use the default YubiCloud servers.
Notes:
* In order to generate API keys or use a YubiKey with an OTP server, it must be registered. After configuring your key in the [YubiKey Personalization Tool](https://www.yubico.com/products/services-software/personalization-tools/use/), you can register it with the default servers [here](https://upload.yubico.com/).
* aarch64 builds of the server version 1.6.0 or older do not support Yubikey functionality due to upstream issues - see [#262](https://github.com/dani-garcia/bitwarden_rs/issues/262).
* aarch64 builds of the server version 1.6.0 or older do not support Yubikey functionality due to upstream issues - see [#262](https://github.com/dani-garcia/vaultwarden/issues/262).
```sh
docker run -d --name bitwarden \
@ -12,5 +12,5 @@ docker run -d --name bitwarden \
-e YUBICO_SECRET_KEY=ABCDEABCDEABCDEABCDE= \
-v /bw-data/:/data/ \
-p 80:80 \
bitwardenrs/server:latest
vaultwarden/server:latest
```

4
Enabling-admin-page.md

@ -11,7 +11,7 @@ docker run -d --name bitwarden \
-e ADMIN_TOKEN=some_random_token_as_per_above_explanation \
-v /bw-data/:/data/ \
-p 80:80 \
bitwardenrs/server:latest
vaultwarden/server:latest
```
After this, the page will be available in the `/admin` subdirectory.
@ -20,4 +20,4 @@ The first time you save a setting in the admin page, `config.json` will be gener
Note that config changes in the admin page do not take effect until you click the `Save` button. For example, if you are testing SMTP settings, and you change the `SMTP Auth mechanism` setting and then click `Send test email` to test the change, this won't work as expected -- since you didn't click `Save`, the `SMTP Auth mechanism` change won't have taken effect.
**Note:** After changing the `ADMIN_TOKEN`, the currently logged in admins will still be able to use their old login token for [up to 20 minutes](https://github.com/dani-garcia/bitwarden_rs/blob/master/src/api/admin.rs#L87).
**Note:** After changing the `ADMIN_TOKEN`, the currently logged in admins will still be able to use their old login token for [up to 20 minutes](https://github.com/dani-garcia/vaultwarden/blob/master/src/api/admin.rs#L87).

36
FAQs.md

@ -1,32 +1,32 @@
# FAQs
## Is Bitwarden_RS associated with the Bitwarden project or 8bit Solutions LLC?
## Is Vaultwarden associated with the Bitwarden project or 8bit Solutions LLC?
Short answer, **No**.
There sometimes is some contact between the developers of both projects, but there is no collaboration.
Besides that, the Bitwarden_RS project only uses the web vault provided by 8bit Solutions LLC with some patches to make it work with our implementation.
Besides that, the Vaultwarden project only uses the web vault provided by 8bit Solutions LLC with some patches to make it work with our implementation.
<br>
<br>
## Can Bitwarden_RS connect to an Oracle MySQL V8.x database?
It could happen that you get the following warning when trying to start Bitwarden_RS when using Oracle MySQL v8.x
## Can Vaultwarden connect to an Oracle MySQL V8.x database?
It could happen that you get the following warning when trying to start Vaultwarden when using Oracle MySQL v8.x
```
[bitwarden_rs::util][WARN] Can't connect to database, retrying: DieselConError.
[vaultwarden::util][WARN] Can't connect to database, retrying: DieselConError.
[CAUSE] BadConnection(
"Authentication plugin \'caching_sha2_password\' cannot be loaded: /usr/lib/x86_64-linux-gnu/mariadb18/plugin/caching_sha2_password.so: cannot open shared object file: No such file or directory",
)
```
Oracle MySQL v8.x uses a more secure password hashing method by default, which is good, but currently not supported by our builds.
You need to create the Bitwarden_RS user in a specific way so that it uses the old native password hashing.
You need to create the Vaultwarden user in a specific way so that it uses the old native password hashing.
```sql
-- Use this on MySQLv8 installations
CREATE USER 'bitwarden_rs'@'localhost' IDENTIFIED WITH mysql_native_password BY 'yourpassword';
CREATE USER 'vaultwarden'@'localhost' IDENTIFIED WITH mysql_native_password BY 'yourpassword';
```
If you already created the user and only want to change the hashing method, use the following:
```sql
-- Change password type from caching_sha2_password to native
ALTER USER 'bitwarden_rs'@'localhost' IDENTIFIED WITH mysql_native_password BY 'yourpassword';
ALTER USER 'vaultwarden'@'localhost' IDENTIFIED WITH mysql_native_password BY 'yourpassword';
```
Also see: [Using MariaDB - Create Database and User](https://github.com/dani-garcia/bitwarden_rs/wiki/Using-the-MariaDB-(MySQL)-Backend#create-database-and-user)
Also see: [Using MariaDB - Create Database and User](https://github.com/dani-garcia/vaultwarden/wiki/Using-the-MariaDB-(MySQL)-Backend#create-database-and-user)
<br>
<br>
@ -35,8 +35,8 @@ The Bitwarden clients need a secure connection to fully work without any issues.
Most of the time when people are using certificates and still have issues, they are using so called Self-Signed certificates. While those could provide a secure connection, some platforms do not allow or support this.
We recommend to use a service like Lets Encrypt to provide a valid and by most devices by default accepted certificate.
See the following page:
* [Enabling-HTTPS](https://github.com/dani-garcia/bitwarden_rs/wiki/Enabling-HTTPS)
* [Running a private bitwarden_rs instance with Let's Encrypt certs](https://github.com/dani-garcia/bitwarden_rs/wiki/Running-a-private-bitwarden_rs-instance-with-Let%27s-Encrypt-certs)
* [Enabling-HTTPS](https://github.com/dani-garcia/vaultwarden/wiki/Enabling-HTTPS)
* [Running a private vaultwarden instance with Let's Encrypt certs](https://github.com/dani-garcia/vaultwarden/wiki/Running-a-private-vaultwarden-instance-with-Let%27s-Encrypt-certs)
<br>
<br>
@ -44,23 +44,23 @@ See the following page:
There are multiple reasons why there is no icon shown.
If it is just for a few of the vault items it could be that we are not able to extract it. Some sites have some protections enabled which causes our implementation to fail. Most of them require Javascript to work.
It could also be that the Bitwarden_RS server is not able to access the Internet or resolve DNS queries.
It could also be that the Vaultwarden server is not able to access the Internet or resolve DNS queries.
You could check the `/admin/diagnostics` page to see if you can resolve DNS queries and have a connection to the Internet.
If that does work, there could also be a firewall or Outgoing Internet Proxy which maybe blocks these requests.
<br>
<br>
## Can i run Bitwarden_RS as an Azure WebApp
## Can i run Vaultwarden as an Azure WebApp
Unfortunately Azure WebApp's uses CIFS/Samba as there volume storage which does not support locking. This causes issues with the SQLite database file.
There are two ways to solve this.
1. Do not use SQLite, but MariaDB/MySQL or Posgresql as the database backend.
2. Try to disable WAL using the `ENABLE_DB_WAL` environment variable by setting it's value to `false`. This needs to be done on a new file, so you need to remove the previously created `db.sqlite3` file and restart the Bitwarden_RS app again.
2. Try to disable WAL using the `ENABLE_DB_WAL` environment variable by setting it's value to `false`. This needs to be done on a new file, so you need to remove the previously created `db.sqlite3` file and restart the Vaultwarden app again.
<br>
<br>
## I did not find my answer here in the FAQ, what to do next?
Well, please try to search and click through our wonderful [Wiki](https://github.com/dani-garcia/bitwarden_rs/wiki).
If that does not help you, try to look at either [Github Discussions](https://github.com/dani-garcia/bitwarden_rs/discussions) or [Bitwarden_RS Forums](https://bitwardenrs.discourse.group/).
If that also results in no solution, you could try to search the open and closed [Issues](https://github.com/dani-garcia/bitwarden_rs/issues).
Well, please try to search and click through our wonderful [Wiki](https://github.com/dani-garcia/vaultwarden/wiki).
If that does not help you, try to look at either [Github Discussions](https://github.com/dani-garcia/vaultwarden/discussions) or [Vaultwarden Forums](https://bitwardenrs.discourse.group/).
If that also results in no solution, you could try to search the open and closed [Issues](https://github.com/dani-garcia/vaultwarden/issues).
If you still have not found an answer, you can start a topic on either [Github Discussions](https://github.com/dani-garcia/bitwarden_rs/discussions) or [Bitwarden_RS Forums](https://bitwardenrs.discourse.group/), or joins us in our [chatroom](https://matrix.to/#/#bitwarden_rs:matrix.org).
If you still have not found an answer, you can start a topic on either [Github Discussions](https://github.com/dani-garcia/vaultwarden/discussions) or [Vaultwarden Forums](https://bitwardenrs.discourse.group/), or joins us in our [chatroom](https://matrix.to/#/#vaultwarden:matrix.org).

36
Fail2Ban-Setup.md

@ -17,10 +17,10 @@ Setup Fail2ban will prevent attackers to brute force your vault logins. This is
## Pre-requisite
- Filenames are at the top of each code block.
- From Release 1.5.0, Bitwarden_rs supports logging to file. Please set this up : [[Logging|logging]]
- From Release 1.5.0, Vaultwarden supports logging to file. Please set this up : [[Logging|logging]]
- Try to log to web vault with a false account and check the log files for following format
```
[YYYY-MM-DD hh:mm:ss][bitwarden_rs::api::identity][ERROR] Username or password is incorrect. Try again. IP: XXX.XXX.XXX.XXX. Username: email@domain.com.
[YYYY-MM-DD hh:mm:ss][vaultwarden::api::identity][ERROR] Username or password is incorrect. Try again. IP: XXX.XXX.XXX.XXX. Username: email@domain.com.
```
## Installation
@ -113,7 +113,7 @@ As a convention, `path_f2b` means the path needed for Fail2ban to work. This dep
Create and fill the following file
```INI
# path_f2b/filter.d/bitwarden_rs.local
# path_f2b/filter.d/vaultwarden.local
[INCLUDES]
before = common.conf
@ -125,24 +125,24 @@ ignoreregex =
**Tip:** If you get the following error message in `fail2ban.log` (CentOS 7, Fail2Ban v0.9.7)
`fail2ban.filter [5291]: ERROR No 'host' group in '^.*Username or password is incorrect\. Try again\. IP: <ADDR>\. Username:.*$'`
Please Use `<HOST>` instead of `<ADDR>` in `bitwarden_rs.local`
Please Use `<HOST>` instead of `<ADDR>` in `vaultwarden.local`
**Tip:** If you see 127.0.0.1 as the IP address of failed logins in bitwarden.log, then you're probably using a reverse proxy and fail2ban won't work correctly:
```
[YYYY-MM-DD hh:mm:ss][bitwarden_rs::api::identity][ERROR] Username or password is incorrect. Try again. IP: 127.0.0.1. Username: email@example.com.
[YYYY-MM-DD hh:mm:ss][vaultwarden::api::identity][ERROR] Username or password is incorrect. Try again. IP: 127.0.0.1. Username: email@example.com.
```
To remedy this, forward the true remote address to bitwarden_rs via the X-Real-IP header. How to do this varies depending on the proxy you use. For example, in Caddy 2.x, when you define the reverse-proxy, define `header_up X-Real-IP {remote_host}`. See [Proxy examples](https://github.com/dani-garcia/bitwarden_rs/wiki/Proxy-examples) for more info.
To remedy this, forward the true remote address to vaultwarden via the X-Real-IP header. How to do this varies depending on the proxy you use. For example, in Caddy 2.x, when you define the reverse-proxy, define `header_up X-Real-IP {remote_host}`. See [Proxy examples](https://github.com/dani-garcia/vaultwarden/wiki/Proxy-examples) for more info.
### Jail
Create and fill the following file
```INI
# path_f2b/jail.d/bitwarden_rs.local
# path_f2b/jail.d/vaultwarden.local
[bitwarden_rs]
[vaultwarden]
enabled = true
port = 80,443,8081
filter = bitwarden_rs
filter = vaultwarden
banaction = %(banaction_allports)s
logpath = /path/to/bitwarden.log
maxretry = 3
@ -152,7 +152,7 @@ findtime = 14400
Note: Docker uses the FORWARD chain instead of the default INPUT chain. Therefore replace the `banaction` line with the following `action` when using Docker:
```INI
action = iptables-allports[name=bitwarden_rs, chain=FORWARD]
action = iptables-allports[name=vaultwarden, chain=FORWARD]
```
**NOTE**:
@ -176,7 +176,7 @@ If you've enabled the admin console by setting the `ADMIN_TOKEN` environment var
Create and fill the following file
```INI
# path_f2b/filter.d/bitwarden_rs-admin.local
# path_f2b/filter.d/vaultwarden-admin.local
[INCLUDES]
before = common.conf
@ -188,18 +188,18 @@ ignoreregex =
**Tip:** If you get the following error message in `fail2ban.log`
`ERROR NOK: ("No 'host' group in '^.*Invalid admin token\\. IP: <ADDR>.*$'")`
Please Use `<HOST>` instead of `<ADDR>` in `bitwarden_rs-admin.local`
Please Use `<HOST>` instead of `<ADDR>` in `vaultwarden-admin.local`
### Jail
Create and fill the following file
```INI
# path_f2b/jail.d/bitwarden_rs-admin.local
# path_f2b/jail.d/vaultwarden-admin.local
[bitwarden_rs-admin]
[vaultwarden-admin]
enabled = true
port = 80,443
filter = bitwarden_rs-admin
filter = vaultwarden-admin
banaction = %(banaction_allports)s
logpath = /path/to/bitwarden.log
maxretry = 3
@ -209,7 +209,7 @@ findtime = 14400
Note: Docker uses the FORWARD chain instead of the default INPUT chain. Therefore replace the `banaction` line with the following `action` when using Docker:
```INI
action = iptables-allports[name=bitwarden_rs-admin, chain=FORWARD]
action = iptables-allports[name=vaultwarden-admin, chain=FORWARD]
```
Reload fail2ban for changes to take effect:
@ -225,9 +225,9 @@ If it works correctly and your IP is banned, you can unban the IP by running:
Without Docker:
```bash
# With Docker
sudo docker exec -t fail2ban fail2ban-client set bitwarden_rs unbanip XX.XX.XX.XX
sudo docker exec -t fail2ban fail2ban-client set vaultwarden unbanip XX.XX.XX.XX
# Without Docker
sudo fail2ban-client set bitwarden_rs unbanip XX.XX.XX.XX
sudo fail2ban-client set vaultwarden unbanip XX.XX.XX.XX
```
If Fail2Ban does not appear to be functioning, verify that the path to the Bitwarden log file is correct. For Docker: If the specified log file is not being generated and/or updated, make sure the `EXTENDED_LOGGING` env variable is set to true (which is default) and that the path to the log file is the path inside the Docker (when you use `/bw-data/:/data/` the log file should be in `/data/...` to be outside the container).

34
Hardening-Guide.md

@ -1,15 +1,15 @@
# Application configuration
The subsections below cover hardening related to bitwarden_rs itself.
The subsections below cover hardening related to vaultwarden itself.
## Disable registration and (optionally) invitations
By default, bitwarden_rs allows any anonymous user to register new accounts on the server without first being invited. While this is not necessary if you have access to the admin page, this is useful your first user on the server and is recommended that you disable it in the admin panel (if the admin panel is enabled) or [[with the environment variable|Disable-registration-of-new-users]] to prevent attackers from creating accounts on your bitwarden_rs server.
By default, vaultwarden allows any anonymous user to register new accounts on the server without first being invited. While this is not necessary if you have access to the admin page, this is useful your first user on the server and is recommended that you disable it in the admin panel (if the admin panel is enabled) or [[with the environment variable|Disable-registration-of-new-users]] to prevent attackers from creating accounts on your vaultwarden server.
bitwarden_rs also allows registered users to invite other new users to create accounts on the server and join their organizations. This does not pose an immediate risk (as long as you trust your users), but it can be disabled in the admin panel or [[with the environment variable|Disable-invitations]].
vaultwarden also allows registered users to invite other new users to create accounts on the server and join their organizations. This does not pose an immediate risk (as long as you trust your users), but it can be disabled in the admin panel or [[with the environment variable|Disable-invitations]].
## Disable password hint display
bitwarden_rs displays password hints on the login page to accommodate small/local deployments that do not have SMTP configured, which could be abused by an attacker to facilitate password-guessing attacks against users on the server. This can be disabled in the admin panel by unchecking the `Show password hints` option or [[with the environment variable|Password-hint-display]].
vaultwarden displays password hints on the login page to accommodate small/local deployments that do not have SMTP configured, which could be abused by an attacker to facilitate password-guessing attacks against users on the server. This can be disabled in the admin panel by unchecking the `Show password hints` option or [[with the environment variable|Password-hint-display]].
# HTTPS / TLS configuration
@ -17,11 +17,11 @@ The subsections below cover hardening related to HTTPS / TLS.
## Strict SNI
[SNI](https://en.wikipedia.org/wiki/Server_Name_Indication) is how a web browser requests that an HTTPS server provide the SSL/TLS certificate for a particular site (e.g., `bitwarden.example.com`). Suppose `bitwarden.example.com` has the IP address `1.2.3.4`. Ideally, you want your instance to only be accessible via https://bitwarden.example.com, and not https://1.2.3.4. This is because IP addresses are continually scanned for various reasons, and your bitwarden_rs instance becomes a more obvious target if it can be detected this way. For example, a simple [Shodan search](https://www.shodan.io/search?query=bitwarden) reveals a number of Bitwarden instances that are accessible by IP address.
[SNI](https://en.wikipedia.org/wiki/Server_Name_Indication) is how a web browser requests that an HTTPS server provide the SSL/TLS certificate for a particular site (e.g., `bitwarden.example.com`). Suppose `bitwarden.example.com` has the IP address `1.2.3.4`. Ideally, you want your instance to only be accessible via https://bitwarden.example.com, and not https://1.2.3.4. This is because IP addresses are continually scanned for various reasons, and your vaultwarden instance becomes a more obvious target if it can be detected this way. For example, a simple [Shodan search](https://www.shodan.io/search?query=bitwarden) reveals a number of Bitwarden instances that are accessible by IP address.
## Reverse proxying
In general, you should avoid enabling HTTPS via bitwarden_rs's built-in [[Rocket TLS support|Enabling-HTTPS]], especially if your instance is publicly accessible. Rocket itself lists the following [warning](https://rocket.rs/v0.4/guide/configuration/#configuring-tls):
In general, you should avoid enabling HTTPS via vaultwarden's built-in [[Rocket TLS support|Enabling-HTTPS]], especially if your instance is publicly accessible. Rocket itself lists the following [warning](https://rocket.rs/v0.4/guide/configuration/#configuring-tls):
> Rocket's built-in TLS is not considered ready for production use. It is intended for development use only.
@ -35,24 +35,24 @@ The subsections below cover hardening related to Docker.
## Run as a non-root user
The bitwarden_rs Docker image is configured to run the container process as the `root` user by default. This allows bitwarden_rs to read/write any data [bind-mounted](https://docs.docker.com/storage/bind-mounts/) into the container without permission issues, even if that data is owned by another user (e.g., your user account on the Docker host).
The default configuration provides a good balance of security and usability -- running as root within an unprivileged Docker container provides a reasonable level of isolation on its own, while also making setup easier for users who aren't necessarily well-versed in how to manage ownership/permissions on Linux. However, as a general policy, it's better security-wise to run processes with the minimum privileges required; this is somewhat less of a concern with programs written in a memory-safe language like Rust, but note that bitwarden_rs does also use some library code written in C (SQLite, OpenSSL, MySQL, PostgreSQL, etc.).
The vaultwarden Docker image is configured to run the container process as the `root` user by default. This allows vaultwarden to read/write any data [bind-mounted](https://docs.docker.com/storage/bind-mounts/) into the container without permission issues, even if that data is owned by another user (e.g., your user account on the Docker host).
The default configuration provides a good balance of security and usability -- running as root within an unprivileged Docker container provides a reasonable level of isolation on its own, while also making setup easier for users who aren't necessarily well-versed in how to manage ownership/permissions on Linux. However, as a general policy, it's better security-wise to run processes with the minimum privileges required; this is somewhat less of a concern with programs written in a memory-safe language like Rust, but note that vaultwarden does also use some library code written in C (SQLite, OpenSSL, MySQL, PostgreSQL, etc.).
To run the container process (bitwarden_rs) as a non-root user (uid/gid 1000) in Docker:
To run the container process (vaultwarden) as a non-root user (uid/gid 1000) in Docker:
docker run -u 1000:1000 -e ROCKET_PORT=8080 -p <host-port>:8080 \
[...other args...] \
bitwardenrs/server:latest
vaultwarden/server:latest
The default user in many Linux distros has uid/gid 1000 (run the `id` command to verify), so this is a good value to use if you prefer to be able to easily access your bitwarden_rs data without changing to another user, but you can adjust the uid/gid as needed. Note that you'll most likely need to specify a numeric uid/gid, because the bitwarden_rs container doesn't share the same mapping of user/group names to uid/gid (e.g., compare the `/etc/passwd` and `/etc/group` files in the container to the ones on the Docker host).
The default user in many Linux distros has uid/gid 1000 (run the `id` command to verify), so this is a good value to use if you prefer to be able to easily access your vaultwarden data without changing to another user, but you can adjust the uid/gid as needed. Note that you'll most likely need to specify a numeric uid/gid, because the vaultwarden container doesn't share the same mapping of user/group names to uid/gid (e.g., compare the `/etc/passwd` and `/etc/group` files in the container to the ones on the Docker host).
`ROCKET_PORT` defaults to 80, which is a [privileged port](https://www.w3.org/Daemon/User/Installation/PrivilegedPorts.html); it needs to be 1024 or higher when running as a non-root user, or else you'll get a permission denied error when bitwarden_rs attempts to bind and listen for connections on that port.
`ROCKET_PORT` defaults to 80, which is a [privileged port](https://www.w3.org/Daemon/User/Installation/PrivilegedPorts.html); it needs to be 1024 or higher when running as a non-root user, or else you'll get a permission denied error when vaultwarden attempts to bind and listen for connections on that port.
To do the same in `docker-compose`:
services:
bitwarden:
image: bitwardenrs/server:latest
image: vaultwarden/server:latest
container_name: bitwarden
user: 1000:1000
environment:
@ -60,13 +60,13 @@ To do the same in `docker-compose`:
... other configuration ...
Since `ROCKET_PORT` is being changed here, make sure to also update your reverse proxy config to proxy bitwarden_rs traffic to port 8080 (or whatever higher port you chose) instead of 80.
Since `ROCKET_PORT` is being changed here, make sure to also update your reverse proxy config to proxy vaultwarden traffic to port 8080 (or whatever higher port you chose) instead of 80.
## Mounting data into the container
Generally, only data that bitwarden_rs needs to operate properly should be mounted into the bitwarden_rs container (typically, this is just your data directory, and maybe a directory containing SSL/TLS certs and private keys). For example, don't mount your entire home directory, `/var/run/docker.sock`, etc. unless you have a specific reason and know what you're doing.
Generally, only data that vaultwarden needs to operate properly should be mounted into the vaultwarden container (typically, this is just your data directory, and maybe a directory containing SSL/TLS certs and private keys). For example, don't mount your entire home directory, `/var/run/docker.sock`, etc. unless you have a specific reason and know what you're doing.
Also, if you don't expect bitwarden_rs to modify the data you're mounting in (e.g., certs), then [mount it read-only](https://docs.docker.com/storage/bind-mounts/#use-a-read-only-bind-mount) by adding `:ro` to the volume specification (for example, `docker run -v /home/username/bitwarden-ssl:/ssl:ro`).
Also, if you don't expect vaultwarden to modify the data you're mounting in (e.g., certs), then [mount it read-only](https://docs.docker.com/storage/bind-mounts/#use-a-read-only-bind-mount) by adding `:ro` to the volume specification (for example, `docker run -v /home/username/bitwarden-ssl:/ssl:ro`).
# Miscellaneous
@ -77,4 +77,4 @@ See: [[Fail2Ban Setup|Fail2Ban Setup]]
## Hiding under a subdir
Traditionally, a Bitwarden instance resides at the root of a subdomain (i.e., `bitwarden.example.com`, and not `bitwarden.example.com/some/path`). The upstream Bitwarden server currently only supports subdomain roots, while bitwarden_rs adds support for [[alternate base directories|Using-an-alternate-base-dir]]. For some users, this is useful simply because they only have access to one subdomain and want to run multiple services under different directories. In such cases, they typically choose something obvious like `mysubdomain.example.com/bitwarden`. However, you can also use this to provide an extra layer of protection by putting bitwarden_rs under something like `mysubdomain.example.com/bitwarden/<mysecretstring>`, where `<mysecretstring>` effectively acts as a password. Some may argue that this is [security through obscurity](https://en.wikipedia.org/wiki/Security_through_obscurity), but it's actually [defense in depth](https://en.wikipedia.org/wiki/Defense_in_depth_(computing)) -- the secrecy of the subdir is just an extra layer of security, and not intended to be the primary means of security (which is still the strength of a user's master password).
Traditionally, a Bitwarden instance resides at the root of a subdomain (i.e., `bitwarden.example.com`, and not `bitwarden.example.com/some/path`). The upstream Bitwarden server currently only supports subdomain roots, while vaultwarden adds support for [[alternate base directories|Using-an-alternate-base-dir]]. For some users, this is useful simply because they only have access to one subdomain and want to run multiple services under different directories. In such cases, they typically choose something obvious like `mysubdomain.example.com/bitwarden`. However, you can also use this to provide an extra layer of protection by putting vaultwarden under something like `mysubdomain.example.com/bitwarden/<mysecretstring>`, where `<mysecretstring>` effectively acts as a password. Some may argue that this is [security through obscurity](https://en.wikipedia.org/wiki/Security_through_obscurity), but it's actually [defense in depth](https://en.wikipedia.org/wiki/Defense_in_depth_(computing)) -- the secrecy of the subdir is just an extra layer of security, and not intended to be the primary means of security (which is still the strength of a user's master password).

18
Home.md

@ -1,12 +1,12 @@
# bitwarden_rs
# vaultwarden
bitwarden_rs is an unofficial Bitwarden server implementation written in Rust. It is compatible with the [official Bitwarden clients](https://bitwarden.com/download/), and is ideal for self-hosted deployments where running the official resource-heavy service is undesirable.
vaultwarden is an unofficial Bitwarden server implementation written in Rust. It is compatible with the [official Bitwarden clients](https://bitwarden.com/download/), and is ideal for self-hosted deployments where running the official resource-heavy service is undesirable.
bitwarden_rs is targeted towards individuals, families, and smaller organizations. Development of features that are mainly useful to larger organizations (e.g., single sign-on, directory syncing, etc.) is not a priority, though high-quality PRs that implement such features would be welcome.
vaultwarden is targeted towards individuals, families, and smaller organizations. Development of features that are mainly useful to larger organizations (e.g., single sign-on, directory syncing, etc.) is not a priority, though high-quality PRs that implement such features would be welcome.
## Supported features
bitwarden_rs implements the Bitwarden APIs required for most functionality, including:
vaultwarden implements the Bitwarden APIs required for most functionality, including:
* Web interface (equivalent to https://vault.bitwarden.com/)
* Personal vault support
@ -31,9 +31,9 @@ bitwarden_rs implements the Bitwarden APIs required for most functionality, incl
## Missing features
Issue [#246](https://github.com/dani-garcia/bitwarden_rs/issues/246) contains the comprehensive list of feature requests, both features of the official server that are missing in bitwarden_rs, as well as enhancements specific to bitwarden_rs.
Issue [#246](https://github.com/dani-garcia/vaultwarden/issues/246) contains the comprehensive list of feature requests, both features of the official server that are missing in vaultwarden, as well as enhancements specific to vaultwarden.
To simplify comparison with the official server, this section summarizes the features implemented in the official server that are not currently available in bitwarden_rs.
To simplify comparison with the official server, this section summarizes the features implemented in the official server that are not currently available in vaultwarden.
Features that may be added as time permits (contributions are always welcome):
@ -42,7 +42,7 @@ Features that may be added as time permits (contributions are always welcome):
* [Event Logs](https://bitwarden.com/help/article/event-logs/)
* [Live sync](https://bitwarden.com/blog/post/live-sync/) (push notifications) for mobile clients (Android/iOS)
* Certain enterprise policies:
* [Two-Step Login](https://bitwarden.com/help/article/policies/#two-step-login) ([#981](https://github.com/dani-garcia/bitwarden_rs/issues/981))
* [Two-Step Login](https://bitwarden.com/help/article/policies/#two-step-login) ([#981](https://github.com/dani-garcia/vaultwarden/issues/981))
* [Single Organization](https://bitwarden.com/help/article/policies/#single-organization)
Features that probably won't be added unless contributed:
@ -55,6 +55,6 @@ Features that probably won't be added unless contributed:
To ask a question, offer suggestions, request new features, or get help configuring or installing the software, please [use the forum](https://bitwardenrs.discourse.group/).
If you spot any bugs or crashes with bitwarden_rs itself, please [create an issue](https://github.com/dani-garcia/bitwarden_rs/issues/). Make sure there aren't any similar issues open, though!
If you spot any bugs or crashes with vaultwarden itself, please [create an issue](https://github.com/dani-garcia/vaultwarden/issues/). Make sure there aren't any similar issues open, though!
If you prefer to chat, we're usually hanging around at [#bitwarden_rs:matrix.org](https://matrix.to/#/#bitwarden_rs:matrix.org) room on Matrix. Feel free to join us!
If you prefer to chat, we're usually hanging around at [#vaultwarden:matrix.org](https://matrix.to/#/#vaultwarden:matrix.org) room on Matrix. Feel free to join us!

6
Kubernetes-deployment.md

@ -5,11 +5,11 @@ There are two options for deploying on Kubernetes:
### Natively:
Please check the [kubernetes-bitwarden_rs](https://github.com/icicimov/kubernetes-bitwarden_rs) repository for example deployment in Kubernetes.
It will setup a fully functional and secure `bitwarden_rs` application in Kubernetes behind [nginx-ingress-controller](https://github.com/kubernetes/ingress-nginx) and AWS [ELBv1](https://aws.amazon.com/elasticloadbalancing/features/#Details_for_Elastic_Load_Balancing_Products). It provides a little bit more than just simple deployment but you can use all or just part of the manifests depending on your needs and setup.
It will setup a fully functional and secure `vaultwarden` application in Kubernetes behind [nginx-ingress-controller](https://github.com/kubernetes/ingress-nginx) and AWS [ELBv1](https://aws.amazon.com/elasticloadbalancing/features/#Details_for_Elastic_Load_Balancing_Products). It provides a little bit more than just simple deployment but you can use all or just part of the manifests depending on your needs and setup.
### Via Helm:
Please check the [helm-bitwarden_rs](https://github.com/Skeen/helm-bitwarden_rs) repository for example deployment in Kubernetes.
It will setup a fully functional and secure `bitwarden_rs` application in Kubernetes behind an nginx controller of your choice. It works well and is tested with the [microk8s](https://microk8s.io/) setup. There is support for generating SSL certificates via [cert-manager](https://github.com/jetstack/cert-manager) too.
It will setup a fully functional and secure `vaultwarden` application in Kubernetes behind an nginx controller of your choice. It works well and is tested with the [microk8s](https://microk8s.io/) setup. There is support for generating SSL certificates via [cert-manager](https://github.com/jetstack/cert-manager) too.
Another option with as much, or even more, flexibility would be: https://github.com/gissilabs/charts/tree/master/bitwardenrs
Another option with as much, or even more, flexibility would be: https://github.com/gissilabs/charts/tree/master/vaultwarden

6
Logging.md

@ -1,4 +1,4 @@
bitwarden_rs logs only to [standard output](https://en.wikipedia.org/wiki/Standard_streams#Standard_output_(stdout)) (stdout) by default. You can also configure it to log to a file.
vaultwarden logs only to [standard output](https://en.wikipedia.org/wiki/Standard_streams#Standard_output_(stdout)) (stdout) by default. You can also configure it to log to a file.
## Logging to a file
@ -15,7 +15,7 @@ When this environment variable is set, log messages will be logged to both stdou
## Changing the log level
To reduce the amount of log messages, you can set the log level to 'warn' (default is 'info'). The [Log level](https://docs.rs/log/0.4.7/log/enum.Level.html#variants) can be adjusted with the environment variable `LOG_LEVEL` while also setting `EXTENDED_LOGGING=true`. NOTE: Using the log level "warn" or "error" still allows [Fail2Ban](https://github.com/dani-garcia/bitwarden_rs/wiki/Fail2Ban-Setup) to work properly.
To reduce the amount of log messages, you can set the log level to 'warn' (default is 'info'). The [Log level](https://docs.rs/log/0.4.7/log/enum.Level.html#variants) can be adjusted with the environment variable `LOG_LEVEL` while also setting `EXTENDED_LOGGING=true`. NOTE: Using the log level "warn" or "error" still allows [Fail2Ban](https://github.com/dani-garcia/vaultwarden/wiki/Fail2Ban-Setup) to work properly.
`LOG_LEVEL` options are: "trace", "debug", "info", "warn", "error" or "off".
@ -30,6 +30,6 @@ docker run -d --name bitwarden \
If running in Docker: `docker logs <container-name>`
If running via `systemd`: `journalctl -u bitwarden_rs.service` (or whatever your service is named)
If running via `systemd`: `journalctl -u vaultwarden.service` (or whatever your service is named)
Otherwise, check where standard output is being redirected, or set the `LOG_FILE` environment variable and view that file.

2
Logrotate-example.md

@ -1,4 +1,4 @@
Over time, the Bitwarden_RS log file can grow to a significant size. Using logrotate, we can periodically rotate logs.
Over time, the Vaultwarden log file can grow to a significant size. Using logrotate, we can periodically rotate logs.
```sh
sudo nano /etc/logrotate.d/bitwarden

4
Password-hint-display.md

@ -1,9 +1,9 @@
Usually, password hints are sent by email. But as bitwarden_rs is made with small or personal deployment in mind, hints are also available from the password hint page, so you don't have to configure an email service. If you want to disable this feature, you can use the `SHOW_PASSWORD_HINT` variable:
Usually, password hints are sent by email. But as vaultwarden is made with small or personal deployment in mind, hints are also available from the password hint page, so you don't have to configure an email service. If you want to disable this feature, you can use the `SHOW_PASSWORD_HINT` variable:
```sh
docker run -d --name bitwarden \
-e SHOW_PASSWORD_HINT=false \
-v /bw-data/:/data/ \
-p 80:80 \
bitwardenrs/server:latest
vaultwarden/server:latest
```

28
Pre-built-binaries.md

@ -1,19 +1,19 @@
bitwarden_rs doesn't currently provide standalone binaries as a separate download, but for platforms that have an Alpine-based Docker image available (currently x86-64 and ARMv7), you can extract standalone, statically-linked binaries from the official Docker images. Each Docker image also includes a matching web vault build (which is platform-independent).
vaultwarden doesn't currently provide standalone binaries as a separate download, but for platforms that have an Alpine-based Docker image available (currently x86-64 and ARMv7), you can extract standalone, statically-linked binaries from the official Docker images. Each Docker image also includes a matching web vault build (which is platform-independent).
## Extracting binaries with Docker installed
Assuming you want to extract binaries for the platform you're running on:
```
docker pull bitwardenrs/server:alpine
docker create --name bwrs bitwardenrs/server:alpine
docker cp bwrs:/bitwarden_rs .
docker pull vaultwarden/server:alpine
docker create --name bwrs vaultwarden/server:alpine
docker cp bwrs:/vaultwarden .
docker cp bwrs:/web-vault .
docker rm bwrs
```
If you want binaries for a different platform (for example, you only have Docker installed on your x86-64 machine, but you want to run bitwarden_rs on a Raspberry Pi), add the `--platform` option to the `docker pull` command:
If you want binaries for a different platform (for example, you only have Docker installed on your x86-64 machine, but you want to run vaultwarden on a Raspberry Pi), add the `--platform` option to the `docker pull` command:
```
docker pull --platform linux/arm/v7 bitwardenrs/server:alpine
docker pull --platform linux/arm/v7 vaultwarden/server:alpine
# Run remaining commands as above.
# Note that the `docker create` command may print a message like:
# WARNING: The requested image's platform (linux/arm/v7) does not match the detected host platform (linux/amd64)
@ -29,9 +29,9 @@ $ mkdir bwrs-image
$ cd bwrs-image
$ wget https://raw.githubusercontent.com/jjlin/docker-image-extract/main/docker-image-extract
$ chmod +x docker-image-extract
$ ./docker-image-extract bitwardenrs/server:alpine
$ ./docker-image-extract vaultwarden/server:alpine
Getting API token...
Getting image manifest for bitwardenrs/server:alpine...
Getting image manifest for vaultwarden/server:alpine...
Downloading layer 801bfaa63ef2094d770c809815b9e2b9c1194728e5e754ef7bc764030e140cea...
Extracting layer...
Downloading layer c6d331ed95271d8005dea195449ab4ef943017dc97ab134a4426faf441ae4fa6...
@ -49,14 +49,14 @@ Extracting layer...
Downloading layer 8516f4cd818630cd60fa18254b072f8d9c3748bdb56f6e2527dc1c204e8e017c...
Extracting layer...
Image contents extracted into ./output.
$ ls -ld output/{bitwarden_rs,web-vault}
-rwx------ 1 user user 22054608 Feb 6 21:46 output/bitwarden_rs
$ ls -ld output/{vaultwarden,web-vault}
-rwx------ 1 user user 22054608 Feb 6 21:46 output/vaultwarden
drwx------ 8 user user 4096 Feb 6 21:46 output/web-vault/
```
If you want the ARMv7 image, you currently have to download it by digest.
Go to https://hub.docker.com/r/bitwardenrs/server/tags?name=alpine and find the entry for the `alpine` tag.
Go to https://hub.docker.com/r/vaultwarden/server/tags?name=alpine and find the entry for the `alpine` tag.
Click the partial digest for the `linux/arm/v7` image:
![](https://i.imgur.com/T5WdwtS.png)
@ -65,10 +65,10 @@ This should bring you to a page that shows the full digest:
![](https://i.imgur.com/Hsz8vJ4.png)
Copy the full digest, and replace the `docker-image-extract bitwardenrs/server:alpine` command above with
`docker-image-extract bitwardenrs/server:<full_digest>`.
Copy the full digest, and replace the `docker-image-extract vaultwarden/server:alpine` command above with
`docker-image-extract vaultwarden/server:<full_digest>`.
For example:
```
$ ./docker-image-extract bitwardenrs/server:sha256:ef129de113bec3409b6370c37a6e5573a1dacc051a3aae2a8a3339323ae63623
$ ./docker-image-extract vaultwarden/server:sha256:ef129de113bec3409b6370c37a6e5573a1dacc051a3aae2a8a3339323ae63623
```

2
Private-CA-and-self-signed-certs-that-work-with-Chrome.md

@ -1,4 +1,4 @@
:warning: :poop: :warning: This method is for testing and development only. The vast majority of users should not use this method, as it requires loading a cert on each of your devices, which is both error-prone and requires future maintenance. Instead, focus your energy on obtaining real certs via [Let's Encrypt](https://letsencrypt.org/getting-started/). This can even work if your bitwarden_rs instance is not on the public Internet ([[example|Running-a-private-bitwarden_rs-instance-with-Let's-Encrypt-certs]]).
:warning: :poop: :warning: This method is for testing and development only. The vast majority of users should not use this method, as it requires loading a cert on each of your devices, which is both error-prone and requires future maintenance. Instead, focus your energy on obtaining real certs via [Let's Encrypt](https://letsencrypt.org/getting-started/). This can even work if your vaultwarden instance is not on the public Internet ([[example|Running-a-private-vaultwarden-instance-with-Let's-Encrypt-certs]]).
:skull_and_crossbones: :skull_and_crossbones: :skull_and_crossbones: This method is not supported. Please do not open GitHub issues or post on the discussion forums asking about how to get this to work.

62
Proxy-examples.md

@ -1,10 +1,10 @@
In this document, `<SERVER>` refers to the IP or domain where you access bitwarden_rs. If both the reverse proxy and bitwarden_rs are running on the same system, simply use `localhost`.
In this document, `<SERVER>` refers to the IP or domain where you access vaultwarden. If both the reverse proxy and vaultwarden are running on the same system, simply use `localhost`.
By default, bitwarden_rs listens on port 80 for web (REST API) traffic and on port 3012 for WebSocket traffic (if [[WebSocket notifications|Enabling-WebSocket-notifications]] are enabled). The reverse proxy should be configured to terminate SSL/TLS connections (preferably on port 443, the standard port for HTTPS). The reverse proxy then passes incoming client requests to bitwarden_rs on port 80 or 3012 as appropriate, and upon receiving a response from bitwarden_rs, passes that response back to the client.
By default, vaultwarden listens on port 80 for web (REST API) traffic and on port 3012 for WebSocket traffic (if [[WebSocket notifications|Enabling-WebSocket-notifications]] are enabled). The reverse proxy should be configured to terminate SSL/TLS connections (preferably on port 443, the standard port for HTTPS). The reverse proxy then passes incoming client requests to vaultwarden on port 80 or 3012 as appropriate, and upon receiving a response from vaultwarden, passes that response back to the client.
Note that when you put bitwarden_rs behind a reverse proxy, the connections between the reverse proxy and bitwarden_rs are typically assumed to be going through a secure private network, and thus do not need to be encrypted. The examples below assume you are running in this configuration, in which case you should not enable the HTTPS functionality built into bitwarden_rs (i.e., you should not set the `ROCKET_TLS` environment variable). If you do, connections will fail since the reverse proxy is using HTTP to connect to bitwarden_rs, but you're configuring bitwarden_rs to expect HTTPS.
Note that when you put vaultwarden behind a reverse proxy, the connections between the reverse proxy and vaultwarden are typically assumed to be going through a secure private network, and thus do not need to be encrypted. The examples below assume you are running in this configuration, in which case you should not enable the HTTPS functionality built into vaultwarden (i.e., you should not set the `ROCKET_TLS` environment variable). If you do, connections will fail since the reverse proxy is using HTTP to connect to vaultwarden, but you're configuring vaultwarden to expect HTTPS.
It's common to use [Docker Compose](https://docs.docker.com/compose/) to link containerized services together (e.g., bitwarden_rs and a reverse proxy). See [[Using Docker Compose|Using-Docker-Compose]] for an example of this.
It's common to use [Docker Compose](https://docs.docker.com/compose/) to link containerized services together (e.g., vaultwarden and a reverse proxy). See [[Using Docker Compose|Using-Docker-Compose]] for an example of this.
<details>
<summary>Caddy 1.x (deprecated)</summary><br/>
@ -80,7 +80,7 @@ If you prefer, you can also directly specify a value instead of substituting an
# Proxy everything else to Rocket
reverse_proxy <SERVER>:80 {
# Send the true remote IP to Rocket, so that bitwarden_rs can put this in the
# Send the true remote IP to Rocket, so that vaultwarden can put this in the
# log, so that fail2ban can ban the correct IP.
header_up X-Real-IP {remote_host}
}
@ -142,7 +142,7 @@ server {
<details>
<summary>Nginx with sub-path (by BlackDex)</summary><br/>
In this example bitwarden_rs will be available via https://bitwarden.example.tld/vault/<br/>
In this example vaultwarden will be available via https://bitwarden.example.tld/vault/<br/>
If you want to use any other sub-path, like `bitwarden` or `secret-vault` you should change `/vault/` in the example below to match.<br/>
<br/>
For this to work you need to configure your `DOMAIN` variable to match so it should look like:
@ -154,26 +154,26 @@ DOMAIN=https://bitwarden.example.tld/vault/
```nginx
# Define the server IP and ports here.
upstream bitwardenrs-default { server 127.0.0.1:8080; }
upstream bitwardenrs-ws { server 127.0.0.1:3012; }
upstream vaultwarden-default { server 127.0.0.1:8080; }
upstream vaultwarden-ws { server 127.0.0.1:3012; }
# Redirect HTTP to HTTPS
server {
listen 80;
listen [::]:80;
server_name bitwardenrs.example.tld;
server_name vaultwarden.example.tld;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name bitwardenrs.example.tld;
server_name vaultwarden.example.tld;
# Specify SSL Config when needed
#ssl_certificate /path/to/certificate/letsencrypt/live/bitwardenrs.example.tld/fullchain.pem;
#ssl_certificate_key /path/to/certificate/letsencrypt/live/bitwardenrs.example.tld/privkey.pem;
#ssl_trusted_certificate /path/to/certificate/letsencrypt/live/bitwardenrs.example.tld/fullchain.pem;
#ssl_certificate /path/to/certificate/letsencrypt/live/vaultwarden.example.tld/fullchain.pem;
#ssl_certificate_key /path/to/certificate/letsencrypt/live/vaultwarden.example.tld/privkey.pem;
#ssl_trusted_certificate /path/to/certificate/letsencrypt/live/vaultwarden.example.tld/fullchain.pem;
client_max_body_size 128M;
@ -185,7 +185,7 @@ server {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass http://bitwardenrs-default;
proxy_pass http://vaultwarden-default;
}
location /vault/notifications/hub/negotiate {
@ -194,7 +194,7 @@ server {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass http://bitwardenrs-default;
proxy_pass http://vaultwarden-default;
}
location /vault/notifications/hub {
@ -202,7 +202,7 @@ server {
proxy_set_header Connection $http_connection;
proxy_set_header X-Real-IP $remote_addr;
proxy_pass http://bitwardenrs-ws;
proxy_pass http://vaultwarden-ws;
}
# Optionally add extra authentication besides the ADMIN_TOKEN
@ -217,7 +217,7 @@ server {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass http://bitwardenrs-default;
proxy_pass http://vaultwarden-default;
}
}
@ -227,7 +227,7 @@ server {
<details>
<summary>Nginx (by ypid)</summary><br/>
Ansible inventory example that uses DebOps to configure nginx as a reverse proxy for bitwarden_rs. I choose to go with the PSK in the URL for additional security to not expose the API to everyone on the Internet because the client apps do not support client certificates yet (I tested it). Note: Using subpath/PSK requires to patch the source code and recompile, ref: https://github.com/dani-garcia/bitwarden_rs/issues/241#issuecomment-436376497. /admin is untested. For general discussion about subpath hosting for security refer to: https://github.com/debops/debops/issues/1233
Ansible inventory example that uses DebOps to configure nginx as a reverse proxy for vaultwarden. I choose to go with the PSK in the URL for additional security to not expose the API to everyone on the Internet because the client apps do not support client certificates yet (I tested it). Note: Using subpath/PSK requires to patch the source code and recompile, ref: https://github.com/dani-garcia/vaultwarden/issues/241#issuecomment-436376497. /admin is untested. For general discussion about subpath hosting for security refer to: https://github.com/debops/debops/issues/1233
```YAML
bitwarden__fqdn: 'vault.example.org'
@ -245,7 +245,7 @@ nginx__servers:
filename: 'debops.bitwarden'
by_role: 'debops.bitwarden'
favicon: False
root: '/usr/share/bitwarden_rs/web-vault'
root: '/usr/share/vaultwarden/web-vault'
location_list:
@ -260,7 +260,7 @@ nginx__servers:
## All the security HTTP headers would then need to be set by nginx as well.
# - pattern: '/ekkP9wtJ_psk_changeme_Hr9CCTud/'
# options: |-
# alias /usr/share/bitwarden_rs/web-vault/;
# alias /usr/share/vaultwarden/web-vault/;
- pattern: '/ekkP9wtJ_psk_changeme_Hr9CCTud/'
options: |-
@ -285,7 +285,7 @@ nginx__servers:
<details>
<summary>Nginx (NixOS)(by tklitschi)</summary><br/>
Example NixOS nginx config. For more Information about NixOS Deployment see [Deployment Wiki page](https://github.com/dani-garcia/bitwarden_rs/wiki/Deployment-examples).
Example NixOS nginx config. For more Information about NixOS Deployment see [Deployment Wiki page](https://github.com/dani-garcia/vaultwarden/wiki/Deployment-examples).
```nix
@ -296,7 +296,7 @@ Example NixOS nginx config. For more Information about NixOS Deployment see [Dep
security.acme.certs = {
"bw.example.com" = {
group = "bitwarden_rs";
group = "vaultwarden";
keyType = "rsa2048";
allowKeysForGroup = true;
};
@ -474,20 +474,20 @@ labels:
Add these lines to your haproxy configuration.
```haproxy
frontend bitwarden_rs
frontend vaultwarden
bind 0.0.0.0:80
option forwardfor header X-Real-IP
http-request set-header X-Real-IP %[src]
default_backend bitwarden_rs_http
use_backend bitwarden_rs_ws if { path_beg /notifications/hub } !{ path_beg /notifications/hub/negotiate }
default_backend vaultwarden_http
use_backend vaultwarden_ws if { path_beg /notifications/hub } !{ path_beg /notifications/hub/negotiate }
backend bitwarden_rs_http
backend vaultwarden_http
# Enable compression if you want
# compression algo gzip
# compression type text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript
server bwrshttp 0.0.0.0:8080
backend bitwarden_rs_ws
backend vaultwarden_ws
server bwrsws 0.0.0.0:3012
```
</details>
@ -515,17 +515,17 @@ frontend http-in
acl host_bitwarden_domain_tld hdr_dom(Host) -i bitwarden.domain.tld
## figure out which one to use
use_backend bitwarden_rs_http if host_bitwarden_domain_tld !{ path_beg /notifications/hub } or { path_beg /notifications/hub/negotiate }
use_backend bitwarden_rs_ws if host_bitwarden_domain_tld { path_beg /notifications/hub } !{ path_beg /notifications/hub/negotiate }
use_backend vaultwarden_http if host_bitwarden_domain_tld !{ path_beg /notifications/hub } or { path_beg /notifications/hub/negotiate }
use_backend vaultwarden_ws if host_bitwarden_domain_tld { path_beg /notifications/hub } !{ path_beg /notifications/hub/negotiate }
backend bitwarden_rs_http
backend vaultwarden_http
# Enable compression if you want
# compression algo gzip
# compression type text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript
# You can use the container hostname if you are using haproxy with docker-compose
server bwrs_http 0.0.0.0:8080
backend bitwarden_rs_ws
backend vaultwarden_ws
# You can use the container hostname if you are using haproxy with docker-compose
server bwrs_ws 0.0.0.0:3012
```

24
Running-a-private-bitwarden_rs-instance-with-Let's-Encrypt-certs.md → Running-a-private-vaultwarden-instance-with-Let's-Encrypt-certs.md

@ -1,13 +1,13 @@
Suppose you want to run an instance of bitwarden_rs that can only be accessed from your local network, but you want your instance to be HTTPS-enabled with certs signed by a widely-accepted CA instead of managing your own [private CA](https://github.com/dani-garcia/bitwarden_rs/wiki/Private-CA-and-self-signed-certs-that-work-with-Chrome) (to avoid the hassle of having to load private CA certs into all of your devices).
Suppose you want to run an instance of vaultwarden that can only be accessed from your local network, but you want your instance to be HTTPS-enabled with certs signed by a widely-accepted CA instead of managing your own [private CA](https://github.com/dani-garcia/vaultwarden/wiki/Private-CA-and-self-signed-certs-that-work-with-Chrome) (to avoid the hassle of having to load private CA certs into all of your devices).
This article demonstrates how to create such a setup using the [Caddy](https://caddyserver.com/) web server, which has built-in ACME support for various DNS providers. We'll configure Caddy to obtain Let's Encrypt certs via the ACME [DNS challenge](https://letsencrypt.org/docs/challenge-types/#dns-01-challenge) -- using the more common HTTP challenge would be problematic here, since it would rely on Let's Encrypt servers being able to reach your internal web server.
(Note that this article covers the DNS challenge setup in more generic terms, but many users will probably find it easiest to use Docker Compose to integrate Caddy and bitwarden_rs. See [Using Docker Compose](https://github.com/dani-garcia/bitwarden_rs/wiki/Using-Docker-Compose#caddy-with-dns-challenge) for an example specific to that.)
(Note that this article covers the DNS challenge setup in more generic terms, but many users will probably find it easiest to use Docker Compose to integrate Caddy and vaultwarden. See [Using Docker Compose](https://github.com/dani-garcia/vaultwarden/wiki/Using-Docker-Compose#caddy-with-dns-challenge) for an example specific to that.)
Two DNS providers are covered:
* [Duck DNS](https://www.duckdns.org/) -- This gives you a subdomain under `duckdns.org` (e.g., `my-bwrs.duckdns.org`). This option is simplest if you don't already own a domain.
* [Cloudflare](https://www.cloudflare.com/) -- This lets you put your bitwarden_rs instance under a domain you own or control. Note that Cloudflare can be used as just a DNS provider (i.e., without the proxying functionality that Cloudflare is best known for). If you don't currently own a domain, you may be able to get a free one at [Freenom](https://www.freenom.com/).
* [Cloudflare](https://www.cloudflare.com/) -- This lets you put your vaultwarden instance under a domain you own or control. Note that Cloudflare can be used as just a DNS provider (i.e., without the proxying functionality that Cloudflare is best known for). If you don't currently own a domain, you may be able to get a free one at [Freenom](https://www.freenom.com/).
It's certainly possible to create a similar setup using other combinations of web server, [ACME client](https://letsencrypt.org/docs/client-options/), and DNS provider, but you'll have to work out the differences in details.
@ -25,7 +25,7 @@ Move the `caddy` binary to `/usr/local/bin/caddy` or some other appropriate dire
## Duck DNS setup
If you don't already have an account, create one at https://www.duckdns.org/. Create a subdomain for your bitwarden_rs instance (e.g., `my-bwrs.duckdns.org`), setting its IP to your bitwarden_rs host's private IP (e.g., `192.168.1.100`). Make note of your account's token (a string in [UUID](https://en.wikipedia.org/wiki/UUID) format). Caddy will need this token to solve the DNS challenge.
If you don't already have an account, create one at https://www.duckdns.org/. Create a subdomain for your vaultwarden instance (e.g., `my-bwrs.duckdns.org`), setting its IP to your vaultwarden host's private IP (e.g., `192.168.1.100`). Make note of your account's token (a string in [UUID](https://en.wikipedia.org/wiki/UUID) format). Caddy will need this token to solve the DNS challenge.
Create a file named `Caddyfile` with the following content:
```
@ -49,19 +49,19 @@ Start `caddy` by running
caddy run -envfile caddy.env
```
Start `bitwarden_rs` by running
Start `vaultwarden` by running
```
export ROCKET_PORT=8080
export WEBSOCKET_ENABLED=true
./bitwarden_rs
./vaultwarden
```
You should now be able to reach your bitwarden_rs instance at https://my-bwrs.duckdns.org.
You should now be able to reach your vaultwarden instance at https://my-bwrs.duckdns.org.
## Cloudflare setup
If you don't already have an account, create one at https://www.cloudflare.com/; you'll also have to go to your domain registrar to set your nameservers to the ones assigned to you by Cloudflare. Create a subdomain for your bitwarden_rs instance (e.g., `bwrs.example.com`), setting its IP to your bitwarden_rs host's private IP (e.g., `192.168.1.100`). For example:
If you don't already have an account, create one at https://www.cloudflare.com/; you'll also have to go to your domain registrar to set your nameservers to the ones assigned to you by Cloudflare. Create a subdomain for your vaultwarden instance (e.g., `bwrs.example.com`), setting its IP to your vaultwarden host's private IP (e.g., `192.168.1.100`). For example:
![A record config](https://i.imgur.com/BBvy4Yj.png)
@ -101,15 +101,15 @@ Start `caddy` by running
caddy run -envfile caddy.env
```
Start `bitwarden_rs` by running
Start `vaultwarden` by running
```
export ROCKET_PORT=8080
export WEBSOCKET_ENABLED=true
./bitwarden_rs
./vaultwarden
```
You should now be able to reach your bitwarden_rs instance at https://bwrs.example.com.
You should now be able to reach your vaultwarden instance at https://bwrs.example.com.
## Getting certs using the `lego` CLI
@ -126,7 +126,7 @@ Here's an example of how to do this:
3. Set up a weekly cron job to run `DUCKDNS_TOKEN=<token> ./lego --dns duckdns -d my-bwrs.duckdns.org -m me@example.com renew`.
This renews your certificate as it nears expiration.
(Note: `lego` requests ECC/ECDSA certs by default. If you are using the [[Rocket HTTPS server|Enabling-HTTPS#via-rocket]] built into bitwarden_rs, you will need to request RSA certs instead. In the `lego` commands above, add the option `--key-type rsa2048`.)
(Note: `lego` requests ECC/ECDSA certs by default. If you are using the [[Rocket HTTPS server|Enabling-HTTPS#via-rocket]] built into vaultwarden, you will need to request RSA certs instead. In the `lego` commands above, add the option `--key-type rsa2048`.)
In this example, the generated outputs you need to configure your reverse proxy with are:

4
Running-docker-container-with-non-root-user.md

@ -1,4 +1,4 @@
By default `bitwardenrs/server` is using root user to run service inside the container. There are few things you need to set to run the container as non-root user if you wish to do so:
By default `vaultwarden/server` is using root user to run service inside the container. There are few things you need to set to run the container as non-root user if you wish to do so:
1. Make sure that the directory, you're mounting inside the container will be writable by the user. For example if you decide to run as `nobody`, the directory needs to be writable by user with id 65534. For other ways to specify user inside the container, see the [docker documentation](https://docs.docker.com/engine/reference/run/#user), in our examples here we will use `nobody`.
@ -23,7 +23,7 @@ docker run -d \
-e ROCKET_PORT=1024 \
-v /bw-data/:/data/ \
-p 80:1024 \
bitwardenrs/server:latest
vaultwarden/server:latest
```
Notice that the port mapping (`-p 80:1024`) reflects the `ROCKET_PORT` setting.

6
Running-with-systemd-docker.md

@ -15,7 +15,7 @@ Requires=docker.service
[Service]
TimeoutStartSec=0
ExecStartPre=-/usr/bin/docker pull bitwardenrs/server:latest
ExecStartPre=-/usr/bin/docker pull vaultwarden/server:latest
ExecStartPre=-/usr/bin/docker stop bitwarden
ExecStartPre=-/usr/bin/docker rm bitwarden
ExecStart=/usr/bin/docker run \
@ -23,7 +23,7 @@ ExecStart=/usr/bin/docker run \
-p 8081:3012 \
--env-file /opt/.bitwarden.env \
-v /opt/bw-data:/data/ \
--rm --name bitwarden bitwardenrs/server:latest
--rm --name bitwarden vaultwarden/server:latest
ExecStopPost=-/usr/bin/docker rm bitwarden
Restart=Always
RestartSec=30s
@ -64,7 +64,7 @@ Systemd can source a file of the form:
```shell
Key="Value"
```
You can find more environment settings and the correct syntax in this [example env template](https://github.com/dani-garcia/bitwarden_rs/blob/21325b7523a68ab3ae8d435ab5b73176db6155ff/.env.template).
You can find more environment settings and the correct syntax in this [example env template](https://github.com/dani-garcia/vaultwarden/blob/21325b7523a68ab3ae8d435ab5b73176db6155ff/.env.template).
However, the systemd project does not mandate where this file should be stored. Consult your distribution's documentation for the
best location for this file. For example, RedHat based distributions typically place these files in `/etc/sysconfig/`

20
Running-without-WAL-enabled.md

@ -1,6 +1,6 @@
> WAL is an SQLite only setting and has no effect with Postgres or MySQL.
By default during the startup `bitwarden_rs` will try to enable [WAL](https://sqlite.org/wal.html) for the DB. Adding this improves performance and in the past helped preventing failed requests under some circumstances.
By default during the startup `vaultwarden` will try to enable [WAL](https://sqlite.org/wal.html) for the DB. Adding this improves performance and in the past helped preventing failed requests under some circumstances.
## Reasons to turn WAL off
@ -8,21 +8,21 @@ Generally speaking unless you're absolutely sure, that you need to turn WAL off,
* Some filesystems don't support WAL - this is especially true for network filesystems. If you're using such filesystem, the service will fail to start with `Failed to turn on WAL` error message.
* The database requires sqlite version `3.7.0` or newer, so if you for any reason (for example backups) require to access the DB directly with some other tool that cannot be updated, you might need to disable WAL.
* You are [using the MySQL backend](https://github.com/dani-garcia/bitwarden_rs/wiki/Using-the-MySQL-Backend)
* You are [using the PostgreSQL backend](https://github.com/dani-garcia/bitwarden_rs/wiki/Using-the-PostgreSQL-Backend)
* You are [using the MySQL backend](https://github.com/dani-garcia/vaultwarden/wiki/Using-the-MySQL-Backend)
* You are [using the PostgreSQL backend](https://github.com/dani-garcia/vaultwarden/wiki/Using-the-PostgreSQL-Backend)
* One of the [disadvantages described here](https://sqlite.org/wal.html#advantages) affects you
## How to turn WAL off
### 0. Make backup
These changes are generally safe and can be done without data loss, however [backing up your data](https://github.com/dani-garcia/bitwarden_rs/wiki/Backing-up-your-vault) prior to any changes is strongly advised.
These changes are generally safe and can be done without data loss, however [backing up your data](https://github.com/dani-garcia/vaultwarden/wiki/Backing-up-your-vault) prior to any changes is strongly advised.
### 1. Disable WAL on old DB
If you have old DB, that was used with WAL enabled, you need to disable it using sqlite:
1. Stop `bitwarden_rs`
2. Locate your [data folder](https://github.com/dani-garcia/bitwarden_rs/wiki/Changing-persistent-data-location). Normally there will be `db.sqlite3` file there unless you specified some other name to use.
1. Stop `vaultwarden`
2. Locate your [data folder](https://github.com/dani-garcia/vaultwarden/wiki/Changing-persistent-data-location). Normally there will be `db.sqlite3` file there unless you specified some other name to use.
3. Open the file using sqlite:
```bash
@ -36,16 +36,16 @@ delete
```
5. Quit sqlite utility by typing `.quit` and pressing enter. (notice the dot at the beginning)
### 2. Disable WAL in `bitwarden_rs`
### 2. Disable WAL in `vaultwarden`
To turn WAL off, you need to start `bitwarden_rs` with `ENABLE_DB_WAL` variable set to `false`:
To turn WAL off, you need to start `vaultwarden` with `ENABLE_DB_WAL` variable set to `false`:
```bash
docker run -d --name bitwarden \
-e ENABLE_DB_WAL=false \
-v /bw-data/:/data/ \
-p 80:80 \
bitwardenrs/server:latest
vaultwarden/server:latest
```
Make sure to always start with this variable present as starting even once without it will enable WAL again. (if that happens start at the [first step](#1-disable-wal-on-old-db) to disable it again)
@ -57,4 +57,4 @@ Generally speaking you just start `bitarden_rs` without `ENABLE_DB_WAL` set to f
sqlite3 db.sqlite3 'PRAGMA journal_mode'
```
Where `db.sqlite3` is the DB file used by `bitwarden_rs`. It should return back the mode that is currently used, so in our case it's `wal`. Disabled WAL will typically report back `delete` as this is the default.
Where `db.sqlite3` is the DB file used by `vaultwarden`. It should return back the mode that is currently used, so in our case it's `wal`. Disabled WAL will typically report back `delete` as this is the default.

8
SMTP-configuration.md

@ -1,4 +1,4 @@
You can configure bitwarden_rs to send emails via a SMTP agent:
You can configure vaultwarden to send emails via a SMTP agent:
```sh
docker run -d --name bitwarden \
@ -10,12 +10,12 @@ docker run -d --name bitwarden \
-e SMTP_PASSWORD=<password> \
-v /bw-data/:/data/ \
-p 80:80 \
bitwardenrs/server:latest
vaultwarden/server:latest
```
When `SMTP_SSL` is set to `true`(this is the default), only TLSv1.1 and TLSv1.2 protocols will be accepted and `SMTP_PORT` will default to `587`. If set to `false`, `SMTP_PORT` will default to `25` and the opportunistic encryption will be tried (no encryption attempted with code prior to 3/12/2020). This can be very insecure, use this setting only if you know what you're doing. To run SMTP in explicit mode, set `SMTP_EXPLICIT_TLS` to `true`. If you can send emails without logging in, you can simply not set `SMTP_USERNAME` and `SMTP_PASSWORD`.
Note that if SMTP and invitations are enabled, invitations will be sent to new users via email. You must set the `DOMAIN` configuration option with the base URL of your bitwarden_rs instance for the invite link to be generated correctly:
Note that if SMTP and invitations are enabled, invitations will be sent to new users via email. You must set the `DOMAIN` configuration option with the base URL of your vaultwarden instance for the invite link to be generated correctly:
```sh
docker run -d --name bitwarden \
@ -28,7 +28,7 @@ User invitation links are valid for 5 days, after which a new invitation will ne
## SMTP servers
Properly configuring an SMTP server/relay isn't trivial. The mailer library that bitwarden_rs uses also isn't the easiest to troubleshoot. So unless you're particularly interested in setting this up yourself, it's probably easier to use an external service.
Properly configuring an SMTP server/relay isn't trivial. The mailer library that vaultwarden uses also isn't the easiest to troubleshoot. So unless you're particularly interested in setting this up yourself, it's probably easier to use an external service.
Here are a few services with a free tier that allows sending 100-200 emails per day (which is plenty for most use cases):

68
Setup-as-a-systemd-service.md

@ -1,15 +1,15 @@
These instructions require you to have [[compiled the bitwarden_rs binary|Building-binary]]. If you generated a docker image, you may want to look at [[Running with systemd-docker | Running-with-systemd-docker]]
These instructions require you to have [[compiled the vaultwarden binary|Building-binary]]. If you generated a docker image, you may want to look at [[Running with systemd-docker | Running-with-systemd-docker]]
## Setup
Making bitwarden_rs start on system startup and use the other facilities of systemd (e.g. isolation, logging,...) requires a `.service` file. The following is a usable starting point:
Making vaultwarden start on system startup and use the other facilities of systemd (e.g. isolation, logging,...) requires a `.service` file. The following is a usable starting point:
```ini
[Unit]
Description=Bitwarden Server (Rust Edition)
Documentation=https://github.com/dani-garcia/bitwarden_rs
Documentation=https://github.com/dani-garcia/vaultwarden
# If you use a database like mariadb,mysql or postgresql,
# you have to add them like the following and uncomment them
# by removing the `# ` before it. This makes sure that your
# database server is started before bitwarden_rs ("After") and has
# started successfully before starting bitwarden_rs ("Requires").
# database server is started before vaultwarden ("After") and has
# started successfully before starting vaultwarden ("Requires").
# Only sqlite
After=network.target
@ -28,36 +28,36 @@ After=network.target
[Service]
# The user/group bitwarden_rs is run under. the working directory (see below) should allow write and read access to this user/group
User=bitwarden_rs
Group=bitwarden_rs
# The user/group vaultwarden is run under. the working directory (see below) should allow write and read access to this user/group
User=vaultwarden
Group=vaultwarden
# The location of the .env file for configuration
EnvironmentFile=/etc/bitwarden_rs.env
EnvironmentFile=/etc/vaultwarden.env
# The location of the compiled binary
ExecStart=/usr/bin/bitwarden_rs
ExecStart=/usr/bin/vaultwarden
# Set reasonable connection and process limits
LimitNOFILE=1048576
LimitNPROC=64
# Isolate bitwarden_rs from the rest of the system
# Isolate vaultwarden from the rest of the system
PrivateTmp=true
PrivateDevices=true
ProtectHome=true
ProtectSystem=strict
# Only allow writes to the following directory and set it to the working directory (user and password data are stored here)
WorkingDirectory=/var/lib/bitwarden_rs
ReadWriteDirectories=/var/lib/bitwarden_rs
# Allow bitwarden_rs to bind ports in the range of 0-1024
WorkingDirectory=/var/lib/vaultwarden
ReadWriteDirectories=/var/lib/vaultwarden
# Allow vaultwarden to bind ports in the range of 0-1024
AmbientCapabilities=CAP_NET_BIND_SERVICE
[Install]
WantedBy=multi-user.target
```
Change all paths to match your installation (`WorkingDirectory` and `ReadWriteDirectory` should be the same),
name this file `bitwarden_rs.service` and put it into `/etc/systemd/system`.
name this file `vaultwarden.service` and put it into `/etc/systemd/system`.
If you have to change an existing systemd file (which was provided to you by the package you installed), you can add your changes by using
```
$ sudo systemctl edit bitwarden_rs.service
$ sudo systemctl edit vaultwarden.service
```
To make systemd aware of your new file or any changes you made, run
```
@ -66,23 +66,23 @@ $ sudo systemctl daemon-reload
## Usage
To start this "service", run
```
$ sudo systemctl start bitwarden_rs.service
$ sudo systemctl start vaultwarden.service
```
To enable autostart, run
```
$ sudo systemctl enable bitwarden_rs.service
$ sudo systemctl enable vaultwarden.service
```
In the same way you can `stop`, `restart` and `disable` the service.
### Updating bitwarden_rs
After compiling the new version of bitwarden_rs, you can copy the compiled (new) binary and replace the existing (old) binary and then restart the service:
### Updating vaultwarden
After compiling the new version of vaultwarden, you can copy the compiled (new) binary and replace the existing (old) binary and then restart the service:
```
$ sudo systemctl restart bitwarden_rs.service
$ sudo systemctl restart vaultwarden.service
```
### Uninstalling bitwarden_rs
### Uninstalling vaultwarden
Before doing anything else, you should stop and disable the service:
```
$ sudo systemctl disable --now bitwarden_rs.service
$ sudo systemctl disable --now vaultwarden.service
```
Then you can delete the binary, the `.env` file, the web-vault folder (if installed) and the user data (if necessary). Remember to also remove specially created users,groups and firewall rules (if needed) and the systemd file.
@ -94,19 +94,19 @@ $ sudo systemctl daemon-reload
### Logging and status view
If you want to see the logging output, run
```
$ journalctl -u bitwarden_rs.service
$ journalctl -u vaultwarden.service
```
or to see a more concise state of the service, run
```
$ systemctl status bitwarden_rs.service
$ systemctl status vaultwarden.service
```
## Troubleshooting
### Sandboxing options with older systemd versions
In RHEL 7 (and debian 8), the used systemd does not support some of the used isolation options. ([#445](https://github.com/dani-garcia/bitwarden_rs/issues/445),[#363](https://github.com/dani-garcia/bitwarden_rs/issues/363))
In RHEL 7 (and debian 8), the used systemd does not support some of the used isolation options. ([#445](https://github.com/dani-garcia/vaultwarden/issues/445),[#363](https://github.com/dani-garcia/vaultwarden/issues/363))
This can result in one of the following errors:
```
Failed at step NAMESPACE spawning /home/bitwarden_rs/bitwarden_rs: Permission denied
Failed at step NAMESPACE spawning /home/vaultwarden/vaultwarden: Permission denied
```
or
```
@ -127,21 +127,21 @@ before (re-)starting your service.
### Service fails to start
The following error shows in the systemd journal (`journalctl -eu bitwarden_rs.service`):
The following error shows in the systemd journal (`journalctl -eu vaultwarden.service`):
```
Feb 18 05:29:10 staging-bitwarden systemd[1]: Started Bitwarden Server (Rust Edition).
Feb 18 05:29:10 staging-bitwarden systemd[49506]: bitwarden_rs.service: Failed to execute command: Resource temporarily unavailable
Feb 18 05:29:10 staging-bitwarden systemd[49506]: bitwarden_rs.service: Failed at step EXEC spawning /usr/bin/bitwarden_rs: Resource temporarily unavailable
Feb 18 05:29:10 staging-bitwarden systemd[1]: bitwarden_rs.service: Main process exited, code=exited, status=203/EXEC
Feb 18 05:29:10 staging-bitwarden systemd[1]: bitwarden_rs.service: Failed with result 'exit-code'.
Feb 18 05:29:10 staging-bitwarden systemd[49506]: vaultwarden.service: Failed to execute command: Resource temporarily unavailable
Feb 18 05:29:10 staging-bitwarden systemd[49506]: vaultwarden.service: Failed at step EXEC spawning /usr/bin/vaultwarden: Resource temporarily unavailable
Feb 18 05:29:10 staging-bitwarden systemd[1]: vaultwarden.service: Main process exited, code=exited, status=203/EXEC
Feb 18 05:29:10 staging-bitwarden systemd[1]: vaultwarden.service: Failed with result 'exit-code'.
```
This is known to occur when bitwarden_rs is running inside a container (LXC, et al) or natively. The parameter `LimitNPROC=64` in the service file prevents the service from starting. Commenting out that particular parameter results in the service starting correctly.
This is known to occur when vaultwarden is running inside a container (LXC, et al) or natively. The parameter `LimitNPROC=64` in the service file prevents the service from starting. Commenting out that particular parameter results in the service starting correctly.
**Note**: A systemd override file will not work, the line must be commented out/removed. The easiest way to do this is via
```
# systemctl edit --full bitwarden_rs.service
# systemctl edit --full vaultwarden.service
```
then reloading the daemon & restarting.

14
Starting-a-Container.md

@ -6,11 +6,11 @@ The persistent data is stored under /data inside the container, so the only requ
```sh
# using Docker:
docker run -d --name bitwarden -v /bw-data/:/data/ -p 80:80 bitwardenrs/server:latest
docker run -d --name bitwarden -v /bw-data/:/data/ -p 80:80 vaultwarden/server:latest
# using Podman as non-root:
podman run -d --name bitwarden -v /bw-data/:/data/:Z -e ROCKET_PORT=8080 -p 8080:8080 bitwardenrs/server:latest
podman run -d --name bitwarden -v /bw-data/:/data/:Z -e ROCKET_PORT=8080 -p 8080:8080 vaultwarden/server:latest
# using Podman as root:
sudo podman run -d --name bitwarden -v bw-data:/data/:Z -p 80:80 bitwardenrs/server:latest
sudo podman run -d --name bitwarden -v bw-data:/data/:Z -p 80:80 vaultwarden/server:latest
```
@ -20,11 +20,11 @@ The service will be exposed on host-port 80 or 8080.
For non-x86 hardware or to run specific version, you can [[choose some other image|Which-container-image-to-use]].
If your docker/bitwarden_rs runs on a device with a fixed IP, you can bind the host-port to that specific IP and hence prevent exposing the host-port to the whole world or network. Add the IP address (e.g. 192.168.0.2) in front of the host-port and container-port as follows:
If your docker/vaultwarden runs on a device with a fixed IP, you can bind the host-port to that specific IP and hence prevent exposing the host-port to the whole world or network. Add the IP address (e.g. 192.168.0.2) in front of the host-port and container-port as follows:
```
# using Docker:
docker run -d --name bitwarden -v /bw-data/:/data/ -p 192.168.0.2:80:80 bitwardenrs/server:latest
docker run -d --name bitwarden -v /bw-data/:/data/ -p 192.168.0.2:80:80 vaultwarden/server:latest
```
# Starting the container
@ -36,7 +36,7 @@ docker start bitwarden
# Customizing container startup
If you have custom startup script(s) you want to run when the container starts, you can mount a single script into the container as `/etc/bitwarden_rs.sh` and/or a directory of scripts as `/etc/bitwarden_rs.d`. In the latter case, only files with an `.sh` extension are run, so files with other extensions (e.g., data/config files) can reside in the same dir. (See [start.sh](https://github.com/dani-garcia/bitwarden_rs/blob/master/docker/start.sh) for details on exactly how it works.)
If you have custom startup script(s) you want to run when the container starts, you can mount a single script into the container as `/etc/vaultwarden.sh` and/or a directory of scripts as `/etc/vaultwarden.d`. In the latter case, only files with an `.sh` extension are run, so files with other extensions (e.g., data/config files) can reside in the same dir. (See [start.sh](https://github.com/dani-garcia/vaultwarden/blob/master/docker/start.sh) for details on exactly how it works.)
A custom startup script can be useful for patching web vault files or installing additional packages, CA certificates, etc. without having to build and maintain your own Docker image.
@ -49,7 +49,7 @@ echo "starting up"
You can run the script on startup like this:
```
docker run -d --name bitwarden -v $(pwd)/init.sh:/etc/bitwarden_rs.sh <other docker args...> bitwardenrs/server:latest
docker run -d --name bitwarden -v $(pwd)/init.sh:/etc/vaultwarden.sh <other docker args...> vaultwarden/server:latest
```
If you run `docker logs bitwarden`, you should now see `starting up` as the first line of the output.

8
Supporting-upstream.md

@ -1,4 +1,4 @@
bitwarden_rs only provides the API (server) side implementation, so users still rely on clients from upstream. (mobile apps, desktop apps and web Vault) This is a lot of work that is done upstream by 8bit Solutions LLC. At the same time bitwarden_rs supports some paid features and offers that functionality for free. This raises some [questions about sustaining and supporting upstream](https://github.com/dani-garcia/bitwarden_rs/issues/331) development. Many users raised this issue and were asking how they can support upstream while using bitwarden_rs.
vaultwarden only provides the API (server) side implementation, so users still rely on clients from upstream. (mobile apps, desktop apps and web Vault) This is a lot of work that is done upstream by 8bit Solutions LLC. At the same time vaultwarden supports some paid features and offers that functionality for free. This raises some [questions about sustaining and supporting upstream](https://github.com/dani-garcia/vaultwarden/issues/331) development. Many users raised this issue and were asking how they can support upstream while using vaultwarden.
## Donating
@ -6,7 +6,7 @@ You can donate directly to the upstream development via [PayPal](https://www.pay
## Buying a licence
Many users just buy appropriate licence for their deployment and leave it unused. It's kind of a donation because bitwarden_rs can't use the licence in any way.
Many users just buy appropriate licence for their deployment and leave it unused. It's kind of a donation because vaultwarden can't use the licence in any way.
## Help translating the apps
@ -14,8 +14,8 @@ There are [projects on Crowdin](https://crowdin.com/profile/kspearrin) for each
## Testing, reporting bugs in clients
**Please, always report any bugs found here first.** Chances are these aren't upstream bugs, but bugs in our implementation or in your configuration. [We don't want to waste Kyle's time](https://github.com/dani-garcia/bitwarden_rs/issues/336) troubleshooting bugs with 3rd party server. In very rare cases there is a bug upstream, but at this stage we would have any other reason ruled out and the bug confirmed on the upstream server. So the takeaway here is to _not_ report bugs in upstream, but report it here instead even if you think it is client issue. We can work together to see where the problem is.
**Please, always report any bugs found here first.** Chances are these aren't upstream bugs, but bugs in our implementation or in your configuration. [We don't want to waste Kyle's time](https://github.com/dani-garcia/vaultwarden/issues/336) troubleshooting bugs with 3rd party server. In very rare cases there is a bug upstream, but at this stage we would have any other reason ruled out and the bug confirmed on the upstream server. So the takeaway here is to _not_ report bugs in upstream, but report it here instead even if you think it is client issue. We can work together to see where the problem is.
## Helping other users in the community
There are lot of new users that sometimes struggle with basic stuff. Helping them is a great way to support the project. (and to grow the community) From my experience with community around bitwarden_rs, it's great to see people actually helping each other before I get to answer their question - it saves some time and I often end up learning something new. There's [Bitwarden community on Reddit](https://www.reddit.com/r/bitwarden) for example, there are also [official forums](https://community.bitwarden.com/).
There are lot of new users that sometimes struggle with basic stuff. Helping them is a great way to support the project. (and to grow the community) From my experience with community around vaultwarden, it's great to see people actually helping each other before I get to answer their question - it saves some time and I often end up learning something new. There's [Bitwarden community on Reddit](https://www.reddit.com/r/bitwarden) for example, there are also [official forums](https://community.bitwarden.com/).

8
Syncing-users-from-LDAP.md

@ -1,9 +1,9 @@
LDAP integration is performed using a small service that queries LDAP and invites users to your Bitwarden instance. This service is uncreatively named [bitwarden_rs_ldap](https://github.com/ViViDboarder/bitwarden_rs_ldap).
LDAP integration is performed using a small service that queries LDAP and invites users to your Vaultwarden instance. This service is uncreatively named [bitwarden_rs_ldap](https://github.com/ViViDboarder/bitwarden_rs_ldap).
It is not yet distributed as a binary, but there is an available Docker image [vividboarder/bitwarden_rs_ldap](https://hub.docker.com/r/vividboarder/bitwarden_rs_ldap).
Before deploying, you must [[enable your bitwarden_rs admin page|Enabling-admin-page]]. This enables the API that the LDAP sync service will use to invite users. The `ADMIN_TOKEN` that you set will be used when configuring the LDAP sync service. You must also be sure to **not** disable the invitation capability. To verify this, double check that the environment variable `INVITATIONS_ALLOWED` is not set to `false`.
Before deploying, you must [[enable your vaultwarden admin page|Enabling-admin-page]]. This enables the API that the LDAP sync service will use to invite users. The `ADMIN_TOKEN` that you set will be used when configuring the LDAP sync service. You must also be sure to **not** disable the invitation capability. To verify this, double check that the environment variable `INVITATIONS_ALLOWED` is not set to `false`.
It is also recommended to [[enable email sending|SMTP-configuration]] from your Bitwarden instance so that your users will be notified they can make an account. If you do not, they will still be able to register if they use their LDAP email address, but you will have to inform them on your own.
It is also recommended to [[enable email sending|SMTP-configuration]] from your Vaultwarden instance so that your users will be notified they can make an account. If you do not, they will still be able to register if they use their LDAP email address, but you will have to inform them on your own.
With these steps done, you can configure and deploy the LDAP sync service. The most up-to-date instructions are to be found on the service [Readme](https://github.com/ViViDboarder/bitwarden_rs_ldap) itself, but it will involve creating the `config.toml` file with the connection info for your bitwarden_rs instance, your LDAP instance, as well as the LDAP query you'd like to use to find users.
With these steps done, you can configure and deploy the LDAP sync service. The most up-to-date instructions are to be found on the service [Readme](https://github.com/ViViDboarder/bitwarden_rs_ldap) itself, but it will involve creating the `config.toml` file with the connection info for your Vaultwarden instance, your LDAP instance, as well as the LDAP query you'd like to use to find users.

2
Third-party-packages.md

@ -1,4 +1,4 @@
This page is an index of third-party bitwarden_rs packages. As these packages are not maintained or controlled by bitwarden_rs, they can lag behind official releases, sometimes significantly. If you rely on these packages, you might want to [enable watching](https://docs.github.com/en/github/managing-subscriptions-and-notifications-on-github/viewing-your-subscriptions#configuring-your-watch-settings-for-an-individual-repository) for new bitwarden_rs releases and let the maintainer know if the package isn't being kept up to date.
This page is an index of third-party vaultwarden packages. As these packages are not maintained or controlled by vaultwarden, they can lag behind official releases, sometimes significantly. If you rely on these packages, you might want to [enable watching](https://docs.github.com/en/github/managing-subscriptions-and-notifications-on-github/viewing-your-subscriptions#configuring-your-watch-settings-for-an-individual-repository) for new vaultwarden releases and let the maintainer know if the package isn't being kept up to date.
## Arch Linux

10
Updating-the-bitwarden-image.md → Updating-the-vaultwarden-image.md

@ -2,14 +2,14 @@ Updating is straightforward, you just make sure to preserve the mounted volume.
```sh
# Pull the latest version
docker pull bitwardenrs/server:latest
docker pull vaultwarden/server:latest
# Stop and remove the old container
docker stop bitwarden
docker rm bitwarden
# Start new container with the data mounted
docker run -d --name bitwarden -v /bw-data/:/data/ -p 80:80 bitwardenrs/server:latest
docker run -d --name bitwarden -v /bw-data/:/data/ -p 80:80 vaultwarden/server:latest
```
Then visit [http://localhost:80](http://localhost:80)
@ -17,7 +17,7 @@ In case you didn't bind mount the volume for persistent data, you need an interm
```sh
# Pull the latest version
docker pull bitwardenrs/server:latest
docker pull vaultwarden/server:latest
# Create intermediate container to preserve data
docker run --volumes-from bitwarden --name bitwarden_data busybox true
@ -27,7 +27,7 @@ docker stop bitwarden
docker rm bitwarden
# Start new container with the data mounted
docker run -d --volumes-from bitwarden_data --name bitwarden -p 80:80 bitwardenrs/server:latest
docker run -d --volumes-from bitwarden_data --name bitwarden -p 80:80 vaultwarden/server:latest
# Optionally remove the intermediate container
docker rm bitwarden_data
@ -50,7 +50,7 @@ docker-compose start
```sh
sudo systemctl restart bitwarden.service
sudo docker system prune -f
#WARNING this could delete stopped or unused containers, etc. not associated with bitwarden_rs
#WARNING this could delete stopped or unused containers, etc. not associated with vaultwarden
#be carefull and look which containers you need
docker ps -a

14
Using-Docker-Compose.md

@ -1,8 +1,8 @@
[Docker Compose](https://docs.docker.com/compose/) is a tool that allows the definition and configuration of multi-container applications. In our case, we want both the bitwarden_rs server and a proxy to redirect the WebSocket requests to the correct place.
[Docker Compose](https://docs.docker.com/compose/) is a tool that allows the definition and configuration of multi-container applications. In our case, we want both the vaultwarden server and a proxy to redirect the WebSocket requests to the correct place.
## Caddy with HTTP challenge
This example assumes that you have [installed](https://docs.docker.com/compose/install/) Docker Compose, that you have a domain name (e.g., `bitwarden.example.com`) for your bitwarden_rs instance, and that it will be publicly accessible.
This example assumes that you have [installed](https://docs.docker.com/compose/install/) Docker Compose, that you have a domain name (e.g., `bitwarden.example.com`) for your vaultwarden instance, and that it will be publicly accessible.
Start by making a new directory and changing into it. Next, create the `docker-compose.yml` below, making sure to substitute appropriate values for the `DOMAIN` and `EMAIL` variables.
@ -11,7 +11,7 @@ version: '3'
services:
bitwarden:
image: bitwardenrs/server:latest
image: vaultwarden/server:latest
container_name: bitwarden
restart: always
environment:
@ -60,7 +60,7 @@ In the same directory, create the `Caddyfile` below. (This file does not need to
# Proxy everything else to Rocket
reverse_proxy bitwarden:80 {
# Send the true remote IP to Rocket, so that bitwarden_rs can put this in the
# Send the true remote IP to Rocket, so that vaultwarden can put this in the
# log, so that fail2ban can ban the correct IP.
header_up X-Real-IP {remote_host}
}
@ -82,7 +82,7 @@ A similar Caddy-based example for Synology is available [here](https://github.co
## Caddy with DNS challenge
This example is the same as the previous one, but for the case where you don't want your instance to be publicly accessible (i.e., you can access it only from your local network). This example uses Duck DNS as the DNS provider. Refer to [[Running a private bitwarden_rs instance with Let's Encrypt certs|Running-a-private-bitwarden_rs-instance-with-Let's-Encrypt-certs]] for more background, and details on how to set up Duck DNS.
This example is the same as the previous one, but for the case where you don't want your instance to be publicly accessible (i.e., you can access it only from your local network). This example uses Duck DNS as the DNS provider. Refer to [[Running a private vaultwarden instance with Let's Encrypt certs|Running-a-private-vaultwarden-instance-with-Let's-Encrypt-certs]] for more background, and details on how to set up Duck DNS.
Start by making a new directory and changing into it. Next, create the `docker-compose.yml` below, making sure to substitute appropriate values for the `DOMAIN` and `EMAIL` variables.
@ -91,7 +91,7 @@ version: '3'
services:
bitwarden:
image: bitwardenrs/server:latest
image: vaultwarden/server:latest
container_name: bitwarden
restart: always
environment:
@ -118,7 +118,7 @@ services:
- LOG_FILE=/data/access.log
```
The stock Caddy builds (including the one in the Docker image) don't include the DNS challenge modules, so next you'll need to [get a custom Caddy build](https://github.com/dani-garcia/bitwarden_rs/wiki/Running-a-private-bitwarden_rs-instance-with-Let%27s-Encrypt-certs#getting-a-custom-caddy-build). Rename the custom build as `caddy` and move it under the same directory as `docker-compose.yml`. Make sure the `caddy` file is executable (e.g., `chmod a+x caddy`). The `docker-compose.yml` file above bind-mounts the custom build into the `caddy:2` container, replacing the stock build.
The stock Caddy builds (including the one in the Docker image) don't include the DNS challenge modules, so next you'll need to [get a custom Caddy build](https://github.com/dani-garcia/vaultwarden/wiki/Running-a-private-vaultwarden-instance-with-Let%27s-Encrypt-certs#getting-a-custom-caddy-build). Rename the custom build as `caddy` and move it under the same directory as `docker-compose.yml`. Make sure the `caddy` file is executable (e.g., `chmod a+x caddy`). The `docker-compose.yml` file above bind-mounts the custom build into the `caddy:2` container, replacing the stock build.
In the same directory, create the `Caddyfile` below. (This file does not need to be modified.)
```

4
Using-Podman.md

@ -3,7 +3,7 @@
# Creating a systemd service file
Podman is easier to run in systemd than Docker due to its daemonless architechture. It comes with a handy [generate systemd command](http://docs.podman.io/en/latest/markdown/podman-generate-systemd.1.html) which can generate systemd files. Here is a [good article that goes into more detail](https://www.redhat.com/sysadmin/podman-shareable-systemd-services) as well as [this article detailing some more recent updates](https://www.redhat.com/sysadmin/improved-systemd-podman).
```sh
$ podman run -d --name bitwarden -v /bw-data/:/data/:Z -e ROCKET_PORT=8080 -p 8080:8080 bitwardenrs/server:latest
$ podman run -d --name bitwarden -v /bw-data/:/data/:Z -e ROCKET_PORT=8080 -p 8080:8080 vaultwarden/server:latest
54502f309f3092d32b4c496ef3d099b270b2af7b5464e7cb4887bc16a4d38597
$ podman generate systemd --name bitwarden
# container-foo.service
@ -41,7 +41,7 @@ Description=Podman container-bitwarden.service
[Service]
Restart=on-failure
ExecStartPre=/usr/bin/rm -f /%t/%n-pid /%t/%n-cid
ExecStart=/usr/bin/podman run --conmon-pidfile /%t/%n-pid --cidfile /%t/%n-cid --env-file=/home/spytec/Bitwarden/bitwarden.conf -d -p 8080:8080 -v /home/spytec/Bitwarden/bw-data:/data/:Z bitwardenrs/server:latest
ExecStart=/usr/bin/podman run --conmon-pidfile /%t/%n-pid --cidfile /%t/%n-cid --env-file=/home/spytec/Bitwarden/bitwarden.conf -d -p 8080:8080 -v /home/spytec/Bitwarden/bw-data:/data/:Z vaultwarden/server:latest
ExecStop=/usr/bin/podman stop -t "15" --cidfile /%t/%n-cid
ExecStop=/usr/bin/podman rm -f --cidfile /%t/%n-cid
KillMode=none

12
Using-an-alternate-base-dir.md

@ -2,25 +2,25 @@ Traditionally, Bitwarden is limited to residing at the root of a subdomain, e.g.
This limitation originates in the backend and web vault, which haven't been designed to accommodate alternate base dirs (see [bitwarden/server#277](/bitwarden/server/issues/277)). The mobile/desktop apps and browser extensions actually have no issues using a base URL with a path.
In bitwarden_rs, with the changes in [PR#868](https://github.com/dani-garcia/bitwarden_rs/pull/868) (backend) and [PR#11](https://github.com/dani-garcia/bw_web_builds/pull/11) (web vault), you can configure a fully functional instance at an alternate base dir.
In vaultwarden, with the changes in [PR#868](https://github.com/dani-garcia/vaultwarden/pull/868) (backend) and [PR#11](https://github.com/dani-garcia/bw_web_builds/pull/11) (web vault), you can configure a fully functional instance at an alternate base dir.
## Configuration
Simply configure your domain URL to include the base dir. For example, suppose you want to access your instance at `https://bitwarden.example.com/base-dir`. (Note that you can also use multiple levels of directories, like `https://bitwarden.example.com/multi/level/base/dir`if you want.)
1. Stop bitwarden_rs.
2. If you normally configure bitwarden_rs using the admin page, edit your `config.json` to look as follows:
1. Stop vaultwarden.
2. If you normally configure vaultwarden using the admin page, edit your `config.json` to look as follows:
```javascript
{
"domain": "https://bitwarden.example.com/base-dir",
// ... other values ...
}
```
3. If you normally configure bitwarden_rs via environment variables, update your config files/scripts to set the `DOMAIN` environment variable to the base URL. For example:
3. If you normally configure vaultwarden via environment variables, update your config files/scripts to set the `DOMAIN` environment variable to the base URL. For example:
```sh
docker run -e DOMAIN="https://bitwarden.example.com/base-dir" ...
```
4. Restart bitwarden_rs.
4. Restart vaultwarden.
5. You should now be able to access the web vault at `https://bitwarden.example.com/base-dir/` (note the trailing slash). For reasons not entirely clear, you'll probably run into issues if you use `https://bitwarden.example.com/base-dir` (without the trailing slash).
6. Configure your apps or browser extensions to use `https://bitwarden.example.com/base-dir`. If you add a trailing slash, the apps and extensions will automatically remove it before saving.
7. Note over **5**. The trailing slash `/` issue could be solved by appending `/` after the route location string. For example, in nginx.
@ -37,4 +37,4 @@ Simply configure your domain URL to include the base dir. For example, suppose y
## Reverse proxying
If you are putting bitwarden_rs behind a reverse proxy, make sure your proxy is configured to pass the request path through to bitwarden_rs, since the bitwarden_rs API routes are set up to expect the base dir. So if a request for `https://bitwarden.example.com/base-dir/api/sync` hits your reverse proxy, which then proxies to your bitwarden_rs listening on `localhost:8080`, the request must go to `http://localhost:8080/base-dir/api/sync`, not `http://localhost:8080/api/sync`.
If you are putting vaultwarden behind a reverse proxy, make sure your proxy is configured to pass the request path through to vaultwarden, since the vaultwarden API routes are set up to expect the base dir. So if a request for `https://bitwarden.example.com/base-dir/api/sync` hits your reverse proxy, which then proxies to your vaultwarden listening on `localhost:8080`, the request must go to `http://localhost:8080/base-dir/api/sync`, not `http://localhost:8080/api/sync`.

38
Using-the-MariaDB-(MySQL)-Backend.md

@ -10,7 +10,7 @@ If you insist to use MySQLv8 instead of MariaDB then create a user using an old
---
To use the MariaDB (MySQL) backend, you can either use the [official Docker image](https://hub.docker.com/r/bitwardenrs/server) or build your own binary [with MySQL enabled](https://github.com/dani-garcia/bitwarden_rs/wiki/Building-binary#mysql-backend).
To use the MariaDB (MySQL) backend, you can either use the [official Docker image](https://hub.docker.com/r/vaultwarden/server) or build your own binary [with MySQL enabled](https://github.com/dani-garcia/vaultwarden/wiki/Building-binary#mysql-backend).
To run the binary or container, ensure the ```DATABASE_URL``` environment variable is set (i.e. ```DATABASE_URL='mysql://<user>:<password>@mysql/bitwarden'```).
@ -36,13 +36,13 @@ docker run --name mysql --net <some-docker-network>\
-e MYSQL_USER=<bitwarden_user>\
-e MYSQL_PASSWORD=<bitwarden_pw> -d mysql:5.7
# Start bitwarden_rs with MySQL Env Vars set.
# Start vaultwarden with MySQL Env Vars set.
docker run -d --name bitwarden --net <some-docker-network>\
-v $(pwd)/bw-data/:/data/ -v <Path to ssl certs>:/ssl/\
-p 443:80 -e ROCKET_TLS='{certs="/ssl/<your ssl cert>",key="/ssl/<your ssl key>"}'\
-e RUST_BACKTRACE=1 -e DATABASE_URL='mysql://<bitwarden_user>:<bitwarden_pw>@mysql/bitwarden'\
-e ADMIN_TOKEN=<some_random_token_as_per_above_explanation>\
-e ENABLE_DB_WAL='false' <you bitwarden_rs image name>
-e ENABLE_DB_WAL='false' <you vaultwarden image name>
```
### Example using Non-Docker MySQL Server:
@ -74,7 +74,7 @@ services:
- "MYSQL_USER=<bitwarden_user>"
bitwarden:
image: "bitwardenrs/server:latest"
image: "vaultwarden/server:latest"
container_name: "bitwarden"
hostname: "bitwarden"
restart: always
@ -97,44 +97,44 @@ volumes:
### Create database and user
1. Create an new (empty) database for bitwarden_rs (Ensure the Charset and Collate are correct!):
1. Create an new (empty) database for vaultwarden (Ensure the Charset and Collate are correct!):
```sql
CREATE DATABASE bitwarden_rs CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE DATABASE vaultwarden CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
```
2a. Create a new database user and grant rights to database (MariaDB, MySQL versions before v8):
```sql
CREATE USER 'bitwarden_rs'@'localhost' IDENTIFIED BY 'yourpassword';
GRANT ALL ON `bitwarden_rs`.* TO 'bitwarden_rs'@'localhost';
CREATE USER 'vaultwarden'@'localhost' IDENTIFIED BY 'yourpassword';
GRANT ALL ON `vaultwarden`.* TO 'vaultwarden'@'localhost';
FLUSH PRIVILEGES;
```
2b If you use MySQL v8.x you need to create the user like this:
```sql
-- Use this on MySQLv8 installations
CREATE USER 'bitwarden_rs'@'localhost' IDENTIFIED WITH mysql_native_password BY 'yourpassword';
GRANT ALL ON `bitwarden_rs`.* TO 'bitwarden_rs'@'localhost';
CREATE USER 'vaultwarden'@'localhost' IDENTIFIED WITH mysql_native_password BY 'yourpassword';
GRANT ALL ON `vaultwarden`.* TO 'vaultwarden'@'localhost';
FLUSH PRIVILEGES;
```
If you created the user already and want to change the password type:
```sql
-- Change password type from caching_sha2_password to native
ALTER USER 'bitwarden_rs'@'localhost' IDENTIFIED WITH mysql_native_password BY 'yourpassword';
ALTER USER 'vaultwarden'@'localhost' IDENTIFIED WITH mysql_native_password BY 'yourpassword';
```
You might want to try a restricted set of grants:
```sql
GRANT ALTER, CREATE, DELETE, DROP, INDEX, INSERT, SELECT, UPDATE ON `bitwarden_rs`.* TO 'bitwarden_rs'@'localhost';
GRANT ALTER, CREATE, DELETE, DROP, INDEX, INSERT, SELECT, UPDATE ON `vaultwarden`.* TO 'vaultwarden'@'localhost';
FLUSH PRIVILEGES;
```
### Migrating from SQLite to MySQL
An easy way of migrating from SQLite to MySQL has been described in this [issue comment](https://github.com/dani-garcia/bitwarden_rs/issues/497#issuecomment-511827057). The steps are repeated below. Please, note that you are using this at your own risk and you are strongly advised to backup your installation and data!
An easy way of migrating from SQLite to MySQL has been described in this [issue comment](https://github.com/dani-garcia/vaultwarden/issues/497#issuecomment-511827057). The steps are repeated below. Please, note that you are using this at your own risk and you are strongly advised to backup your installation and data!
1. First follow the steps 1 and 2 above
2. Configure bitwarden_rs and start it, so diesel can run migrations and set up the schema properly. Do not do anything else.
3. Stop bitwarden_rs.
2. Configure vaultwarden and start it, so diesel can run migrations and set up the schema properly. Do not do anything else.
3. Stop vaultwarden.
4. Dump your existing SQLite database using the following command. Double check the name of your sqlite database, default should be db.sqlite.<br>
**Note:** You need the sqlite3 command installed on your Linux system.<br>
We need to remove some queries from the output of the sqlite dump like create table etc.. we will do that here.<br><br>
@ -150,9 +150,9 @@ cat sqlitedump.sql >> mysqldump.sql
```
5. Load your MySQL dump:
```bash
mysql --force --password --user=bitwarden_rs --database=bitwarden_rs < mysqldump.sql
mysql --force --password --user=vaultwarden --database=vaultwarden < mysqldump.sql
```
6. Start bitwarden_rs again.
6. Start vaultwarden again.
*Note: Loading your MySQL dump with ```--show-warnings``` will highlight that the datetime fields are getting truncated during the import which **seems** to be okay.*
```
@ -169,8 +169,8 @@ fix:
sed -i 's#\"#\#g' mysqldump.sql
```
```bash
mysql --password --user=bitwarden_rs
use bitwarden_rs
mysql --password --user=vaultwarden
use vaultwarden
source /bw-data/mysqldump.sql
exit
```

20
Using-the-PostgreSQL-Backend.md

@ -1,4 +1,4 @@
To use the PostgreSQL backend, you can either use the [official Docker image](https://hub.docker.com/r/bitwardenrs/server) or build your own binary [with PostgreSQL enabled](https://github.com/dani-garcia/bitwarden_rs/wiki/Building-binary#postgresql-backend).
To use the PostgreSQL backend, you can either use the [official Docker image](https://hub.docker.com/r/vaultwarden/server) or build your own binary [with PostgreSQL enabled](https://github.com/dani-garcia/vaultwarden/wiki/Building-binary#postgresql-backend).
To run the binary or container ensure the `DATABASE_URL` environment variable is set (i.e. `DATABASE_URL='postgresql://<user>:<password>@postgresql/bitwarden'`)
@ -6,7 +6,7 @@ To run the binary or container ensure the `DATABASE_URL` environment variable is
```ini
DATABASE_URL=postgresql://[[user]:[password]@]host[:port][/database]
```
An example docker run environment variable would be: ```-e 'DATABASE_URL=postgresql://postgresadmin:strongpassword@postgres:5432/bitwardenrs'```.
An example docker run environment variable would be: ```-e 'DATABASE_URL=postgresql://postgresadmin:strongpassword@postgres:5432/vaultwarden'```.
If your password contains special characters, you will need to use percentage encoding.
@ -20,22 +20,22 @@ A complete list of codes can be found on [Wikipedia page for percent encoding](h
An easy way of migrating from SQLite to PostgreSQL or to MySQL exists, but please, note that you **are using this at your own risk and you are strongly advised to backup your installation and data!**. This is **unsupported** and has not been robustly tested.
1. Create an new (empty) database for bitwarden_rs:
1. Create an new (empty) database for vaultwarden:
```sql
CREATE DATABASE bitwarden_rs;
CREATE DATABASE vaultwarden;
```
2. Create a new database user and grant rights to database:
```sql
CREATE USER bitwarden_rs WITH ENCRYPTED PASSWORD 'yourpassword';
GRANT all privileges ON database bitwarden_rs TO bitwarden_rs;
CREATE USER vaultwarden WITH ENCRYPTED PASSWORD 'yourpassword';
GRANT all privileges ON database vaultwarden TO vaultwarden;
```
3. Configure bitwarden_rs and start it, so diesel can run migrations and set up the schema properly. Do not do anything else.
4. Stop bitwarden_rs.
3. Configure vaultwarden and start it, so diesel can run migrations and set up the schema properly. Do not do anything else.
4. Stop vaultwarden.
5. install [pgloader](http://pgloader.io/)
6. create the file bitwarden.load with the following content:
```
load database
from sqlite:///where/you/keep/your/bitwarden_rs/db.sqlite3
from sqlite:///where/you/keep/your/vaultwarden/db.sqlite3
into postgresql://yourpgsqluser:yourpgsqlpassword@yourpgsqlserver:yourpgsqlport/yourpgsqldatabase
WITH data only, include no drop, reset sequences
EXCLUDING TABLE NAMES LIKE '__diesel_schema_migrations'
@ -43,4 +43,4 @@ load database
;
```
7. run the command ```pgloader bitwarden.load``` and you might see some warnings, but the migration should complete successfully
8. Start bitwarden_rs again.
8. Start vaultwarden again.

38
Which-container-image-to-use.md

@ -1,12 +1,12 @@
`bitwarden_rs` provides a single Docker image ([`bitwardenrs/server`](https://hub.docker.com/r/bitwardenrs/server)) with unified support for SQLite, MySQL, and PostgreSQL database backends, as of version 1.17.0. Prior to that version, there were separate images for each database backend (see [Historical images](#historical-images)).
`vaultwarden` provides a single Docker image ([`vaultwarden/server`](https://hub.docker.com/r/vaultwarden/server)) with unified support for SQLite, MySQL, and PostgreSQL database backends, as of version 1.17.0. Prior to that version, there were separate images for each database backend (see [Historical images](#historical-images)).
The `bitwardenrs/server` image is also multi-arch, meaning it supports multiple CPU architectures under a single image name. Assuming you're running one of the supported architectures, simply pulling `bitwardenrs/server` should automatically yield the appropriate arch-specific image for your environment, with the possible exception of ARMv6 boards, such as Raspberry Pi 1 and Zero (see [moby/moby#41017](https://github.com/moby/moby/issues/41017)). ARMv6 users running Docker 20.10.0 and later can simply pull the `bitwardenrs/server` multi-arch image as usual. ARMv6 users running earlier Docker versions must specify `arm32v6` in the image tag, e.g. `latest-arm32v6`.
The `vaultwarden/server` image is also multi-arch, meaning it supports multiple CPU architectures under a single image name. Assuming you're running one of the supported architectures, simply pulling `vaultwarden/server` should automatically yield the appropriate arch-specific image for your environment, with the possible exception of ARMv6 boards, such as Raspberry Pi 1 and Zero (see [moby/moby#41017](https://github.com/moby/moby/issues/41017)). ARMv6 users running Docker 20.10.0 and later can simply pull the `vaultwarden/server` multi-arch image as usual. ARMv6 users running earlier Docker versions must specify `arm32v6` in the image tag, e.g. `latest-arm32v6`.
The SQLite backend is the most widely used/tested, and recommended for most users unless there is a specific need to use a different database backend.
### Image tags
The `bitwardenrs/server` image has several tags, each of which represents some variant or property (e.g., specific version) of the image.
The `vaultwarden/server` image has several tags, each of which represents some variant or property (e.g., specific version) of the image.
* `latest` -- Tracks the latest released version (i.e., tagged with a version number). This tag is recommended for most users, as it's generally the most stable.
@ -26,18 +26,18 @@ The `bitwardenrs/server` image has several tags, each of which represents some v
## Image updates
Occasionally, the upstream Bitwarden project (i.e., Bitwarden Inc.) makes backward-incompatible changes to the clients that require matching changes to the server implementation. bitwarden_rs generally pushes out a new release promptly to handle these changes.
Occasionally, the upstream Bitwarden project (i.e., Bitwarden Inc.) makes backward-incompatible changes to the clients that require matching changes to the server implementation. vaultwarden generally pushes out a new release promptly to handle these changes.
However, since upstream controls the release of the clients, and mobile apps and browser extensions typically auto-update on their own, it's important for bitwarden_rs users to keep up-to-date with the latest bitwarden_rs release. Otherwise, incompatible client and server versions can lead to sudden breakage or misbehavior.
However, since upstream controls the release of the clients, and mobile apps and browser extensions typically auto-update on their own, it's important for vaultwarden users to keep up-to-date with the latest vaultwarden release. Otherwise, incompatible client and server versions can lead to sudden breakage or misbehavior.
The web vault is the only exception; as it's bundled with the bitwarden_rs image, the web vault version is always properly matched to the bitwarden_rs server version. If you only use the web vault as the client (unlikely), then you don't need to worry about these compatibility issues.
The web vault is the only exception; as it's bundled with the vaultwarden image, the web vault version is always properly matched to the vaultwarden server version. If you only use the web vault as the client (unlikely), then you don't need to worry about these compatibility issues.
## Historical images
Prior to the addition of multidb support in version 1.17.0, MySQL and PostgreSQL support was only included in separate database-specific images. You can still find these in Docker Hub, and they are still updated for now. However, the database-specific images will be removed in the future, so you should transition to using the unified `bitwardenrs/server` image.
Prior to the addition of multidb support in version 1.17.0, MySQL and PostgreSQL support was only included in separate database-specific images. You can still find these in Docker Hub, and they are still updated for now. However, the database-specific images will be removed in the future, so you should transition to using the unified `vaultwarden/server` image.
* [`bitwardenrs/server-mysql`](https://hub.docker.com/r/bitwardenrs/server-mysql) - Debian-based `bitwarden_rs` image that includes support for MySQL only (not SQLite or PostgreSQL).
* [`bitwardenrs/server-postgresql`](https://hub.docker.com/r/bitwardenrs/server-postgresql) - Debian-based `bitwarden_rs` image that includes support for PostgreSQL only (not SQLite or MySQL).
* [`bitwardenrs/server-mysql`](https://hub.docker.com/r/bitwardenrs/server-mysql) - Debian-based `vaultwarden` image that includes support for MySQL only (not SQLite or PostgreSQL).
* [`bitwardenrs/server-postgresql`](https://hub.docker.com/r/bitwardenrs/server-postgresql) - Debian-based `vaultwarden` image that includes support for PostgreSQL only (not SQLite or MySQL).
## Historical tags
@ -57,13 +57,13 @@ Please add your details here, if you're running the image on a hardware that is
| Hardware used | OS | Docker architecture reported | Image used | Status | Notes |
|----------------------|--------------|---------------------------------|---------------------|--------|-------|
| Regular 64bit server | Ubuntu 18.04 | x86_64 | `bitwardenrs/server` | OK | |
| O-Droid HC2 | Armbian | arm7l (arm32) | `registry.lollipopcloud.solutions/arm32v7/bitwarden` (see notes) | OK | Unofficial image built from upstream sources ; `bitwardenrs/server:raspberry` is the official equivalent image |
| Raspberry Pi Zero W | Raspbian (4.14.98+) | linux/arm (armv6l) | `bitwardenrs/server:armv6` | OK | |
| Raspberry Pi Zero W | Raspbian (4.19.66+) | linux/arm (armv6l) | `bitwardenrs/server:latest` (Multiarch) | OK | Only when using the docker experimental feature 'docker pull --platform=linux/arm/v6'. Otherwise the wrong image will be selected (https://github.com/dani-garcia/bitwarden_rs/issues/1064) |
| Raspberry Pi 1 B | Raspbian (4.19.97+) | linux/arm (armv6l) | `bitwardenrs/server:armv6` | OK | |
| Raspberry Pi 3 B | Raspbian (4.14.98-v7+) | linux/arm (armv7l) | `bitwardenrs/server:raspberry` | OK | |
| Raspberry Pi 4 | Raspbian (4.19.118-v7l+) | linux/arm (armv7l) | `bitwardenrs/server:raspberry` | OK | 4go version, rev 1.1 |
| Synology | DSM (DSM 6.2.1-23824 Update 6) | Docker-x64-17.05.0-0367 | `bitwardenrs/server:latest` | OK |
| Synology | DSM (DSM 6.2.2-24922 Update 4) | Docker-x64-18.09.0-0506 | `bitwardenrs/server:1.13.0-alpine` | OK |
| Regular 64bit server | Unraid 6.8.0 | 19.03.5 | `bitwardenrs/server:latest` | OK | |
| Regular 64bit server | Ubuntu 18.04 | x86_64 | `vaultwarden/server` | OK | |
| O-Droid HC2 | Armbian | arm7l (arm32) | `registry.lollipopcloud.solutions/arm32v7/bitwarden` (see notes) | OK | Unofficial image built from upstream sources ; `vaultwarden/server:raspberry` is the official equivalent image |
| Raspberry Pi Zero W | Raspbian (4.14.98+) | linux/arm (armv6l) | `vaultwarden/server:armv6` | OK | |
| Raspberry Pi Zero W | Raspbian (4.19.66+) | linux/arm (armv6l) | `vaultwarden/server:latest` (Multiarch) | OK | Only when using the docker experimental feature 'docker pull --platform=linux/arm/v6'. Otherwise the wrong image will be selected (https://github.com/dani-garcia/vaultwarden/issues/1064) |
| Raspberry Pi 1 B | Raspbian (4.19.97+) | linux/arm (armv6l) | `vaultwarden/server:armv6` | OK | |
| Raspberry Pi 3 B | Raspbian (4.14.98-v7+) | linux/arm (armv7l) | `vaultwarden/server:raspberry` | OK | |
| Raspberry Pi 4 | Raspbian (4.19.118-v7l+) | linux/arm (armv7l) | `vaultwarden/server:raspberry` | OK | 4go version, rev 1.1 |
| Synology | DSM (DSM 6.2.1-23824 Update 6) | Docker-x64-17.05.0-0367 | `vaultwarden/server:latest` | OK |
| Synology | DSM (DSM 6.2.2-24922 Update 4) | Docker-x64-18.09.0-0506 | `vaultwarden/server:1.13.0-alpine` | OK |
| Regular 64bit server | Unraid 6.8.0 | 19.03.5 | `vaultwarden/server:latest` | OK | |

4
_Sidebar.md

@ -4,7 +4,7 @@
## Container Image Usage
1. [[Which container image to use|Which-Container-image-to-use]]
1. [[Starting a container|Starting-a-container]]
1. [[Updating the bitwarden image|Updating-the-bitwarden-image]]
1. [[Updating the vaultwarden image|Updating-the-vaultwarden-image]]
1. [[Using Docker Compose|Using-Docker-Compose]]
1. [[Using Podman|Using-Podman]]
@ -19,7 +19,7 @@
### HTTPS
1. [[Enabling HTTPS|Enabling-HTTPS]]
1. [[Running a private bitwarden_rs instance with Let's Encrypt certs]]
1. [[Running a private vaultwarden instance with Let's Encrypt certs]]
## Configuration
1. [[Overview|Configuration-overview]]