Is OpenBucket for you?
OpenBucket is a single-node S3-compatible object store: one Node.js process
over SQLite and the local filesystem. That design is a deliberate trade — it's
what makes OpenBucket small enough to docker run in one command or embed
directly inside your NestJS app, and it's why it is not a drop-in
replacement for a distributed object store. Be honest with yourself about which
side of that line you're on.
OpenBucket is a great fit when…
- You want S3 semantics without operating a cluster. One container, one volume, any S3 SDK. No MinIO cluster to run, no AWS bill, no second service to babysit.
- You're building an app and need a file backend. The
@openbucket/nestjslibrary runs inside your process — one-line multer uploads, presigned browser POST, in-process@OnObjectCreated()events, and on-the-fly image transforms. A remote S3 can't do these in-process. - Your durability needs are "one node, plus a copy off the box." OpenBucket writes atomically, stores a SHA-256 per object, gates every read against it, and scrubs for bit-rot in the background. For off-box durability you turn on async replication to real S3 / R2 / B2 / MinIO. That's your redundancy story — see below.
- You're self-hosting for cost, sovereignty, air-gap, dev/test, or edge and a single well-run node with backups and a replica is an appropriate amount of durability for the data.
- You want small-to-moderate volumes that fit comfortably on one machine's disk and one SQLite metadata database.
OpenBucket is not the right choice when…
- You need built-in multi-node durability or high availability. There is no clustering, sharding, or automatic failover. The node is a single point of failure for availability; if it's down, your store is down until it's back. Replication gives you a durable second copy, not automatic HA. If you require multi-node quorum durability out of the box, use AWS S3, Cloudflare R2, or a MinIO cluster.
- You need the eleven-nines, multi-AZ durability SLA of a hyperscaler. OpenBucket's durability is as good as your disk, your fsync, your backups, and your replica — all of which you operate. We tell you exactly how the bytes are protected (Durability) so you can decide if that's enough. We do not offer a durability SLA.
- You need virtual-host-style addressing or region emulation. Path-style
only (
forcePathStyle: true), one configured region, no cross-region redirects. - You need S3 features we don't implement.
SelectObjectContentandGetObjectTorrentreturnNotImplemented; accelerate / logging / request-payment / website subresources are recognized stubs, not production features. See the compatibility matrix. - You're at very large scale — tens of TB / high-concurrency multi-tenant workloads that outgrow a single node and one SQLite metadata plane.
Running it safely, whatever your case
Even where OpenBucket fits, treat it like the stateful, single-node system it
is: put it behind a TLS-terminating reverse proxy, keep all of DATA_DIR on one
filesystem (atomic renames depend on it), turn on
scheduled backups and, for anything you can't
afford to lose, replication to a second
target.
:::info Pre-1.0 status OpenBucket is pre-1.0. The S3 surface and admin console are feature-complete and tested against a conformance suite, and a security audit has been completed and remediated — but APIs may still change before 1.0. See the roadmap for what's stable and what may still move. :::