Hey,
when I set ADMIN_TOKEN in my docker-compose the admin page gets enabled.
When I remove it it should get disabled, but it is still accessible.
Any ideas why?
I think this is security critical, so any help is appreciated 
Did you try restarting the system?
Yes, doesnt make a change actually, this is so weird
I would contact the Bitwarden CS team in that case:
Hope you get it solved quickly!
1 Like
Hi @Timo_W,
As I understand Bitwarden does not use the environment variable ADMIN_TOKEN=
See Configure Environment Variables | Bitwarden Help & Support
In Bitwarden’s case the system admin portal is logged in with an email address so long as that email has been added to the environment variable adminSettings__admins=
This makes me believe you are instead using Vaultwarden, which is an unofficial 3rd party fork of the Bitwarden project, but does still use compatible client apps.
You can typically verify this, as there should be some type of Vaultwarden branding in welcome emails, web-vault, or admin interface.
The Vaultwarden admin page does use the environment variable ADMIN_TOKEN= and further information can be found on the wiki here.
In short Vaultwarden will use environment variables initially, but will then ignore them once any settings are made via the admin page as it creates a config.json file which will override any environment variables you have set.
The first time you save a setting in the admin page,
config.jsonwill be generated in yourDATA_FOLDER. Values in this file will take precedence over the corresponding environment variable.
Basically you should be able to edit the config.json file to remove the admin interface, or delete the config.json file to force Vaultwarden to use environment variables, but note this file will be recreated if any variables are set with the admin interface.
Depending on your setup, you may also still wish to have the admin interface accessible, but only on your private LAN, and not be accessible on the greater internet if this is publicly exposed, this can be typically set via a reverse proxy if using HTTPS.
Please feel free to reach out directly on the Vaultwarden support forums for further help if needed. We try to keep any Vaultwarden specific concerns off of the main support unless they directly relate to the upstream project.
Hope this helps, and also directs you to the best place for this concern. 
1 Like
You are right, Vaultwarden 
Thank you for your answer, really! I will definitely do my research there then - or switch to Bitwarden:D
Thank you very much.
But I need to ask - why should I choose Bitwarden and not Vaultwarden? I am new to this, so the only thing I see is: Vaultwarden is completly free and offers the same like Bitwarden
I know its a fork, but anyway I am interested in it
The base tier of Bitwarden server is free as well. But if you upgrade to a subscription, you are entitled to priority support from the Bitwarden CS team, and of course, you will have access to a wonderful community of Bitwarden customers here on the forum!
So - what I get is premium support? Are there any differences in terms of security of those both?
Support, community forums, access to the latest development features, including new premium features, etc. I think that alone is worth the paltry amount Bitwarden charges for a subscription.
Regarding security, Bitwarden operates under a model that includes security audits. They are also a business venture, so their reputation is at the core of their business and must take security very seriously. The Vaultwarden fork is independent of Bitwarden and led by enthusiasts, so you will have to do your own evaluation of their security practices to determine if they are as trustworthy.
You think Bitwarden can be run on a 1 Core Server with 2 Gigs of Ram - with only me as user?
It should be fine. See the system requirements here:
1 Like
Thanks again for your help.
1 Like
Also receiving Websocket Errors. I deployed it behind Nginx as reverse proxy, mapped to the port 80 of the nginx container. Is this possible?
Sorry to hear you are running into errors already. Bitwarden server will want to accept incoming requests on port 443 for security reasons, and it is not advised to change that. However, if you are behind a reverse proxy, I believe you can override this so that the server will accept incoming connections on port 80 while behind the proxy.
Regarding the proxy server, you definitely only want it to accept incoming connections on port 443 for security reasons (especially if the server is running on port 80!).
I know that Kent (@cksapp) has a lot more experience with this than I do, so hopefully he chimes in to correct me if I am wrong, and he may have some good insights for you as well.
1 Like
I had much of this previously written before an incident came up at work, and while I am glad you have stuck with the licensed product. I think this would be good information for anyone else who may find themselves in a similar situation.
In regards to the official Bitwarden product VS the unofficial Vaultwarden fork there are several things to be aware of, and it is good to weigh the pros and cons of each solution.
Features
You are correct that Vaultwarden does offer some features that would otherwise be paid premium features in Bitwarden. That being said Vaultwarden also has some features that are missing and are only available in the official release of Bitwarden.
A full list can be viewed in their wiki.
Vaultwarden is primarily developed by enthusiasts as @dh024 mentioned, and as such will typically see longer periods between updates and is dependent on community contributions to its code.
Security
Being community driven, the backend server is also rewritten in the RUST programming language which does have some specific hardware benefits. Vaultwarden though does not have the same intense QA as Bitwarden may, and as I know has never had an in depth look at its code base from a security standpoint. RUST is a fairly secure programming language in and of itself, but still does not account for either malicious or even accidental coding vulnerabilities.
Now this may be less of an issue as the client app (mobile app, browser extension, desktop application, web-vault) all encrypt the data locally prior to sending data to the back-end server. This is how Bitwarden creates its zero-knowledge architecture, and as such even when looking into the database created by Vaultwarden, all information is encrypted and would be less of a concern if this information somehow got into the wrong hands.
This is all to say that Vaultwarden is mainly aimed towards possibly small businesses, and typically home users, and especially those technology home enthusiasts.
I myself personally run a home-lab and multiple projects for testing/home use. While I trust Vaultwarden, I ultimately trust Bitwarden’s vetted and secure client apps that encrypt prior to send. Bitwarden has been vetted by well known and trusted security companies and continually does so on a regular basis.
Compatibility
While Bitwarden being open-source and as I understand perfectly accepting of the Vaultwarden fork (other than requesting a modest branding change to distinguish the projects), they have maintained compatibility thus far with the Bitwarden clients and the Vaultwarden server.
This is not guaranteed though to always work however, while I do not think Bitwarden would intentionally restrict or make changes to their clients that would cause issues with Vaultwarden, should Bitwarden make any major changes to how the client apps function, look and feel in the interface, or even how things are stored with the official Bitwarden server could cause this to break with the unofficial Vaultwarden instance.
i.e. If some of the planned upcoming changes to Bitwarden are implemented such as account switching, etc. this could possibly change how things work between the Bitwarden client and the official Bitwarden server.
When this happens Bitwarden will know their own changes and work with their dev team to integrate these changes between the client apps and server, and have QA ensure consistency.
Vaultwarden would be unaware of the changes until this goes “live” in an update, in which case you may be restricted to only being able to use the Vaultwarden modified web-vault, as this is bundled with Vaultwarden and would not be auto-updated.
This could cause a time where you are unable to access your password vault until Vaultwarden is able to make the compatible changes on their side and also push those updates out.
ETA would be TBD by how fast the community of Vaultwarden’s devs work to restore compatibility
To be (self-hosted), or not to be
That is the question. 
This is actually a point that both Bitwarden and Vaultwarden suffer
Vaultwarden more so in that it is aimed more towards small mom-and-pop businesses or home users, many whom don’t have the time or resources to properly maintain such infrastructure.
Larger enterprises may self-host for many reasons such as security or data privacy compliance requirements, but said larger enterprises will also typically have the resources and personnel required to do so.
When self-hosted there are several factors to consider;
- Hardware has to be maintained (this may be old hardware you already have or part of a home-lab that is used for other things)
- Security is on you, everything from securing the OS and docker layer, to service accounts and SSH connections, to maintenance and software updates.
- Backing up - This is a big one.
Whether it is Bitwarden or Vaultwarden you need to create constant backups of your data. Especially for something as important as a password manager vault. Unless for whatever reason you don’t care about your sensitive, private, and arguably the most important data in your digital life if your password manager is being used correctly.
Backing up your self-hosted instance is not as simple as drag and drop to copy files from one place on the filesystem to another hopefully remote filesystem.
Both Vaultwarden and Bitwarden utilize databases, Bitwarden uses MSSQL, while by default Vaultwarden will use sqlite, but can also be pointed to another backend database such as PostgeSQL, or MariaDB (MySQL).
This now means you are a database administrator, and database backups have to be done in a specific way such that the data is consistent when the backup is created.
Bitwarden makes this fairly easy as nightly backups are automated in the code already and all you have to do is ensure they are backed up off-site.
With Vaultwarden you would need to most likely write a cron job with the appropriate database backup command, and point to where and how you would like these database backups to be handled.
Other data such as attachments, environment settings and other auxiliary files, apart from just the database where logins and notes are stored also need to be continually backed up for a full and easy restore in a disaster scenario.
All this being said, if you are an enthusiast or want to “just because” it is absolutely your prerogative, and only you know your data privacy needs/wants.
For most home/SMB users though I would say 95% of the time and people do not need to self-host and will be better off with the SaaS model provided by Bitwarden.
For those that truly wish to or must self-host, take it from someone who does this type of stuff for a living. You will absolutely want to know and should have a plan for how much work and effort has to go into doing that type of thing properly.
If you are a home-lab person who wants to experiment or also learn then absolutely go for it, but otherwise the piddly subscription for a personal or family premium account is well worth it in my opinion to let Bitwarden’s professional team manage and deal with any issues with their SaaS cloud.
Additional rescources for self-hosted installs of Bitwarden
p.s.
As a side note many of the Vaultwarden users will try to give back to the Bitwarden community as well, either directly with contributions, buying a premium license and just not using it or still in tandem with Vaultwarden, or via community support. As without the upstream team there wouldn’t be an original project to fork, feature additions, and most importantly the client apps which Vaultwarden still completely relies on.
We ran a small internal Vaultwarden instance internally at my company as a trial run for Bitwarden, after having used Bitwarden within our IT department for the better part of two years.
Really helped to show the usage and employee adoption and ultimately sell the package and tool for the official Bitwarden project to our C-suite and approved budget for our employees. Our company can afford to license users and ultimately is where Bitwarden makes its revenue, and I am happy and very glad I could assist in migrating our company to use this tool and supporting this project further.
Bitwarden has even recently added a new addition where enterprise users can get a free family plan sponsored which should help for further adoption of Bitwarden and let our users take this security tool home to their friends and families, and is just another wonderful thing to show how Bitwarden’s main goal is security above all else.
1 Like
Yes I am already running NGINX with my other websites on 443 and 80 and I would like to add Bitwarden to it, thats why I need it
Because I cant answer anymore as I am new here:
Edit 1: Thanks again for your help and investigation, I really appreciate it. Yes in the config.yml you can set the HTTP and HTTPS Port and Ive put it behind the proxy and I was able to accept it, but I was receiving websocket errors. Probably bc of nginx - ah lol I didnt set the Upgrade header - thats what I will try next. Will keep you updated
Edit 2: Indeed Websockets work now. Seems to be fine, mapping to the http port now
Edit 3: I am receiving: [r2d2][ERROR] Unable to open the database file in my bitwardenrs container. Is this something I need to worry about @cksapp ?
1 Like
In regards to this issue, as mentioned Bitwarden typically will install and listen on ports 80 and 443 for certificate renewal and HTTPS traffic. I believe Bitwarden also includes an NGINX reserve proxy already within the swarm and is typically assumed to be the only services running on that machine (or VM) and have those ports 80 and 443 accessible.
I believe there may be a way to have the official self-hosted version set with another port in the environment variables, (there used to be an old forum post here where it is discussed I believe) and possibly also have this behind another reverse proxy of your own choosing and still have that work.
Once home I can check around for further details, and try this out in my home-lab, I have a dev Bitwarden VM for some of these odd use cases I can try with and can let you know what I find.
1 Like