> S3 support sounded like the "enterprise-ready" checkbox to tick. It was actually a bet against the entire premise of the project. It's gone now, here's why.
> Source: https://orochibraru.com/blog/why-penombre-is-dropping-s3-support · Site index: https://orochibraru.com/llms.txt

# Why Penombre dropped S3 support

*19 September 2026*

Penombre no longer supports S3. It's already out, shipped in a recent release. Not because it was broken, but because it was a mistake to add in the first place, and I'd rather admit that in public than pretend it was a deliberate roadmap decision.

## The pitch that talked me into it

Nobody asked for it. No issue, no request, nobody. I talked myself into it. Enough years reading enterprise architecture blogs and "cloud-native" checklists will do that to you: you start treating "supports S3" as a box a serious project is supposed to tick, even when the project in question is a self-hosted drive for people running it off a box in a closet. So I built it anyway: a storage adapter, a second code path for every read and write, integration tests against MinIO, the whole thing, in service of a requirement nobody actually had.

Then I had to live with it.

## What "one more backend" actually cost

- Every storage bug had two possible causes, and I got to find out which one after reproducing it against a bucket.
- "Your files stay files," the actual pitch of this project, stopped being true the moment they were objects in a bucket instead of a directory tree. `rsync` and `ls` no longer just worked. That's not a minor footnote, that's the thing I keep telling people to trust.
- The whole feature was built for a deployment shape (enterprise, elastic object storage, someone else's ops team) that this project has never claimed to serve.

> A feature that makes the software worse for 100% of actual users so it can be theoretically fine for a deployment nobody's running is not a feature. It's scope creep I imported from a world this project doesn't belong to.

## Who actually wanted S3 here

Nobody running Penombre on a box in a closet with a mounted volume wants S3. They want the opposite: a plain directory a backup script can see. The SQLite-by-default, one-container pitch exists for exactly the same reason: minimize the things that can go wrong on hardware nobody's paging you about at 3am. S3 support was me quietly arguing against my own premise, for however long it took to notice.

If you genuinely need S3-backed storage, this was never going to be your tool. Seafile and a dozen enterprise NAS platforms already do this properly, with people paid to support it.

## What's there instead

Local disk, always. Mounted volumes for NAS shares if you've already got storage elsewhere. If you want it in a bucket anyway, run Penombre on local disk and let something like `rclone` or `restic` push a backup out to S3 on its own schedule, same result, without the storage layer itself being slower and stranger for everyone.

If you were one of the handful of people actually using S3 support, sorry for the churn: open an issue and I'll help you get your files back onto a disk where they belong. Homelab, not enterprise. Should've been the rule from the start.