How "locked in" are we to upstream? #244

Closed
opened 2026-02-04 18:55:40 +03:00 by OVERLORD · 2 comments
Owner

Originally created by @pdarcos on GitHub (Mar 6, 2019).

My question may seem silly but I don't find a clear answer anywhere.

The whole point of bitwarden_rs is to have our own self-hosted option that's not too heavy nor dependent on the official bitwarden.

I see lots of parts in the code that still reference bitwarden, which is fine until Kyle changes something upstream or blocks access to some api or service that bitwarden_rs is consuming from bitwarden.

So my question is how dependent are we to changes upstream? If bitwarden were to shutdown or otherwise block access how would we cope? Ideally we'd have everything on our backend and wouldn't be impacted if something happens to bitwarden, but I'm not sure we're there yet.

Can someone enlighten me on this question?

Thanks and keep up the awesome work

Originally created by @pdarcos on GitHub (Mar 6, 2019). My question may seem silly but I don't find a clear answer anywhere. The whole point of bitwarden_rs is to have our own self-hosted option that's not too heavy nor dependent on the official bitwarden. I see lots of parts in the code that still reference bitwarden, which is fine until Kyle changes something upstream or blocks access to some api or service that bitwarden_rs is consuming from bitwarden. So my question is how dependent are we to changes upstream? If bitwarden were to shutdown or otherwise block access how would we cope? Ideally we'd have everything on our backend and wouldn't be impacted if something happens to bitwarden, but I'm not sure we're there yet. Can someone enlighten me on this question? Thanks and keep up the awesome work
OVERLORD added the question label 2026-02-04 18:55:40 +03:00
Author
Owner

@dani-garcia commented on GitHub (Mar 6, 2019):

I'm not sure what do you mean by references or dependencies to upstream, the only thing where we ever depended on the upstream service was the icon fetching service, but that was replaced on the last release.

Other than that, the server is completely self contained. The most likely upstream-related problem is if the clients get updated and the update contains a breaking change, but I don't expect that to happen very often, and it's usually a simple change.

That said, we still depend on the clients being maintained and allowing the user to configure the server, but I can't see that changing any time soon, as in my opinion it's one of the biggest features of bitwarden in the first place.

@dani-garcia commented on GitHub (Mar 6, 2019): I'm not sure what do you mean by references or dependencies to upstream, the only thing where we ever depended on the upstream service was the icon fetching service, but that was replaced on the last release. Other than that, the server is completely self contained. The most likely upstream-related problem is if the clients get updated and the update contains a breaking change, but I don't expect that to happen very often, and it's usually a simple change. That said, we still depend on the clients being maintained and allowing the user to configure the server, but I can't see that changing any time soon, as in my opinion it's one of the biggest features of bitwarden in the first place.
Author
Owner

@pdarcos commented on GitHub (Mar 6, 2019):

Thanks @dani-garcia You answered my question completely.
I think I was getting confused because I remembered reading somewhere that we were still dependent on upstream for some services: I guess the icon fetching service was it and now that's been updated too :)

@pdarcos commented on GitHub (Mar 6, 2019): Thanks @dani-garcia You answered my question completely. I think I was getting confused because I remembered reading somewhere that we were still dependent on upstream for some services: I guess the icon fetching service was it and now that's been updated too :)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/vaultwarden#244