Newbie help and decision

I still have PTSD from LastPass and I am trying to convert my wife and I over to something. I have a Synology NAS business class. I have been reading about 1password, Bitwarden, Vaultwarden (self-hosting) and finally C2 Password from Synology. Naturally you would think C2 Password would be a good fit since I am familar with Synology NAS and all of my network devices are Synology. However, I find that it is new and I am not sure I can trust them like I can’t trust anyone else. I am looking for US based solutions which of course C2 is not. BitWarden is US based code, but being open source, what is going to stop the hackers from taking the code and figuring out how to manipulate Browsers, Mobile Apps and the like. Also, since I would like to make a longer term commitment to a solution, I was considering self-hosting, but it can’t be too complicated for my wife and I am novice with just enough knowledge to figure stuff out. I see that Vault Warden using Docker can be hosted on a NAS server, but this is third-party software which concerns me. I have read in this form that BitWarden does not run on Synology NAS, but it can be run through docker, so I am confused since docker can be run on Synology. I did not find anyone talking about running the official version of BitWarden on a Synology NAS, so I am guessing there is a nuisance here with docker and a package to implement. Finally, is hosting any better than just going through Bitwarden servers. Again, I have PTSD from LastPass and hosted solutions and I have been running LastPass back to the Roboform days. I willing to lock everything down behind my servers and firewalls, but I would need all the specifics on how to do that. VaultWarden seems to provide everything including reverse Proxy, buttttttt this is again third-party and I am unsure if I can trust that. Any advice would be greatly appreciated.

I did see a post that appears to be installing BitWarden Unified below, if someone else can confirm that is what is going on at this site. They are using Portainer to load with Docker which I have no background with and it looks like you have to authorize changes to the NAS configuration that seems risky.

I’m newbie as well, but in fact is using the unified version. Check step 16, that they use the bitwarden/self-host:beta image, which is indeed the one for Unified

I got to your post in a similar situation, I wanted to move on with self hosting BitWarden on a RaspberryPI and sometime ago I was discouraged when I saw the option everyone was talking about was BitwardenRS (which now has become VaultWarden): nothing against the developer but is a personal initiative reimplementing everything in Rust and I’d prefer to stick with the official developers (and other personal preferences). And yesterday I discovered the Unified version exists now.

Regarding Portainer: in a nutshell it’s being used as an administration frontend for creating containers and other related docker stuff, they use it to create a stack (that’s comprised of two containers, first one for the DB and second one for BitWarden itself).

I’ll be working with this but not sure I could provide you any relevant details as have no idea about Synology. As for VaultWarden I don’t think they have the reverse proxy embedded (again, I’m talking from what I gathered some months ago, but I’d be surprised if that changed).

Hope this gives you some light, cheers

1 Like

Thank you for the feedback it is very helpful. My main concern is that the gentlemen also has a Howto on loading Portainer and part of it it says allow root configuration changes to the NAS. I am sure it is probably fine, but I don’t like to follow instructions without knowing the hazards of doing so. I am wondering why I need Portainer when VaultWarden can just use Docker directly to load unless VaultWarden already has as Stack to load to Synology NAS. Again newbie here, so I appologize for incorrect terms. Here is the link to the Portainer Howto. In step 6 you can see the warning. https://mariushosting.com/synology-30-second-portainer-install-using-task-scheduler-docker/

But instead of using portainer if you’re uncomfortable with the option (and I understand is not nice providing root access just because someone says so), you can get away without it by using docker compose (to ease managing both db and BitWarden containers) or go all the way with docker. Check the official guide for unified, if you have some basic knowledge on containers I think is understandable.

No knowledge at all on containers, but using Docker all the way would probably be best for me even if there are growing pains. I guess I want to use the tools as meant by the developers. Containers sound like a package of runtime library and/or routines, so maybe it will make since to me. Will you use Portainer or are you going to use Docker directly? I took programming as electives including Fortran, Cobol, Basic, Assembly, Pascal, DBASE & Clipper(actually wrote programs for a living), and some C++, but that was 30 years ago and I have not done much since. I have tinkered with Raspberry PI and run Octoprint on one for my 3D printer. So, I have enough general background to get into trouble and hopefully figure things out.

I should add that my Synology NAS has Docker as a standard package to download.

1 Like

There seem to be a few posts such as in the Synology forums, a linked post from there (which was also recommended in a Google search for “run docker compose Synology”), as well as another Google recommended guide to running docker compose on a compatible Synology NAS device.

Though, as pointed out in a Reddit post the Synology docker stack may not be well maintained, or fit the Bitwarden Unified System Requirements to have at least Docker Engine 19+
So you may be better off running a VM if you have the Synology Virtual Machine Manager, and running docker and docker-compose within that VM.

Though there seems to be a few ways to go about it depending on if your hardware supports these, so you can choose the option that suits you best.

I’m running Vaultwarden in Docker on my Synology DS720+ without issue (using Synology’s Docker package). I also made the switch from Lastpass and the transition was pretty smooth (and even easily accepted by the family members I had to transition). I’ve got Portainer running too but really only use it to view running containers (and clean out old images) not to actually manage/deploy containers. So far using Synology’s app has worked just fine.

2 Likes

Apologies for the delay coming back to this but been busy with a few things and having little time for my Bitwarden project. Yesterday I’ve managed to get it up and running.

I’ll try to give some context in a nutshell, hope you don’t mind and I don’t sound condescending (not intended at all, specially as I’m not an expert):

From an end user perspective I’d rather think it as a “micro virtual machine”: it will be executing within your host and allow you to run stuff on that container as if you’d remote control a virtual machine (for instance you can launch an interactive shell). How it works below the surface is way different from a VM but as a person interested in having a software deployed in an isolated manner, is a similar experience.

Besides the containers themselves, you might hear about stacks which are basically a group of containers that work together to provide a given service. For instance Bitwarden Unified will require bot the application itself and its database, so is a good choice to create a stack with one container for the application (using the BitWarden Unified image) and another for the database (there you have different options as many database engines are supported).

I’ve been using Portainer for about half year but lately I’ve started moving out of its stack management as it was a bit limiting for my stuff; right now I’m using docker compose for the stacks setup directly (still using Portainer for inspecting and connecting to the containers). In any case, I think Portainer is good enough for this use case, but in the end it leans on docker compose so the knowledge for configuring the stack is the same.

That’s the very basic. Then docker has a lot of things you can tweak with for given the containers real usage (otherwise they’d be just an isolated box):

  • volumes: mounting host file system onto the container
  • port mapping: mapping the container ports into the hosts ports to allow extenal connections
  • networks: allow to different containers to communicate to each other by joining a network
  • secrets: prevent using environment variables for setting up sensitive data
  • resource limits: to prevent containers taking too much from the host
  • etc etc etc

Setup with a Reverse Proxy

I’m sharing a version of my solution, in case it helps. Unfortunately this includes using a reverse proxy that I had set up before and is outside the solution so it can be confusing; the reason for that is that Bitwarden app won’t work without SSL so you either configure the certificate on the container itself or have a proxy on top of that (you can check this comment with some thoughts around that) . In any case here it goes an example for the compose.yaml (or the stack definition):

name: bitwarden

