VaultS3: S3-compatible object storage in one binary

The README opens with a warning about its own author

The most unusual thing about this project is that its pitch starts with a disclaimer. A note says this is a one-person project and you should know that before you trust it with your data. The reason follows: the author was running MinIO, the pieces they depended on moved behind a paid tier, and they did not want to rent back something they already had, so they wrote their own. The stated deal is explicit. What you get is a maintainer who runs this in production himself and fixes things because he runs into them too, and what you do not get is a company standing behind it. The project is on GitHub because the author doubted he was the only one in that position, and if something breaks the request is to open an issue, with pull requests welcome. The homepage is vaults3.com, the licence is AGPL-3.0, the last push was on 2026-10-18, and the recent releases are v5.0.2, v5.0.1 and v5.0.0, all from 2026-10-07, which is a sign that the 5.0 line has just landed. For an engineer reading a comparison table of object stores, a project that states its own risk profile in the first paragraph is easier to evaluate than one that does not.

The memory claim, and what happens under load

The headline is a single binary that idles in 17 MB of RAM, and the README backs that with a comparison table of six projects. VaultS3 is listed at 17 MiB idle, Silo at 101 MiB, Garage at 23 MiB, RustFS at 70 MiB, SeaweedFS at 98 MiB and MinIO at 184 MiB, with a row for how many components you have to run, which is 1 for everything except SeaweedFS at 3. The footnote is careful about how those figures were taken: measured in August 2026 on one host, all six idle with no traffic, Docker working set after a 110 second settle, and a second reading taken to confirm the figures had stopped moving. And the honest part follows immediately, namely that memory under load is higher for every one of them, with VaultS3 peaking around 185 MiB while writing 64 MiB objects at concurrency 16, reproducible with docker stats --no-stream. That is the right way to present a footprint claim, and it is the number to plan against rather than the idle figure. The comparison also has a footnote on how it was compiled, with star counts read from each repository on 11 September 2026 and Garage's taken from a GitHub mirror because it is developed on its own Forgejo instance.

What the single binary actually contains

The answer to when VaultS3 is the answer lists the things you would otherwise assemble or pay for, and they are worth reading as a scope statement. There is a full dashboard, IAM with policies and OIDC, versioning with diff and rollback, per-bucket encryption with rotation and crypto-shredding, erasure coding, Raft clustering, active-active replication, lifecycle, notifications, a FUSE mount, full-text and vector search, virus scanning, tiering and scheduled backups. The claim that no paid tier holds any of it back and that there is no telemetry is a design position rather than a technical fact, but it is a clear one. The dependencies in go.mod explain the architecture underneath that list better than the prose does. hashicorp/raft with raft-boltdb gives the consensus and its storage, bbolt is the metadata store, klauspost/reedsolomon is the erasure coding, hanwen/go-fuse is the filesystem mount, and nats.go, kafka-go, rabbitmq and go-redis are the notification and cache integrations. There is also ldap for directory integration, parquet-go for the analytical path, klauspost/compress and brotli for compression, xxhash for checksums and yaml for configuration. The module targets go 1.26.0 with toolchain go1.26.7, and the Go badge in the README asks for 1.25 or newer.

The build compiles a React dashboard into the Go binary

The packaging is where you can see the care taken. The Dockerfile has three stages. The first builds the frontend on node:22-alpine and is deliberately pinned to the native build platform, with a comment explaining that the dashboard output is static, architecture-independent HTML, CSS and JS, so there is no reason to build it under QEMU emulation for arm64, which also avoids an npm optional native-dependency resolution bug that breaks emulated arm64 installs. The second stage builds the Go binary on golang:1.26-alpine, and the compile line is explicit about the flags:

RUN CGO_ENABLED=0 go build -ldflags="-s -w -X main.version=${VERSION}" -o /vaults3 ./cmd/vaults3

A second build produces /vaults3-cli, and the comment there states the intent: the CLI ships in the image, built from the same commit as the server, so the two cannot drift apart, and you run it with docker exec against the container. The version is injected by CI so the dashboard and the -version flag agree. The runtime stage is alpine:3.21 with only ca-certificates added, a vaults3 group and user at uid 1000, and the directories /data, /metadata and /etc/vaults3 created and chowned, with a comment explaining that without a writable working directory every relative path resolves to /, which the unprivileged user cannot create in, so the built-in ./data, ./metadata and ./logs defaults failed. The Makefile mirrors the same build for local work, with web, build, build-go, cli, run, test, test-coverage, lint and fmt targets, and the version injected from the nearest git tag.

How the S3 comparison actually reads

The README includes a table comparing VaultS3 with Amazon S3, and it is refreshingly one-sided in the other direction. The framing sentence is that S3 is the API VaultS3 implements, not a competitor you would swap it for. Durability is your disks and configuration against eleven nines across three or more availability zones by default. Scale is around 10M objects per node, with a billion needing roughly 30 nodes, against effectively unlimited. Operations and compliance are yours, including any certification, against no infrastructure to run, with the note that AWS is certified but your configuration still is not. Cost is hardware, with no per-request or egress charges, against per GB, per request and per GB egressed. The exit path is ordinary files and a BoltDB index behind the S3 API, against the S3 API. Then the honest summary: self-hosting wins when egress or request charges dominate the bill, when the data has to stay on hardware you control, when clients are on the same network as the storage, or when you need a cost that does not move with traffic, and S3 wins when you want durability and availability you do not have to engineer, scale you do not have to plan for, or an audit whose scope stops at your own configuration. The S3 figures are stated as reflecting publicly available AWS information as of August 2026, with an invitation to open an issue if a cell is out of date.

The README tells you when to pick something else

This is the section that separates a serious project from a project with a comparison table. If you already run MinIO and want it to keep working, the recommendation is Silo, a community fork by Pigsty that keeps the line maintained and restores the console MinIO cut, with the same on-disk format, the same API and the same MINIO_* variables so an existing deployment carries on unchanged. The README notes that MinIO removed the admin console from its Community Edition in 2025 and archived the open-source repository in February 2026, so its star count reflects a project no longer developed in the open, and that full management now requires the paid AIStor product. If AGPL is a problem for you, the answer is RustFS or SeaweedFS, both Apache-2.0, with the note that RustFS's own README still marks distributed mode, lifecycle and KMS as under testing. If you need a distributed filesystem rather than only object storage, the answer is SeaweedFS, with a mature FUSE mount and a filer layer, running as master, volume and filer rather than one process. And if you want the smallest possible replicated store without erasure coding or versioning, Garage, which idles in 23 MiB and is deliberately narrow in scope. A reader who disagrees with the project's conclusions is given the alternatives, the licences and the reasons.

Editorial conclusion

Adopt VaultS3 if you want to replace a hosted object store with something you run on your own hardware, you can accept an AGPL-3.0 licence, and you want the dashboard, encryption and versioning without assembling them from separate components. Do not adopt it if you need a company behind the project, a distributed filesystem, or a licence that is not AGPL. Before you trust it with data, read the maintainer's own note about being a one-person project, check the 17 MiB idle figure against the roughly 185 MiB peak the project itself reports under load, and decide from the documented S3 API coverage in docs/S3-API.md whether the operations your client needs are actually implemented.

Frequently asked questions

Official sources

1. Kodiqa-Solutions/VaultS3 on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases