this post was submitted on 29 Jun 2025
60 points (95.5% liked)

Selfhosted

48773 readers
967 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 2 years ago
MODERATORS
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
60
Reevaluating my password management (sh.itjust.works)
submitted 1 day ago by [email protected] to c/[email protected]
53 comments fedilink hide all child comments
 

It never made sense to me to put password managers in the cloud. Regards to what you intend it to do, you’re making it accessible to a wider audience than necessary. And yet, I’m using iCloud. It’s time for a change.

I’m thinking of just running a locally hosted password manager on my home server and letting my devices sync with it somehow when I’m at home. I have a VPN into my home network when I’m away that automatically triggers when I leave the house, so even that’s not that big an issue, but I’m really not familiar with what’s gonna cleanly integrate with all my stuff and be easy to use. All I know is I wanna kill the cloud functionality of my setup.

I already have a jellyfish server so I figured I would just throw this onto that. Any suggestions?

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 44 points 22 hours ago (3 children)

Why not use KeepassXC? It's a completely local encrypted db but it integrates with cloud storage apps like nextcloud for sync. It has plugins for integration with Firefox and KeepassAndroid is pretty smooth on the current Android OS.

[–] [email protected] 4 points 17 hours ago* (last edited 16 hours ago) (1 children)

Shamelessly shilling my OSS project, rook. It provides a secret-server-ish headless tool backed by a KeePass DB.

  • Headless server
  • Optional and convenient integration with the kernel keyring (on Linux), for locking the server to only provide secrets to the user's session
  • Provides a range of search, list, and get commands
  • Minimal dependencies and small code base make rook reasonably auditable

You might be interested in rook if you're a KeePassXC user. Why might you want this instead of:

  • Gnome secret-server, KDEs wallet, or pass? rook uses your (a) KeePass DB, while most other projects store secrets in their own DBs and require (usually manual) sync'ing when passwords change.
  • One of the browser secret storage? Those also keep a bespoke DB which needs to be synced, and they're limited to browser use. Rook supports using secrets in cron jobs or on the command line (e.g. mbsync, vdirsyncer, msmtp, etc, etc).
  • KeePassXC? KeePassXC does provide a secret service that mocks Gnome secret-service, but you have to keep KeePassXC (a GUI app) running even if you only rarely use the UI. Rook can also be used on a headless machine.
  • The KeePassXC command line tool? That requires entering the password for every request, making it tedious to use and impractical for automated, periodic jobs.

Rook is read-only, and intended to be complementary to KeePassXC. The KeePassXC command line tools are just fine for editing, where providing a password for every action is acceptable, and of course the GUI is quite nice for CRUD.

[–] [email protected] 1 points 11 hours ago

Damn, that sounds very interesting! The use of a Keepass DB instead of a new one makes it great to have as option. It's something I hadn't think about for a long time.

I'll check it out later and maybe install it after I restore my server, I'm planning to reduce my attack surface too:)

[–] [email protected] 10 points 21 hours ago

Yup this is the way. The resulting .kdbx database file is encrypted so you can even synchronize it over an untrusted provider. Otherwise you can use something like syncthing to keep it strictly peer to peer.

[–] [email protected] 9 points 22 hours ago* (last edited 22 hours ago) (1 children)

this one, OP. no need to introduce the horror that's a:

  • hosted app (why?!)
  • client app is electron crapware
  • the client app doesn't even have full functionality, you have to use the web UI for some tasks

edit: I'm obviously speaking about the bitwarden/vaultwarden horror. keepassXC is none of them things.

[–] [email protected] 7 points 19 hours ago

KeepassXC is the only thing that makes sense to me.

I don't want all my passwords stored with some huge target like lastpass or bitwarden.

Encrypted local (and synced) DB is the only way.