Quelqu’un a tenté Vaultwarden.fr ?
Là mes mots de passe sont sur BitWarden, et avec les infos de la reprise par un acteur douteux je veux en partir.
Ce qui m’intéresse avec Vaultwarden.fr c’est la compatibilité avec les API BitWarden, donc pas de changements sur les applis et extensions auxquelles je suis habitué.
Post
Replies:
10
Boosts:
1
(Ma question porte sur Vaultwarden.fr, à la limite sur Vaultwarden au sens large)
@joachim .fr non, vaultwarden tout court oui — un des premiers trucs que j’ai mis en place au boulot pour remplacer un gestionnaire très obsolète, en 2019 je pense. Rien à redire, ça marche fort bien (enfin l’extension est entièrement compatible et donc a les mêmes problèmes qu’avec bitwarden haha)
J'utilise Vaultwarden via une distri #yunohost perso (sur rpi4 et maintenant rpi5) depuis 4/5 ans.
Cela fonctionne parfaitement avec l'appli et l'extension Firefox BitWarden.
Plutôt satisfait du fonctionnement même si politiquement et techniquement, dépendre de BitWarden est véritablement problématique à moyen et long termes.
@bateausurleau @joachim
J'ai moi aussi #vaultwarden autohéberger via #yunohost . J'avais pas conscience d'un problème politique avec ça. Peut tu détailler? Merci.
Dans la mesure où l'application sur #android et l'extension sont développées par #bitwarden , il me semble que nous faisons face à une forme de dépendance « politiquement » néfaste au regard des pratiques non démocratiques décrites ici : https://blog.ppb1701.com/the-quiet-renovation-at-bitwarden
VaultWarden est toléré par Bitwarden et cette réalité peut être amenée à changer de façon unilatérale de la part du « nouveau » CEO de BitWarden.
En ce sens, il m'apparait que nous avons bien un problème politique ( **Orientation démocratique du projet* versus « gouvernance »)
A Note for Vaultwarden Users
Whether self-hosting stays viable long-term is the real question worth sitting with.
Right now it works because Bitwarden’s clients are open source and the server API is public. Vaultwarden implements that API, and the official apps can’t tell the difference. That depends on Bitwarden continuing to publish open source clients and not restricting which servers they’ll talk to — neither of which is guaranteed under new management.
The brake on the worst case: self-hosting is a listed Enterprise feature that generates real revenue. Killing it upsets paying business customers. That matters.
The catch: what Bitwarden sells to enterprises is their own official server stack, not Vaultwarden. Vaultwarden exists in a space they’ve tolerated but never endorsed. If the calculus shifts, the tolerance ends without any announcement. Just let the API drift until compatibility breaks on its own.
I don’t think that’s imminent. But I also thought the free tier commitment was ironclad, and “Always free” isn’t on the page anymore.
The real safety net is that Bitwarden’s clients are Apache 2.0 licensed. A fork would need a rebrand to stay clear of the trademark — different name, tweaked UI, same engine — but that’s a speed bump, not a wall. The web vault works through any browser regardless of what happens to the apps, so worst case you’d lose autofill temporarily while a fork caught up. Inconvenient, not catastrophic. Vaultwarden itself is already proof the model works.
Watch the clients. If they go closed, the community will notice fast, and the fork will follow.
@joachim Vaultwarden s'héberge facilement. Sinon, que tu passes via une offre gérée ou en auto-hébergement, tu dépends toujours des extensions et applications publiées par Bitwarden pour les clients.
@joachim vu que tu héberges déjà un monstre en ruby, tu peux héberger vaultwarden 😊 c'est super light, y a pas vraiment de maintenance à part le mettre à jour (et faire un backup tous les jours).
@aspyrine j’héberge aussi quelques monstres en Python, un monstre en Go, une abomination en PHP, mais du Rust ? Pas encore :)
