this post was submitted on 29 Jun 2025
78 points (96.4% liked)

Selfhosted

61103 readers
701 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:

Detailed Rules Post

  1. Be civil.

  2. No spam.

  3. Posts are to be related to self-hosting.

  4. Don't duplicate the full text of your blog or readme if you're providing a link.

  5. Submission headline should match the article title.

  6. No trolling.

  7. Promotion posts require active participation, with an account that is at least 30 days old. F/LOSS without a paywall has exceptions, with requirements. See the rules link for details. Tags [CBH] or [AIP] are required, see the links in Rule 8 for details.

  8. AI-related discussions and AI-involved promotional posts have additional requirements for tagging, as noted in Rule 7 and the AI & Promotional Post Expanded Rules post, and find example disclosures here.

Resources:

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

Questions? DM the mods!

founded 3 years ago
MODERATORS
ruud@lemmy.world
Loki@lemmy.world
CannaVet@lemmy.world
devve@lemmy.world
ayyy@sh.itjust.works
curbstickle@anarchist.nexus
curbstickle_lw@lemmy.world
78
Reevaluating my password management (sh.itjust.works)
submitted 1 year ago by muusemuuse@sh.itjust.works to c/selfhosted@lemmy.world
65 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
[–] dr-robot@fedia.io 53 points 1 year ago (4 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.

[–] unexposedhazard@discuss.tchncs.de 15 points 1 year 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.

[–] glitching@lemmy.ml 11 points 1 year ago* (last edited 1 year 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.

[–] null_dot@lemmy.dbzer0.com 8 points 1 year 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.

[–] sxan@midwest.social 6 points 1 year ago* (last edited 1 year 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.

[–] not_amm@lemmy.ml 2 points 1 year ago (1 children)

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:)

[–] sxan@midwest.social 2 points 1 year ago

If you do, use the -k option - it locks access to the rook service to only the user session. Rook works without it, but is more secure with it.

[–] oyzmo@lemmy.world 1 points 1 year ago

Any iOS app?