This is a collection of scripts and configurations that work together to automate deployment of bitwarden_rs in a singular docker container.
This is more or less an extension of the image distribution by @mprasil.
Rather than directly starting bitwarden_rs; however, this image
cron$DOMAIN using certbot, if one is not already available in /datanginx, which serves as the public-facing HTTP server.bitwarden_rsAll environment variables noted in the README for bitwarden_rs still apply. $DOMAIN is of particular importance
in this configuration, and must be set for proper certificate issuance. The assumption is made that this container will
have a dedicated DNS name (e.g. a subdomain of your website such as bitwarden.example.org, in which case $DOMAIN is bitwarden.example.org).
This has the side effect of enabling U2F support (once it gets fixed).
The following environment variables are set by the startup script and cannot be overriden, as other applications expect these to be certain values,
| Variable | Value | Purpose |
|---|---|---|
ROCKET_ENV |
production |
Primarily to prevent excessive logging traffic |
ROCKET_PORT |
8080 |
bitwarden_rs sits behind a reverse proxy |
ROCKET_ADDRESS |
127.0.0.1 |
|
WEBSOCKET_ENABLED |
true |
Reverse proxy routes WS requests |
DATA_FOLDER |
/data/bitwarden |
To make bwrs share /data |
In addition to the aforementioned environment variables, the following new environment variables exist,
| Variable | Default | Purpose |
|---|---|---|
ACME_TRUSTWORTHY |
unset | Setting this will cause certbot to trust invalid certificates (for testing with pebble) |
ACME_SERVER |
unset | ACME service endpoint for certbot |
ACME_DRY |
unset | Setting this adds --dry-run to the initial certbot invocation |
ACME_STAGE |
unset | Setting this add --staging to the intiial certbot invocation |
ACME_EMAIL |
nobody@example.org |
ACME customer email. You absolutely should change this. |
The NginX configuration exists as a template which is processed by envsubst at runtime, in order to accomodate changes to $DOMAIN.
NginX has been configured in such a manner that it scores A+ on SSLLabs certification, specifically
/.well-known/acme-challenge is set up such that certbot's webroot authenticator can coexist with the bitwarden API/notifications/hub and /notifications/hub/negotiate are properly handled so as to enable WebSocket notification supportLogrotate is installed and configured to look for certbot and NginX logs in their subdirectories beneath /data. NginX log files
are rotated on a weekly basis with three weeks of history retained. Certbot logs are rotated on a monthly basis with twelve months
of history retained.
bitwarden_rs output is not logged; however, it (as of writing) has no meaningful output and is more or less silent when ROCKET_ENV is
not set to one of the development/testing values.
Practically speaking, there should be no friction resulting from changes to $DOMAIN; hoever, the certbot renewal INIs for any historic
value of $DOMAIN will persist, resulting in renewal errors.
On the matter of previously used domains, the current design does not accomodate multiple values for $DOMAIN.
-d $DOMAIN is passed directly to certbot, and the manner in which bitwarden_rs interprets the value for $DOMAIN may limit the
ability to pass multiple values in some fashion via the variable.
Because of this, even previous domains remain configured to point at the server, historic renewal configuations will almost certainly to fail,
as the NginX template includes the server_name ${DOMAIN} directive.