I’m looking into different self hosted open source multiuser password safes and while there are many options I haven’t found one with a .deb or .rpm install - only a whole bunch of docker compose.
Do you know of any good options that are included in debian 12 or fedora 39 repositories or at least that has a .deb or .rpm?
Currently I’m using keepassxc but been asked for something that either has a webui login for end users or an android app.
edit 2024-02-17:
After looking into the .deb and .rpm options available (passbolt or unofficial vaultwarden-deb) I decided to bite the bullet and install a debian 12 vm that I will try out different docker solutions on.
Vaultwarden is simpler to selfhost implementation of Bitwarden server fully compatible with it’s apps.
ArchLinux have the server in official repos.
For Debian (.deb) I have found this unofficial repo: https://github.com/gvtulder/vaultwarden-deb Be mindful it suggests stupid installation method by downloading and executing the install.sh script directly, you may want to read it yourself before install.
For .rpm I haven’t find any repositories that are actively maintained, but you may have more luck.
Thanks for the recommendation! Gonna look into vaultwarden-deb.
There are keepass android apps like KeePassDX. You can have server sync with WebDav, but I don’t know about shared databases. Should work if you configure the WebDav server etc.
A friend of mine is a big fan of bitwarden but I have no Idea if that fits your requirement. Should have a webui tho.
The problem with the KeePass apps is that it works by syncing database files which means that there can be sync conflicts. Okay for me to handle, but not for the rest of my household.
I really want a server-client system where everyone works in the same database.Bitwarden is Docker, but also very well-liked. Might have to give up on the .deb / .rpm wish.
Thanks for the suggestion!KeepassXC implements a specific shared mode which is made to avoid conflicts.
I have no idea why no one uses it, I use it, works well.
This is the reason I don’t use a shared database, I think that’s what you’re referencing?
Add ability to sync group structure with KeeShare - Status:Open
https://github.com/keepassxreboot/keepassxc/issues/3045KeyShare is, this issue is specifically about groups within KeyShare, you can create one KeyShare for each group if you require groups.
Would work if it was planned to be a system used by only techies or if we knew exactly what groups are wanted beforehand. Definitely gonna remember the tip, splitting it into several shared dbs didn’t even hit me as an option.
I use it too, works just fine.
The usual go to for self hosted password managers is VaultWarden. There’s no deb or rpm package but you can get it spun up with docker pretty easily. Any reason you’re specifically looking for “included” or packaged solutions? That’s going to severely limit your options.
A quick search led me to Passbolt which has multiple user support, native installs for both Debian and Fedora (you’ll need to add their repo manually, though) and an Android app, so it seems to fit all your criteria.
Just curious, are there any specific reasons you wish to avoid docker?
Easier for me to add a vm in my current system to handle backup, rollbacks and system updates. I’m much more confident that I can quickly restore a vm to new hardware f.e. Which feels important for a password vault.
Thanks a lot for the passbolt recommendation. Gonna look into it now!
FYI, if you run vaultwarden using docker compose with your data volume as a folder, all you have to do is bring it down for like 1minute, make a backup of the folders, and bring it back up. I use a cron script to do this nightly. When my vps host went out of business, I restored my docker folder to a new vps and was up and running again in a couple minutes. Also, you could easily restore it to a virtual machine, if you like. Docker with compose is extremely portable.
Stupid q but why is the stop/start necessary? I’m running VW (and a dozen other things) thru docker on a synology dsm and it performs backups daily+monthly. Is it actually necessary to stop the container just to copy it?
I’ve read that best practice is to do a database dump, in addition to backing up all the data files. It’s my understanding that there’s a slight chance of corrupting something in the database if you don’t stop the service first, since something could be changed while you’re doing your backup.
The easiest solution for me, as well as for being able to just restore my files and start the service again somewhere else, is to stop, backup, and restart. It’s down for less than 5 minutes while i’m asleep. If I expected better uptime than that I wouldn’t be trying to self host.
If you’re already using a VM anyway (especially for the backend/web UI piece) restoring the image won’t be any different for a server running docker vs one running apt packages.
True, I could use VM+Docker as you say. I’ve been thinking of making a dedicated “Docker VM” before when I’ve looked at interesting projects that has no other offerings.
I’ve felt that using docker in a vm robs docker of it’s advantages so why use it at all if I’m planning on having a vm? I guess one answer is “because the software you want is delivered as a docker image”.It may seem like unnecessary overhead, but dockerized vaultwarden in a VM has been a huge improvement for me compared to unix-pass.
And with the volumes set up right, moving it is as easy as copy/pasting the folder it all lives in.
Sounds like I should get my docker vm. :)
deleted by creator
Bitwarden have deb and rpm support.
Only client side from what I can find. The server seems to be Docker based.
Server side is more complex. So for serverside you will be hard to find non docker og non manual installasion.
Passbolt and Vaultwarden has been recommended so far. Gonna look into them later! :)
Vaultwarden is a lightweight server of bitwarden.
Alternative implementation of the Bitwarden server API written in Rust and compatible with upstream Bitwarden clients*, perfect for self-hosted deployment where running the official resource-heavy service might not be ideal.
