Open Source Azure Blob Storage 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.

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.