#1 is a problem with the client's code, I don't know any easy workaround. Usually a long-running transaction means you're accidentally waiting on stuff like RPCs in the middle, or maybe doing something that doesn't really need to be in a xact.
#2, shouldn't the client<->PgBouncer connections stay open?
#3 is why I just use client-side pools instead of PgBouncer, but that gets annoying when you have a replicated service so you have to think about the sum of connections across all pools, so I get why people use PgBouncer.
I don't care about raising prices, I'm worried about the new CEO having a PE mindset. That means Bitwarden will now focus on extracting value while the product stagnates and degrades in quality. Time to jump ship before their security and quality goes down the drain.
Not my project but Vaultwarden is an open source (in Rust) alternative backend for Bitwarden. I believe its been around a while, and is still maintained.
I’ve used Vaultwarden for at lesst 7 years, I’m sure for longer but I’m not sure how long.
Never had an issue with Vaultwarden itself. Restored from backups several times for a variety of reasons (migrating host, corrupt hard disk, re-installs) and that always worked first try.
That guide is wild. By default it allows public registration, shows password hints, requires a reverse proxy for robust TLS but then passes tokens via GET params, runs in the container as root. Recommends fail2ban because it doesn't have any coverage against brute force. Recommends using a custom path for security.
This feels less like a guide on hardening Vaultwarden than a guide on why I should be skeptical about it.
I’m not an expert with web sockets or web development - but re: Get Params, Vaultwarden has to follow the API of the upstream Bitwarden implementation:
The part I found jarring was that it will totally do TLS for you but using a TLS stack they don’t recommend, and if you put it behind a reverse proxy you also need to know to do custom log redaction to avoid logging tokens.
They’re design choices where the default that has been chosen is dangerous for somebody deploying the software. Plenty of web apps do not have those pitfalls.
I have my vaultwarden running on a container on my home-lab server acessible only from Tailscale. The container itself is only accessible as its own node on my Tailscale private network and can’t be reached any other way (there are no inbound port forwards for the container itself, tailscale handles this)
My phone and laptop both use tailscale to access this and a few other containers I have set up similarly. I also have tailscale ACL rules to limit just “me” or whomever I want to allow to use it (family etc) also on my tailnet.
Backups are encrypted and stored locally as well as to AWS glacier.
What would happen if you lost access to phone and laptop? Is there another "backup" device, or a mechanism to register a new device to your Tailscale network that doesn't require vaultwarden?
I've never had a reliability issue with Vaultwarden. Hosted it 5+ years now. Even with random off/on of the server and other bumps in the road in life, the Docker container I run has had no issues with hosting. The user interface is friendly but can be just a little slow.
Mine is not exposed to the public internet, though some friends of mine do. I use a VPN when I need to access fresh data from the home server, otherwise both the Firefox client and Android client will generally keep a cache of the last data pull when they had connection (so it wasn't an issue the 4 or so years I didn't have a VPN yet).
By not exposing it to the wider internet. When I use a client (iPhone, browser, etc.) while on the home network, it syncs. While off the network, the last synced data is still there. That's been good enough for me.
When the server can’t be accessed, you can’t create a secret, right? This has been quite annoying in my experience. I’d still recommend Bitwarden clients with self-hosted Vaultwarden.
I've got it running in an LXC container. Other than occasionally updating it, it's been entirely trouble free (I did need to work to get it out of the Docker container but that's a problem most won't have). Honestly one of the most useful and low trouble self-hosted apps I've used next to Dokuwiki. As far as hardening, I have not done a huge amount, but it lives on my LAN and is only reachable via VPN from the outside, which again works surprisingly well even with my Android phone.
I just take ZFS snapshots. I've restored a couple of times that way just to test DR and it worked pretty well.
Not technical, but the person behind that project now works for Bitwarden so there's some risk of a rugpull. Of course it's OSS but you'll need to trust a fork or maintain it yourself if said rugpull happens.
The maintainer has said that they've been given permission to maintain it in their free time. All it takes is a bad quarter and the CEO decides they don't want to be supporting a competitor and that goes away. It's possible that a community continuation could happen but I wouldn't rely on something so uncertain for something as important as credentials.
It’s a bad strategy. I am capable so I host an instance of vaultwarden for myself and spouse (only available via our vpn)
But when friends and family ask for my recommendation I send them to Bitwarden and they pay for the service.
If it wasn’t for vaultwarden and the clients being open source I would not be using it nor recommending it.
I’d probably still be using keepass with manual sync and when friends and family ask for suggestions I’d probably shrug and say I don’t trust any of them.
The expansion of "rugpull" to encompass "a company or open source developer changing the roadmap or level of investment in something they develop" is fascinating.
No matter where Bitwarden ends up, passwords are one of these few things I am very hesitant to self-host. The stakes are just too high, and my knowledge of security has too many unknown unknowns to take that risk.
Personally, I want to avoid the responsibility for hosting it myself. I'm happy to pay for that. But a reasonable amount. Today Bitwarden's price is fine for me, but I worry about what's coming.
Don't I have to rely on the OG frontend/GUI components, though? They are one automatic update away from bundling taking custom server address away with important security fixes, in a way that you are damned if you do and damned if you don't.
Technically yes but the frontend is so far open source so forking that is also something that could technically happen if company ever went back on it.
There is not an alternative frontend that I'm aware of, but as the article mentions, the clients are Apache 2.0 licensed, so in the event of a rug pull, a fork and rebrand of the clients would be what is needed to restore service.
I’m happy to pay for good services, but M&A means cost-cutting measures to make the company look good for acquisition and that makes me uncomfortable with letting them store secure data for me.
I’m not buying hosting from a password manager, I’m buying security. I don’t have complete confidence that I can secure a self-hosted password manager and it’s not an area where I want to take risks.
It's very simple, just don't make it accessible outside your home network. Clients sync when the server is accessible and use last synced data otherwise.
The effort required to set this up far outweighs the price to pay someone to do it for me.
I pay a cleaner, I have a dishwasher, I pay someone to do my taxes, I pay for companies to host software.
Then again, I never order food and almost never get takeaway, as cooking is nice and I value my food enough to care what goes in it. Cheaper too, easily offsetting what I pay for my password manager.
Tailscale for your laptop, phone, etc. to be able to talk to the other computers when away from your home WiFi. (Optional, but makes syncing easier).
Syncthing, talking to your Tailscale IP addresses if you use it, or your private WiFi network addresses if you don't use Tailscale.
One folder synced, containing keyfile2.kdbx.
30 minutes to set up and then you almost never need to think about it again. If you don't trust Tailscale, you can run a Headscale server or just not use it. And the syncing is entirely run on your machines; your data never ends up written to someone else's SSD.
I mean does it? I have set it up before but I just set it up for my new small office team. I already had an internal server and WireGuard vpn in our office and it took 2 minutes to create a quadlet to run vaultwarden and a few more to configure it. The “hardest” part was training the team on how to use collections.
I'm so fucking tired of jumping ship with these password vault providers. This will be my third jump in so many years.
Exactly what value do they think they have left to extract from me? I'm a paying customer for a product that essentially just stores an indexed list of strings with at-rest encryption.
Their official App's autofill on my phone hasn't worked for several months now., I literally have to login to it once every couple hours just to manually copy and paste my usernames and passwords separately. I guess enshitification knows no bounds?
Me too precisely. But after getting acclimated to a self hosted vaultwarden for the backend and beginning to explore some of the 3rd party Bitwarden frontends that implement its API, I’d recommend hanging in there a bit longer. I think there may be a moat around BW already for self-hosting.
What’s next in the circle is keepass I guess? And it’s just not friendly/robust enough yet for me to switch to it with my family who will probably just go back to using the same passwords on multiple sites if they hit resistance in ease of use.
I'm getting really tired of the enshittification cycle. Learning about android verification and captcha changes recently has been another big frustration point. I moved to android as a more open alternative to apple just a few years ago, and to bitwarden from lastpass around the same time. I would like to just have these infrastructural services work well and quietly without thinking about them for many years. Do I really have to put up with this happening faster and faster for the rest of capitalism? (I think so)
>Do I really have to put up with this happening faster and faster for the rest of capitalism? (I think so)
no, if you relax the qualifier "without thinking" slightly and are okay with thinking for a few hours. There's so many off-the-shelf open source solutions now to just throw on a 5 bucks VPS, it costs you less time and money than switching or the premium plan of most of these individual services.
The point is that if there are only one or two red flags, you can risk assess them and continue as is if the risk is low. But if there are a large number of red flags, then you need to consider your exit strategy as well.
I don’t wait for companies to enshittify anymore. When they start making decisions that look like they’re heading in that direction, I start looking for alternatives.
yet. The hallmarks of enshittification are there. We've all been through the cycle of "this product is too good to be true, and provides considerably more value than it costs" "Customer Acquisition/Market Capture" phase. And we know what has to come next. They have to make the product profitable, because you cant just burn up VC money forever.
I don't know if it is exactly the same proverb -- it isn't about objecting to the bear (or boar) shitting in the woods, it is about our ability to infer that the bear shits in the woods even if we have never seen it happen. We know the bear shits, we know the bear lives in the woods, even people who have lived in the city their entire life and have never seen bear shit can infer that the bear shits in the woods.
In context, my intended meaning was that software enshittification works the same way: we don't have to see a particular private equity firm enshittify a particular piece of software to know that they do enshittify software, just as we do not have to see a bear shit in the woods to know that the bear does shit in the woods.
Vendors doing a rug-pull isn't just capitalism. China is adding DRM to AM radio: old receivers won't work. Heck, Soviet WWII ration cards no longer give turmips.
They're not doing it to increase margin. "Enshittification" or "rug-pulls" aren't when things get worse or things change, they're when the conditions that were used to attract an audience are changed in order to extract more margin after that audience is captured.
The larger exampls to compare them to would be "dumping." Dump subsidized, tariff-free corn in Mexico to make it unprofitable to farm corn in Mexico, and after all of the Mexican farmers go bust, buy their land and raise the price of corn to infinity while cheaping out on the quality of seed and handling. Enshittification. Rug-pull.
I'm building an AI Dashboard & AI Leaderboard where you can see who generates the most lines of code using Codex, Claude, Copilot, Cursor, etc. https://wakatime.com/ai
Your kids need to learn how to clean up after themselves.
All you need is a camera pointing at the floor with image detection... when there's legos on the floor it triggers a video playing that explains how the kids need to pick up the legos. /s
Actually, a camera that scores the clean up progress, together with some virtual gold coins and real loot boxes for a week of good compliance might really do the trick.
> I removed my phone number from the account. I am travelling to the UK for a short period and did not want to have roaming on my Australian phone.
So for my own notes, removing a phone number from my Google account before travel will risk account suspension. Hope OP resolves it, but also need to make sure this never happens to me.
Damnit, now I probably have to update my vscode plugin to support Cursor 3... I mean have a coffee or go for a swim while waiting on AI to update my vscode plugin to support Cursor 3. :P
1. pool exhaustion from idle connections inside open long-running transactions
2. SQLAlchemy's client-side pool using dead connections that PgBouncer had already killed, causing periodic request errors
3. Some tasks have to bypass PgBouncer when they use SET or prepared statements
I've already sharded large datasets at the application layer, but looks like PgDog solves the above problems for any future work?
reply