Selfhosted
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:
-
Be civil.
-
No spam.
-
Posts are to be related to self-hosting.
-
Don't duplicate the full text of your blog or readme if you're providing a link.
-
Submission headline should match the article title.
-
No trolling.
-
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.
-
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:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
view the rest of the comments
why not vaultwarden?
If I'm going to have to host my own infrastructure, I don't want it tied to Bitwarden, given the new direction of the company.
I fully support Vaultwarden though, and I wish them well.
I'll be going with KeyPassXC and Syncthing.
Vaultwarden (and all the client apps) depend on Bitwarden for the API spec. If Bitwarden introduces closed features in the API that Vaultwarden can't/won't implement, but the client apps do, it will split the spec. They can also introduce API license keys, which would render Vaultwarden mostly irrelevant.
The only way for Vaultwarden to remain relevant going forward is to own it and split ways from Bitwarden. This would in turn mean that the FOSS client apps have to decide which to support. But I think the ecosystem is going to fragment eventually anyway, so the sooner every app decides which way they want to go, the better.
Or you could just fork it when there's a problem
Sounds like you're volunteering to do that additional amount of work.
History shows this will happen. Or do you have any counter example?
Mariadb, libreoffice and most recently OpenCourant
Not arguing against it of course, just dislike when people make forking (and establishing a whole new standard) sound like not that big of a deal.
well, the first step of forking is clicking a button or execting a "git clone" command. thats trivial. publishing to android is a bit of work, but very one-time.
keeping up with development is a different story - but many foss projects thrive with support from whoever needs to have something fixed.
You'll also have to convince other maintainers to adopt the new API in this case, otherwise it's pointless. Vaultwarden is only the server, you'd at least require one third-party client (e.g. Keyguard) to add and maintain the Vaultwarden API and probably also someone to fork the browser plugins. This whole issue is quite involved.
I highly doubt future compatibility. Things will diverge. I care about having a good hostable password manager. I don't care about the name of the client or if it's compatible with some closed source shit.
When presented a hypothetical between the commenter suggesting it be
A) forked now
And me suggesting
B) forking when there is a problem
You elect C) the commenter does the work?
Brilliant contribution
I'm. Using Vaultgarden but its not clear if the Android app will still be available.
I've been very happy with Vaultwarden+Keyguard
https://keyguard.dev/
Edit: I had not looked closely enough at the license and did not realize it's not FOSS, my bad
But that's not Foss, so I didn't consider it
It is free and open-source on Desktop at this moment.
But it makes sense to pay for it, since Bitwarden is a constantly changing system and these projects based on it must always be up-to-date with their API changes, too. This is time and worry consuming, and should be compensated.
License is: all rights reserved.
That's free like in beer, and open like 'allowed to inspect' that's not what most people mean when they talk of Foss.
source: https://github.com/AChep/keyguard-app/blob/master/LICENSE
Thank you for pointing this out- I'd managed to completely miss that it seems. That's unfortunate
Roger that. Thank you for the clarification that you meant the actual term, and not just the fact of no mandatory payment and it having an the source available for public.
I get what you mean, yet frankly, I do not believe such projects may be always free that are supposed to always be up-to-date for another system they have no official relation to, and keep it as a responsible hobby other people depend on.
It currently doesn't work with Vaultwarden. The Linux client doesn't accept custom certificates. And the Android client is paid. It is a dead-end for self-hosting.
The license is also stupidly a single sentence. Which means that use could be nuked at any minute, and any money you use to pay the developer means nothing. If they wanted to kill the project today and nuke the repo, you have no legal rights, the project dies and fuck you and your passwords. That doesn't exactly inspires confidence.
Thank you for pointing out that the license is not FOSS, I hadn't noticed that. I suppose I'll be exploring my options again.
I'd been using the Android client from f-droid and hadn't needed to pay for it, which was working with my VW server. On my desktop/laptop I use rbw, so I hadn't noticed the cert issues with the kekeyguard desktop client.
Thank you very much for the awesome project mentioned! I had no idea about it!
The marvel works great with Vaultwarden, too, it seems!
Though, Bitwarden system/clients are not so featureful as KeePassXC, for example, it's a great alternative for a more adequate synchronization.
Awesome!
There will be... Some fork at least