Open Source Amazon S3 Alternatives

Everything the MinIO server hands out goes over the S3 protocol, so existing tools and SDKs connect without changes. Object storage is the job, and the project aims at AI and machine learning pipelines, analytics and other data intensive workloads.

The repository is archived and no longer maintained, and the community edition now ships as source only. Older pre compiled binaries stay online for reference but receive no further updates, and the maintainers point production users at their commercial AIStor editions instead.

Four routes get the community server running.

• Go install: build the latest server straight from the module path.
• Docker: build an image from the provided Dockerfile once the binary exists.
• Helm: install into Kubernetes from the published charts.
• Cross compilation: set the target operating system and architecture at build time.

One command starts a standalone server against any empty folder using default root credentials. The embedded MinIO Console is a web object browser for creating buckets and uploading objects, and the mc command line client talks to the same endpoint for administrative work.

Licensing is AGPLv3, and the maintainers spell out the obligations: modified code you have benefited from goes back to the community, and commercial or proprietary repackaging happens at your own risk. Support is best effort through GitHub and Slack rather than guaranteed.

Ceph is a scalable distributed storage system. This repository carries the source and the tooling to build it, which is what you want when you are compiling for a platform the official packages do not cover, or working on the storage code itself.

Builds are configured through the do_cmake.sh script and compiled with ninja. A debug build is the default whenever a git checkout is present, and it can run at a fraction of production speed, so pass the RelWithDebInfo build type for anything you intend to measure. Bundled dependencies such as Boost, RocksDB and Arrow compile from source unless you opt into system libraries.

The tree gives you more than a compiler invocation.

• Test clusters: vstart launches a working cluster from the build directory, with rbd and rados commands ready in bin.
• Container builds: code, unit tests and packages build inside Podman or Docker, avoiding local dependency installs and covering other distributions.
• Test suite: ctest runs unit tests in parallel across every processor, with regex filtering for a single case.
• Optional components: the RADOS Gateway builds by default and can be switched off at configure time.
• Source tarballs: make-dist produces a full tarball for building deb or rpm packages.

Documentation builds from the same tree with one script, and each code contribution needs a valid signed-off line, though copyright assignment is never asked for. Bugs and existing issues live on the project's own tracker rather than on GitHub.

Object storage sized between a single spare disk and a data center fleet is awkward to come by. Garage fills that gap, an S3-compatible distributed object storage service designed for self-hosting at small to medium scale, the kind of cluster one group can actually maintain.

The architecture assumes the nodes are not all in one room. A cluster is built from machines running at different physical locations, and Garage replicates data across those locations, so the service keeps answering even while some servers are unreachable.

Four priorities shape the project.

• Geo-distribution: replication spans the physical sites a cluster is spread over, not merely separate disks.
• Availability: the storage service stays reachable when individual nodes go down or lose connectivity.
• Lightweight operation: the software is meant to be easy to run and undemanding on the machines hosting it.
• Resilience: machine failure is treated as an expected event rather than an incident.

Because the API is S3-compatible, tools that already speak to object storage can address a Garage cluster directly. Binary releases are published alongside the source, and the documentation covers the design goals, a feature reference and a quick start.

Deuxfleurs, the experimental small-scale hosting provider behind the project, has run Garage in production since its first release in 2020. It is free software under AGPL v3.

Storj is a distributed cloud storage network. Files handed to it are encrypted, broken into pieces and scattered across a global network of computers, and only you can retrieve them. The result behaves like object storage while removing the single provider that would otherwise hold every copy of your data.

The platform is S3-compatible, which is the practical part. Existing tools and code that speak the S3 API can point at Storj through its gateway without being rewritten. This repository holds the network code itself, written in Go, along with the suite of distributed applications around it.

The wiki documents a few starting points for anyone new.

• Test network: a local network to develop against before touching anything in production.
• Uplink CLI: the command line client for moving data in and out.
• S3 gateway: the compatibility layer that lets existing S3 tooling talk to the network.
• White paper: the design of the v3 network, published in full for anyone who wants the reasoning behind it.

One caveat matters to developers. Client libraries such as uplink follow semantic versioning, but this repository deliberately does not and is not meant to be consumed as a Go module, so backwards-incompatible changes can appear between minor and patch releases. The code is currently licensed under AGPLv3, with contributors asked to sign a CLA so it can be relicensed under Apache v2 or another license later.

Shifts around MinIO left teams reconsidering how safe it is to depend on a single reference implementation of the S3 API. Alarik answers that with object storage written in Swift, licensed under Apache 2.0 and meant to be run by the teams that depend on it.

The S3 surface covers core object operations, multipart uploads, bucket versioning, conditional requests, range reads with correct partial content semantics, presigned URLs, bucket policies and lifecycle rules, authenticated with SigV4 in header, query and chunked forms.

Around the API sits the rest of the system.

• Web console: an object browser with drag and drop upload, metadata editing, version browsing and time-limited shared links.
• Access control: local accounts, several OIDC providers, per user access keys and a bucket level public access block.
• Webhooks: AWS-shaped event notifications, HMAC signed, retried from a persistent outbox that survives restarts.
• Replication: SigV4 signed writes to any remote S3-compatible target, filtered by prefix and synchronous per rule if you ask.
• Erasure coding: Reed-Solomon data and parity shards spread across nodes and rebuildable from any k of them.
• No external database: buckets, users, keys, policies and cluster membership live in Alarik's own storage directory.

Placement uses rendezvous hashing, so any node can serve any request and a failed node never reshuffles data. Writes acknowledge once a quorum of shards land, while read repair and a background scrub rebuild anything missing or corrupted. Alarik runs on Linux, is labeled beta, and its authors intend to migrate their own accounting product onto it.

Spinifex recreates the AWS service surface on infrastructure you control. Software written for EC2, EBS, S3, VPC and IAM keeps working unchanged, because the AWS CLI, the SDKs and Terraform talk to Spinifex the way they talk to AWS. What changes is where the workload runs, not what it is.

Every API call is authenticated at a gateway, published to a NATS subject and answered by whichever daemon claims it. Daemons hold no state, so scaling out means starting more. There is no etcd, no Kubernetes and no external control plane, so a cluster keeps serving through disconnection.

The platform is assembled from several Go services and the open source pieces around them.

• Spinifex: VM orchestration over QEMU driven through the QMP interface, with EKS, ECS, ECR and RDS built on that same instance layer.
• Viperblock: block storage with write ahead logs on local NVMe, replicated across nodes and exposed over NBD or virtio-blk.
• Predastore: S3 compatible object storage with SigV4 auth, multipart uploads and Reed-Solomon erasure coding across nodes.
• Northstar: authoritative DNS for cluster service discovery and public records, with zones kept as readable TOML files.
• Networking: OVN backs VPC networking and security groups, while HAProxy and nginx serve the load balancer APIs.

The same platform deploys in three shapes, a partner Neocloud with GPU capacity, a multi-node cluster in your own data center, or an edge site running air gapped. It is Go and AGPL 3.0, with a 72 hour hosted sandbox for pointing an existing workload at it first.