To report bugs, check out the following Github issue for detailed instructions.
For those who have the resources to install, run, and maintain hardware, Bitwarden is pleased to offer a new, flexible deployment option for self-hosted environments. The Bitwarden unified self-hosted deployment joins the existing standard deployment option as a lightweight alternative for those who choose to deploy and manage their password management solution on their own private network or infrastructure.
Warning: This is a beta release, which means that this deployment option may be unstable and have issues. If you manage a Bitwarden organization vault, we recommend using the officially-supported, standard deployment option.
Thank you very much the reply.
Docker handling with one single container will be much easier and possibly be handled by portainer + watchtower. Also arm support for pi is great.
Good work!
@bw-admin Frustrated (soon to be former) LastPass user here. Checking out the unified beta, looks like a great start!
Apologies if this is a basic question as Iām new, but what are the (supposedly unencrypted) key files in /var/lib/docker/volumes/bitwarden/_data/data-protection used for?
Also worth noting is that I tried setting mem_limit: 200m as suggested in the documentation but the app wouldnāt function at that limit. Currently running with no limit and 1G of memory with linuxserver\swag for reverse proxy.
The data-protection key files are used as a part of ASP.NET Coreās data protection packages. We specifically use it for tokens we create for things like an organization invite so we can send a token that contains information such as who the organization invite is coming from and an expiration date. The keys it uses to protect that data to ensure it hasnāt been tampered with are in those directories so that tokens can still be used even if you restart the container.
The 200m minimum might not be for everyone and much like any video game I would recommend having more than the minimum specs but thanks for letting us know, if we get to many people not able to have the 200m limit work we may bump it up a little bit.
I love that Bitwarden has created a Unified docker image that gives more options and control for self-hosting. Thank you guys for that!
Generally speaking, I believe the Unified deployment should either:
Have options to achieve the same essential functional setup as the standard installation, orā¦
Clearly state where and how the two installations differ.
It appears that the Unified version does not have the same SSL certificate generation via Lets Encrypt that the standard self-host installation does. If that functionality will not be part of Unified, the difference should probably be mentioned in the installation guide and the āFor additional information, see Certificate Options.ā link should be changed to something that has information for both Standard and Unified, or be a link to something that is specific to Unified.
I am fairly new to Bitwarden, and have recently moved to using you mainly for the possibility to self-host my own environment. Over the holidays, Iāve set up the regular environment, and then now also the unified beta. I am using a 1GB Ubuntu VM behind Cloudflare using their āauthenticated origin pullsā. For that I use Caddy (alpine) as a reverse proxy.
In comparison to the regular install, the unified beta works so much better for me, given the limited RAM I am using (mainly to keep the costs down I try and see what I can get away with). FWIW, I have assigned a 500M limit for the bitwarden container, and that seems fine so far.
The regular install too often ran out of memory even with 2GB RAM. For the unified beta, I am running Bitwarden, MariaDB and Caddy all via docker compose, which seems to make communication between the containers easy, and avoids port assignment issues. Thank you for providing this option!
Some feedback perhaps for consideration:
I managed to backup the docker volumes for bitwarden and mysql (etc/bitwarden and /var/lib/mysql respectively) and was able to recreate my system on an entirely new VM, so backup worked! The only thing that did not work were the 2FA FIDO2 keys ā despite using the same domain name, they flagged an error and I could not log into my vault. Seems they detected the different machine, which probably is a feature and not a bug. I was however able to log into the reconstituted vault using both authenticator app as well as the recovery code, so was fine. But thatās perhaps something to document towards users in the context of these backups (i.e. you might get locked out of backups if only using FIDO2 for your vault!)
I actually managed to also back up the mysql database only using the suggestion from MariaDB. That does not backup attachments, but this could be a convenient alternative to do nightly backups. For that though, I needed to know the MariaDB database root password. Your present documentation suggests setting a random one that seems not known to the user (MARIADB_RANDOM_ROOT_PASSWORD: ātrueā). So pointing that out might be another item to consider, and again, this would be no way to recover from backups on another machine in case of a complete loss of the original machine/VM.
Overall, I am not sure what would be the most efficient procedure for backups of the unified build. More guidance might be useful once you come out of beta.
Thank you for doing this unified deployment though, itās a major improvement for me!
Thanks for the feedback all! Please continue to add general feedback here and see below for reporting specific bugs.
While the Bitwarden unified deployment remains in beta release, we encourage you to report issues and give feedback via GitHub. Please use this issue template to report anything related to your Bitwarden unified deployment and check out this page to track known issues or join the discussion.
This may be more of a feature request so Iām putting it here instead of Github.
Would it be possible to configure the database details using a DB_URL? The hosting platform Iām using automatically provides a linked db using such a url in the environment of the spun up container. This platform (https://dokku.com) allows me to rename such an environment variable but it must have the _URL suffix. I believe DB_URL is pretty much standard for these sorts of things.
Thanks @mrwonka the team will continue to review feedback on the beta, can you drop a feature request here and tag it āunifiedā for voting/discussion?
Support DB_URL for configuration of database credentials.
Feature function
Currently itās possible to configure the unified docker image with a database using separate DB credentials variables. Itād be great if we could just supply a singular āDB_URLā as this would work great with Heroku like deployment systems which auto populate such a value if youāve linked up a database to the application.
Youāve probably seen what these look like but just in case this is probable:
Just finished setting up a Unified deployment on mysql with nginx reverse proxy. Very happy with what Iāve seen so far but I have a small issue.
My issue is that Iām using a custom port (ie 9443) and in a few places this isnāt recognized (verification email and admin login noted so far). Is there somewhere to set this port so that those URLs work inherently without having to re-write the URL manually by hand? I canāt find any env variable that seems to fit the bill for this use-case but maybe Iām missing something.
Support Oracle Database as database backend for unified deployment
Feature function
Will enable the use of Oracle Database. This will be handy for Oracle Cloud free tier users since Oracle gives 2x managed Oracle Database instances with 20GB storage each.
I cannot really find the answer, but my company is interested in the new unified solution and i like to test it. Would it be possible to switch the docker version to the āliveā version without having to migrate everything once unified comes out of beta?