love this. one person, 119GB, two drives, rsync. no kubernetes, no distributed cluster, no nonsense. just works.<p>this is the kind of setup that lets you actually go to bed without checking your phone every 20 minutes.
For S3 self-hosters check out Garage, who are developing with NLnet funding: <a href="https://garagehq.deuxfleurs.fr" rel="nofollow">https://garagehq.deuxfleurs.fr</a>
> In March 2026, I migrated to self-hosted object storage powered by Versity S3 Gateway.<p>Thanks for sharing this, I wasn't even aware of Versity S3 from my searches and discussions here. I recently migrated my projects from MinIO to Garage, but this seems like another viable option to consider.
As a user for over a decade, just here to submit my appreciation. healthchecks.io is fantastic.
I don't get it, if it's running on the same (mentioning "local") machine, why does it even need the S3 API? Could just be plain IO on the local drive(s)
The app was already built against the S3 API when it used cloud storage. Keeping that interface means the code doesn't change - you just point it at a local S3-compatible gateway instead of AWS/DO. Makes it trivial to switch back or move providers if needed.
(Author here) There are multiple web servers for redundancy (3 currently), and each needs access to all objects.
If the app was written using the S3 API, it would be much faster/cheaper to migrate to a local system the provides the same API. Switching to local IO would mean (probably) rewriting a lot of code.
seperate machine I think given the quoted point at the end:<p>> The costs have increased: renting an additional dedicated server costs more than storing ~100GB at a managed object storage service. But the improved performance and reliability are worth it.
The S3 API doesn't work like normal filesystem APIs.<p>Part of it is that it follows the object storage model, and part of it is just to lock people into AWS once they start working with it.
I'm 100% aware of how S3 works. I was questioning why the S3 API is needed when the service is using local storage.
Apart from all these other products that implement s3? MinIO, Ceph (RGW), Garage, SeaweedFS, Zenko CloudServer, OpenIO, LakeFS, Versity, Storj, Riak CS,
JuiceFS, Rustfs, s3proxy.
What kind of vendor lock-in do you even talk about. Their API is public knowledge, AWS publishes the spec, there are multiple open source reference client implementations available on GitHub, there are multiple alternatives supporting the protocol, you can find writings from AWS people as high in hierarchy as Werner Vogels about internals. Maybe you could say that some s3 features with no alternative implementation in alternative products are a lock-in. I would consider it a „competitive advantage”. YMMV.
> part of it is just to lock people into AWS once they start working with it.<p>This is some next-level conspiracy theory stuff. What exactly would the alternative have been in 2006? S3 is one of the most commonly implemented object storage APIs around, so if the goal is lock-in, they're really bad at it.
> What exactly would the alternative have been in 2006?<p>Well, WebDAV (Document Authoring and Versioning) had been around for 8 years when AWS decided they needed a custom API. And what service provider <i>wasn't</i> trying to lock you into a service by providing a custom API (especially pre-GPT) when one existed already? Assuming they made the choice for a business benefit doesn't require anything close to a conspiracy theory.<p>And it worked as a moat until other companies and open source projects started cloning the API. See also: Microsoft.
WebDAV is kinda bad, and back then it was a big deal that corporate proxies wouldn't forward custom HTTP methods. You could barely trust PUT to work, let alone PROPFIND.
WebDAV is ass tho. I don't remember a single positive experience with anything using it.<p>And still need redundant backend giving it as API
Or a simple SAN
So you don't need to refactor your code?
And when/if you decide to head back to a 3rd party it requires no refactoring again.
yeah, sure, those 5-10 different API calls would surely be a huge toll to refactor... I'd rather run an additional service to reimplement the S3 API mapping to my local drive /s
It's interesting that cloud providers are unable to provide stable S3 as a service. Hetzner is unable to deliver stable object storage, but given the article neither are OVHCloud and UpCloud.
Self Hosted object storage looks neat!<p>For this project, where you have 120GB of customer data, and thirty requests a second for ~8k objects (0.25MB/s object reads), you’d seem to be able to 100x the throughput vertically scaling on one machine with a file system and an SSD and never thinking about object storage. Would love to see why the complexity
(Author here) that's more or less what I have right now – one machine with a file system and an SSD. S3 API on top is there to give multiple web servers shared access to the same storage. I could have used something else instead of S3 – say, NFS – but there was a feature request for S3 [1] and S3 has a big ecosystem around it already.<p>[1] <a href="https://github.com/healthchecks/healthchecks/issues/609" rel="nofollow">https://github.com/healthchecks/healthchecks/issues/609</a>
The complexity for that is almost always for redundancy and for ease of deploys.
"Our current (April 2026) object usage is: 14 million objects, 119GB"<p>I mean, I appreciate the openness about the scale, but for context, my home's personal backup managed via restic to S3 is 370GB. Fewer objects, but still, we're not talking a big install here.<p>This is pretty much like that story of, if it fits on your laptop, it's not big data.
I'm sure it's a lot better now but everytime I see btrfs I get PTSD.
Same here. Had a production node running btrfs under heavy write load (lots of small files, frequent creates) and spent two days debugging what turned out to be filesystem-level corruption. Switched to ext4 and never looked back. The article doesn't mention what filesystem sits under Versitygw here, which seems like a pretty relevant omission for anyone thinking of replicating the setup.
I'm a little surprised it's not ZFS. Too difficult to add to their Linux environment? That's still a problem here in 2026.
Same, and reasoning around inodes feels easy fixed by just upping inode per KB from 16k to 4k which is likely block size anyways.
I hit a panic in btrfs using an ubuntu 24 LTS kernel. The trauma is still well and alive.
I'd worry about file create, write, then fsync performance with btrfs, but not about reliability or data-loss.<p>But a quick grep across versitygw tells me they don't use Sync()/fsync, so not a problem... Any data loss occurring from that is obviously not btrfs fault.
Care to elaborate? I've heard good things about it, but am personally a ZFS user.
> The costs have increased: renting an additional dedicated server costs more than storing ~100GB at a managed object storage service. But the improved performance and reliability are worth it.<p>Were your users complaining about reliability and performance? If it cost more, adds more work (backup/restore management), and the users aren't happier then why make the change in the first place?
great writeup. Is s3 a customer or internal requirement? Why not write to your disks? Easily 1/3 - 1/5 the price and better performance.
Moved object storage from AWS to CloudFlare and have been pretty happy. No problems with performance so far. Bills were 90% cheaper too (free bandwidth)
As someone who has dealt with wacky storage issues/designs, a lot of this "felt" strange to me. Btrfs? Rsync? Then I got to the bottom and saw that they were only handling about 100 GB of data! At that scale, nearly anything will work great and TFA was right to just pick the thing with the fewest knobs.<p>At a previous job years ago, we had a service that was essentially a file server for something like 50TB of tiny files. We only backed it up once a week because just _walking_ the whole filesystem with something like `du` took more than a day. Yes, we should have simply thrown money at the problem and just bought the right solution from an enterprise storage vendor or dumped them all into S3. Unfortunately, these were not options. Blame management.<p>A close second would have been to rearchitect dependent services to speak S3 instead of a bespoke REST-ish API, deploy something like SeaweedFS, and call it a day. SeaweedFS handles lots of small files gracefully because it doesn't just naively store one object per file on the filesystem like most locally-hosted S3 solutions (including Versity) do. And we'd get replication/redundancy on top of it. Unfortunately, I didn't get buy-in from the other teams maintaining the dependent services ("sorry, we don't have time to refactor our code, guess that makes it a 'you' problem").<p>What I did instead was descend into madness. Instead of writing each file to disk, all new files were written to a "cache" directory which matched the original filesystem layout of the server. And then every hour, that directory was tarred up and archived. When a read was required, the code would check the cache first. If the file wasn't there, it would figure out which tarball was needed and extract the file from there instead. This only worked because all files had a timestamp embedded in the path. Read performance sucked, but that didn't matter because reads were very rare. But the data absolutely had to be there when needed.<p>Most importantly, backups took less than an hour for the first time in years.
Given the individual file size and total volume, I'd argue it make sense to use move to local only storage.<p>On a separate note, what tool is the final benchmark screenshot form?
> Our S3 API is now served by Versity S3 Gateway and backed by a plain simple Btrfs filesystem.<p>With apologies to the SRE Book ("hope is not a strategy")... Btrfs is not a strategy.