services:
  app:
    image: bitwarden/self-host:beta
    depends_on:
      - db
    volumes:
      - /my-stacks/bitwarden/bitwarden-data:/etc/bitwarden # where /my-stacks/bitwarden/bitwarden-data is a directory on your local filesystem where you'd like the container to keep it's persistent storage (in this case some encryption keys, certificates and logs)
    environment:
      # Server hostname
      BW_DOMAIN: my-bitwarden.my-domain # This assumes you have your own domain. If not exposing to the internet you can use .local or similar stuff
      # Database
      BW_DB_PROVIDER: mysql
      BW_DB_SERVER: db # See the other container configuration for explanation on this value
      BW_DB_DATABASE: my-bitwarden-database-name
      BW_DB_USERNAME: my-user
      BW_DB_PASSWORD: my-strong-password-for-my-user
      # Installation information - obtained from https://bitwarden.com/host/
      BW_INSTALLATION_ID: my-guid-taken-from-bitwarden 
      BW_INSTALLATION_KEY: my-secret-taken-from-bitwarden
      # if you'd like to prevent registration, after your users are registered you'll need to uncomment next line and restart the stack
      # globalSettings__disableUserRegistration: true 
      # Email - Needed for getting verification emails, alerts, etc. You can use the tool without this but I don't think is a good idea. Leaving an example with gmail
      globalSettings__mail__replyToEmail: [email protected]
      globalSettings__mail__smtp__host: smtp.gmail.com
      globalSettings__mail__smtp__port: 587
      globalSettings__mail__smtp__ssl: true
      globalSettings__mail__smtp__username: [email protected]
      globalSettings__mail__smtp__password: my-16chars-app-password # Check https://support.google.com/accounts/answer/185833?hl=en for how to create and use this
    networks: 
      default:
      reverse-proxy-network: # joining the container to a network with the reverse proxy
        aliases:
          - bitwarden.local # the name used for thereverse proxy to reach this container. Basically this means that the reverse proxy is mapping anything that targets https://my-bitwarden.my-domain to http://bitwarden.local:8080, being 8080 the default port used by Bitwarden

  db:  # This is used also as the hostname, that's why same literal is in the BW_DB_SERVER variable
    image: lscr.io/linuxserver/mariadb:latest
    environment:
      MYSQL_DATABASE: my-bitwarden-database-name
      MYSQL_USER: my-user
      MYSQL_PASSWORD: my-strong-password-for-my-user
      MYSQL_ROOT_PASSWORD: my-super-strong-password-for-root-access
    volumes:
      - /my-stacks/bitwarden/mysql:/config # where /my-stacks/bitwarden/mysql is a directory on your local filesystem where you'd like the container to keep it's persistent storage (in this case both database files and mariadb configuration)

networks:
  reverse-proxy-network: #the docker network where the reverse proxy is located
    external: true

:information_source: Any place where you find a my- prefix, is because that value shoud be decided and configured

Hope this is helpful. Cheers

1 Like

All of your time and effort is greatly appreciated. It seems I have a lot of reading to do understand Docker and creating the environment. After loading Docker, I see Bitwarden Self Hosting Unified Registry. I will have to do some reading that @cksapp suggested on the Synology forums. I did download the image and launch it, it actually seemed to run without error, but I have no idea what database or any other configuration that was set. I saw DB Vault was in the configuration. I thought I read somewhere in a post from the dev that if you don’t create a separate database, it will create a SQLITE without having to have more than one container. " Only required for sqlite if you would like to specify the path to your database file. If not specified, sqlite will automatically create a vault.db file under the /etc/bitwarden volume."

I am debating going to cloud based Bitwarden until I figure this out as my wife is still using LastPass after of course we have updated all of the logins and credential information. Still it is a really bad idea, but I have not given her an option yet. I have to figure out if I can migrate the credentials to the self-hosted before I would do that.


Rushing into a self-hosted solution as a knee-jerk reaction to the Lastpass breach is understandable, but unnecessary. You need to understand that:

  1. Vaults are encrypted specifically to protect the stored secrets in case the database is ever leaked, and that Bitwarden (unlike Laspass) uses only vetted, standard cryptography libraries for all encryption, so therefore:
  2. The only way that a security vulnerability may exist if a Bitwarden vault is ever stolen is if you choose a weak master password for your vault. If you have a strong, unique, and closely guarded master password, then a stolen vault (should it ever come to that) is completely useless to a thief.

being open source, what is going to stop the hackers from taking the code and figuring out how to manipulate Browsers, Mobile Apps and the like.

I too have PTSD from the Lasspass breach. It’s understandable.

I can’t comment on the self hosting scenario. I’m far too lazy to set something like that up. But I would like to address the point above. I think this is a completely valid point but another way to look at it is because it’s open source it’s not just open for bad actors but good actors as well. It means people are interogating the code and yes there could be a vulnerablity found by a bad actor first but law of averages says any vulnerabilty will be found by a good actor and patched quickly.

And, of course, it doesn’t look like Bitwarden gives admin access to people from their home networks with those people running out of date installs of Plex on the system either. Which really, Last Pass should have ensured that didn’t happen from day one.

1 Like

You’re welcome. Hope you find your way.
I’d think that you can start using the web and then export the vault to your self hosted, based on different articles I’ve seen so far.

I haven’t started reviewing Bitwarden code, but being Open Source does not mean at all it can be hacked by someone reading it. Encryption algorithms (some of them supporting our daily activities on internet) are well known and nobody complains about that. Of course, if anything bad is in there that would allow an attacker to take advantage as you say, other people is also in position to prevent that.

The opposite is security through obscurity, which I believe is not very supported in the security community anymore.