Alarik: an S3-compatible object store written in Swift
High performance distributed S3 compatible object storage focused on speed and designed to be an open alternative to MinIO and RustFS.
At a glance
- What is it?
- Alarik is a self-hosted S3-compatible object storage system written in Swift, positioned as an open alternative to MinIO and RustFS, and its design decisions are unusual: no external database, Reed-Solomon erasure coding for object data, and rendezvous hashing instead of range sharding. The status badge on the repository says beta, and every release is a 1.0.0 beta.
- Who is it for?
- Alarik fits a team that needs to self-host an S3-compatible endpoint, already operates a Linux fleet, and wants a storage system with no database to run and no vendor licence attached to it. It does not fit a team that needs a production track record, because every published release is a 1.0.0 beta and the last push to the repository was on 2026-09-19, and it does not fit a team whose clients depend on the small S3 corners MinIO covers.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 34 days ago.
- What is it written in?
- Mainly Swift, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A Swift object store aimed at the MinIO gap
Alarik is described as a high-performance, S3-compatible object storage system written in Swift and licensed under Apache 2.0, with the stated aim of delivering speed, developer-friendly ergonomics and a modern cloud-native core. The homepage is alarik.io and the documentation lives at alarik.io/docs. The repository language is Swift and the platform badge in the README says Linux, so the deployment target is a Linux server rather than a cross-platform developer tool.
The positioning statement is unusually blunt about why it exists. The README argues that recent shifts in the ecosystem, especially surrounding MinIO, revealed how fragile it is to depend on a single reference implementation for S3-compatible storage, and that those changes highlighted structural, licensing and philosophical issues that many teams had long overlooked. The promise that follows is a modern, transparent, community-driven alternative: fast, simple to operate, easy to extend, and genuinely open source, with no licensing traps and no moving goalposts, and a self-hosted, high-speed S3 system without the enterprise upsell.
Whether that argument lands depends on your own read of the MinIO situation, but the engineering pitch is separable from it. What follows is a description of a storage system that takes a small number of unusual design decisions seriously, and those decisions are where the operational cost lives.
The S3 surface area is broad, down to 416 semantics
The compatibility table in the README is long, and the details matter more than the headings. Core object operations cover Put, Get, Head, Delete, Copy and multi-object delete. Multipart uploads cover create, upload part, complete, abort and listing parts and uploads. Bucket versioning supports enable, suspend, version listing and delete markers. Conditional requests implement If-Match, If-None-Match, If-Modified-Since and If-Unmodified-Since, and range reads include suffix ranges with correct 416 semantics.
Presigned URLs use query-string SigV4 authentication with expiry up to seven days. Object tagging works at bucket and object level, bucket policies are JSON policy documents with a public access block, and lifecycle rules cover expiration, noncurrent version expiration and cleanup of incomplete multipart uploads.
Authentication has three parts. Local accounts use a username and password with optional open self-registration, OIDC SSO is admin-managed with multiple simultaneous identity providers and optional auto-provisioning, and S3 access keys are per-user with optional expiration. SigV4 authentication is accepted in header form and query form, including chunked streaming payloads, which is the detail that decides whether some SDK clients work against it without modification.
Two features go beyond what a client library expects. Bucket webhooks deliver AWS-event-shaped notifications over HTTP, using the same event structure as S3 Event Notifications version 2.4, with HMAC-signed deliveries verified through a per-rule shared secret. Bucket replication speaks the real S3 protocol, sending SigV4-signed PutObject, multipart and DeleteObject requests to any S3-compatible target, with reusable remote targets referenced by prefix-filtered rules.
No external database, and what that changes operationally
The most consequential line in the README is under horizontal scaling: no external database. Buckets, users, access keys, policies and cluster membership itself all live in Alarik's own storage, replicated whole to several nodes so that any one of them can serve them alone, and the Storage/ directory is the only thing to back up.
That single decision removes an entire class of operational work. A deployment does not need a Postgres or a distributed consensus service alongside the object store, does not need to think about whether the metadata database and the object storage are consistent with each other, and has exactly one directory to snapshot. The cost is that metadata availability depends on the replication scheme of the object layer, and that the Storage/ directory holds everything, so a misconfigured backup of that directory takes the control plane with it. The README does not document a restore procedure, and it does not describe the on-disk format of the metadata, so that part of the design is not something a reader can evaluate from the repository alone.
The web console and the admin dashboard are part of the same system rather than a separate tool. The console offers an object browser with upload, download, delete and folder navigation, drag-and-drop upload of files and whole folders with progress tracking, recursive search by name across nested folders, on-demand bucket and folder statistics, in-place metadata editing for Content-Type and custom metadata without re-uploading, an object versioning browser, time-limited unauthenticated shared links, and a live dashboard with CPU, RAM and traffic charts plus user and bucket management.
Reed-Solomon shards, HRW hashing and quorum writes
Object data is erasure coded with Reed-Solomon, k data shards plus m parity shards spread across nodes, and the README states the durability target as replication at roughly 1.3 to 1.5x overhead. Any k shards can rebuild the object, so a node can fail without the object being lost and without a full copy being maintained.
Placement uses rendezvous hashing, described as HRW, which places each object's shards deterministically with no range-sharding hotspots and no coordinator. The consequence is stable ownership: a key's nodes are fixed by hashing, so a node going down never reshuffles data. It keeps its keys, and queued writes replay when it returns, and joining or draining a node redistributes shards and reconstructs any that were lost, including historical versions and delete markers.
Writes acknowledge once a quorum of shards land durably, with asynchronous catch-up for stragglers, which means a write returns before every replica has the data. Reads are self-healing: missing or silently corrupted shards are rebuilt from survivors automatically, on read and on a periodic background scrub, so bit rot is caught by normal traffic rather than by a separate audit. Ranged reads on erasure-coded objects reconstruct only the stripes the Range header covers and return 206 Partial Content. Listing is cluster aware, with ListObjects, ListObjectVersions, ListMultipartUploads and DeleteBucket safety checks working correctly across every node, and the admin console exposes node health, the k and m values, shard repair status, storage distribution and an object placement browser.
The design is coherent: it removes a coordinator and a database, at the cost of a write path that returns before every replica is durable and of parity storage overhead on every object.
Reliable delivery for webhooks and replication
Both event delivery paths use the same mechanism, and that mechanism is the part worth understanding before you rely on it. Each rule has a persistent outbox that survives restarts, with exponential backoff retries on failure. Delivery health can be inspected, showing pending and failed deliveries, and a failed delivery can be retried on demand from the console or the API. The same model appears on the replication side, where pending and failed replication tasks can be inspected and retried.
Event and key filtering let a subscription narrow by event type, by key prefix and by suffix, which is what makes per-object hooks practical. The HMAC signing means a receiver can verify that a delivery came from Alarik and was not modified in transit, using a secret it shares with the rule.
Replication has a set of defaults that are conservative and worth knowing. Async is the default, and a rule can opt into holding the client's write until delivery completes, which is the option you want when the source bucket must not lose data when the link is down. Deletes and pre-existing objects are never replicated unless a rule explicitly opts in, so a new rule does not start copying the entire existing bucket. A resync operation performs on-demand replication of a bucket's existing objects for a given rule, and the task health view is where you find out that it worked.
Getting it running, and what the repository gives you
The README's Installation section points at the documentation site, alarik.io/docs, and the text available here stops at that link, so the repository itself is where the operational shape has to be read.
The top level of the repository shows a container-first deployment with several compose files side by side: docker-compose.example.yml as a starting template, docker-compose.cluster.yml and docker-compose.cluster.dev.yml for a cluster, docker-compose.deploy.yml and docker-compose.dev.yml, and an example file, docker-compose.example.yml, that acts as a starting template. Alongside them sit start_cluster.sh and start_dev.sh as launcher scripts, deploy.sh for deployment, publish.sh for release publishing, and an nginx/ directory for the reverse proxy configuration that fronts the API and the console. A charts/ directory points at a Helm chart, so a Kubernetes deployment is the other supported shape. The application code sits in alarik/, the web console in console/, and there is a VERSION file, a CLAUDE.md and a LICENSE.md.
The test scripts are worth a glance for anyone evaluating the compatibility claim, because they are the project's own statement of which clients it expects to work. There is aws_cli_tests.sh for the AWS command line tools, mc_tests.sh for the MinIO client, rclone_tests.sh for rclone, and replication_tests.sh for the replication paths, plus cluster_tests.sh and an aggregator called run_all_tests.sh.
Where Alarik is the wrong choice
Three cases point elsewhere. The first is a team that needs a proven track record. Every release listed for the repository is a 1.0.0 beta, the newest being 1.0.0-beta-16 from 2026-09-03, and the README carries a beta status badge. A storage system holding the backups for a company is a poor place to run a version whose major number has not been cleared, and the README does not document a supported upgrade path between beta builds.
The second is a team whose existing clients depend on the MinIO-specific corners that S3 itself does not define. Alarik targets the S3 API, and the console ships a MinIO-compatible client test in mc_tests.sh, which tells you the project measures itself against that client. That is a reasonable target, but it is not the same as being a drop-in replacement for a MinIO deployment with extensions configured.
The third is a deployment that is not Linux and not containerised. The platform badge names Linux, the distribution path is compose files and a Helm chart, and the client is Swift, so a team that wants a native macOS or Windows binary is looking at the wrong project.
The realistic alternative to weigh is RustFS, which the topic list names alongside MinIO, both of which are Rust implementations of the same idea. The difference in approach is in the durability model and the dependencies: a system built on an external database separates control plane from data plane and can move metadata independently, while Alarik keeps cluster membership and user records inside its own replicated storage and pays for that with parity overhead on every object and a quorum write path that returns before every replica is durable.
Editorial conclusion
Alarik fits a team that needs to self-host an S3-compatible endpoint, already operates a Linux fleet, and wants a storage system with no database to run and no vendor licence attached to it. It does not fit a team that needs a production track record, because every published release is a 1.0.0 beta and the last push to the repository was on 2026-09-19, and it does not fit a team whose clients depend on the small S3 corners MinIO covers. Before you adopt it, read the Installation section in the documentation at alarik.io/docs, since the README points there and the repository ships compose files and a charts/ directory rather than a single install command, and size the Storage/ directory first, because it holds the cluster metadata as well as the object data.
Frequently asked questions
What is Alarik?
It is a high-performance, S3-compatible object storage system written in Swift and licensed under Apache 2.0, positioned as an open alternative to MinIO and RustFS for self-hosting. The project describes it as a modern, community-driven alternative to depending on a single reference implementation for S3-compatible storage.
Does Alarik need an external database?
No. The README states that buckets, users, access keys, policies and cluster membership itself all live in Alarik's own storage, replicated whole to several nodes so any one of them can serve them alone, which means Storage/ is the only thing to back up.
How does Alarik store and protect object data?
Object data is erasure coded with Reed-Solomon, k data plus m parity shards across nodes, rebuildable from any k, giving the durability of replication at roughly 1.3 to 1.5x overhead. Shards are placed with rendezvous hashing so a key's nodes are fixed and a node going down never reshuffles data, and missing or corrupted shards are rebuilt from survivors on read and by a periodic background scrub.
How do I install Alarik?
The README's Installation section points to the documentation at alarik.io/docs. The repository itself ships container-based deployment files, cluster, deploy and dev variants, plus an example compose file, an example file, start_cluster.sh and start_dev.sh scripts, an nginx/ directory for the reverse proxy, and a charts/ directory for a Kubernetes deployment.
Does Alarik support bucket replication and event notifications?
Yes to both. Bucket replication sends SigV4-signed PutObject, multipart and DeleteObject requests to any S3-compatible target, is async by default unless a rule opts into holding the client write, and never replicates deletes or pre-existing objects unless opted in. Bucket webhooks deliver AWS-event-shaped payloads over HTTP, HMAC-signed per rule, with a persistent outbox, exponential backoff retries and on-demand retry of failed deliveries.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/achtungsoftware-alarik)Was this useful?