Bitwarden - manage your brigade's passwords as a team


I’d been looking for a FOSS solution for team password management for a while, and finally dove in and tried out a few solutions. I settled on bitwarden_rs, a community-built lightweight implementation of the Bitwarden server API. It’s built in Rust and deploys as a single Docker container.

The first-party Bitwarden server is also FOSS, but is an older and heavier application. While it does leverage Docker for deployment, the supported method is to use their provided scripts to orchestrate a set of containers. I wanted something that was more “cloud-native” so that I could try it out and start using it immediately via docker-compose but eventually transition to hosting it in a brigade kubernetes cluster.

A big plus of using a BitWarden server is that there’s a whole host of official clients out there for Chrome, Android, iOS etc that the BitWarden company maintains, distributes and shares the source code to, but which you can easily point at your own instance from the options on the login screen. The client applications all work via a synchronization routine, so if for whatever reason your server ever goes down temporarily or for good, every client still has its own data.

You can spin it up pretty easily with a docker-compose.yml file like this:

version: "2"

    image: mprasil/bitwarden:latest
    restart: always
      - ./data:/data
      - ""

That’ll put all its data in ./data relative to the docker-compose.yml file, get that into a backup routine somehow or just use DigitalOcean’s automatic (but optional) whole-machine every-3-days snapshotting.

This config exposes it on port 9280 internally so you could then put an nginx server in front of it that encrypts everything and routes some particular subdomain to bitwarden and other subdomains to other containers you run.

Need a tool for project credential sharing

Aren’t you afraid of security issues with a possibly less maintained non-official version? I’m not sure if the official one went through security audits though…


Yeah it’s a concern. I’m confident it beats passing things around on Slack/email/spreadsheets though. The security model uses client-side encryption-decryption, so being compatible with the official clients tells me it’s adhering to that model. There are enough eyes on it to spot major issues and enough users that we probably won’t be the first target of any exploit. It’s also not a public service so our instance isn’t easily discoverable on the web and we can keep it unindexed so bulk exploits can’t easily find it.

My instinct is that we’re better served having a tool that lets us manage sharing in a model that matches our needs than any possible marginal security increase of using a different tool that necessitates workarounds. What good is commercially-supported security if we’re limited to 3 seats and end up passing around master logins? What is the added risk of a solution that doesn’t support a multi-org/collection model that has us distributing more passwords to people than we need? Those threats feel way more real and immediate to me