Alarik is a high-performance, S3-compatible object storage system written in Swift, licensed under the Apache 2.0 license. It aims to deliver exceptional speed, developer-friendly ergonomics, and a modern cloud-native core. See Documentation
Recent shifts in the ecosystem-especially surrounding MinIO-have revealed how fragile it is to depend on a single “reference” implementation for S3-compatible storage. These changes highlighted structural, licensing, and philosophical issues that many teams had long overlooked.
Alarik exists to provide a modern, transparent, community-driven alternative. Developers and organizations need an S3-compatible store that is fast, simple to operate, easy to extend, and genuinely open-source. No licensing traps, no moving goalposts.
The goal: a self-hosted, high-speed S3 system built for today’s workloads, without the enterprise upsell.
| Feature | Notes |
|---|---|
| Core object operations | Put, Get, Head, Delete, Copy, multi-object delete |
| Multipart uploads | Create, upload part, complete, abort, list parts/uploads |
| Bucket versioning | Enabled/suspended, version listing, delete markers |
| Conditional requests | If-Match, If-None-Match, If-Modified-Since, If-Unmodified-Since |
| Range reads | Including suffix ranges, correct 416 semantics |
| Presigned URLs | Query-string (SigV4) auth, up to 7-day expiry |
| Object tagging | Bucket and object-level tag-sets |
| Bucket policies | JSON policy documents, public access block |
| Lifecycle rules | Expiration, noncurrent version expiration, incomplete multipart cleanup |
| Bucket webhooks | AWS-event-shaped notifications over HTTP (see below) |
| Bucket replication | Continuous, SigV4-signed replication to remote S3-compatible targets (see below) |
| SigV4 authentication | Header and query auth, chunked (streaming) payloads |
| Feature | Notes |
|---|---|
| Object browser | Upload, download, delete, folder navigation |
| Drag-and-drop upload | Files and whole folders, with progress tracking |
| Recursive search | Find objects by name across nested folders |
| Bucket & folder stats | On-demand size and object count |
| Metadata editing | Content-Type and custom metadata, in place, without re-uploading |
| Object versioning UI | Browse, preview, download, and delete individual versions |
| Shared links | Time-limited, unauthenticated public links to an object |
| Admin dashboard | Live CPU/RAM/traffic charts, storage stats, user & bucket management |
| Feature | Notes |
|---|---|
| Local accounts | Username/password, optional open self-registration |
| OIDC SSO | Admin-managed, multiple simultaneous identity providers, optional auto-provisioning |
| S3 access keys | Per-user, with optional expiration |
| Bucket policies | Fine-grained, S3-compatible JSON policies |
| Public access block | Bucket-level override to block public access regardless of policy |
| Feature | Notes |
|---|---|
| AWS-compatible payloads | Same event structure (v2.4) as S3 Event Notifications |
| HMAC-signed deliveries | Verify authenticity with a per-rule shared secret |
| Reliable delivery | Persistent outbox, survives restarts, exponential backoff retries |
| Delivery health | Inspect pending/failed deliveries and retry on demand, from the console or API |
| Event & key filtering | Subscribe by event type, key prefix, and/or suffix |
| Feature | Notes |
|---|---|
| Real S3 protocol | SigV4-signed PutObject/multipart/DeleteObject requests, works against any S3-compatible target |
| Target + rule model | Reusable remote targets (endpoint, credentials), referenced by prefix-filtered rules |
| Reliable delivery | Persistent outbox, survives restarts, exponential backoff retries |
| Sync or async per rule | Async by default; a rule can opt into holding the client's write until delivery completes |
| Opt-in delete & existing-object replication | Deletes and pre-existing objects are never replicated unless a rule opts in |
| Resync | On-demand replication of a bucket's existing objects for a rule |
| Task health | Inspect pending/failed replication tasks and retry on demand, from the console or API |
| Feature | Notes |
|---|---|
| Postgres-backed control plane | Opt-in multi-node HA for buckets, users, access keys, and policies behind a load balancer |
| Sharded, replicated object data | Rendezvous (HRW) hashing places each object on 3 nodes cluster-wide, no range-sharding hotspots |
| Any node serves any request | An entry node forwards to a responsible node transparently - no client-visible routing logic |
| Quorum writes | A write acks once a majority of replicas confirm, with async catch-up for stragglers |
| Automatic rebalancing | Node join/drain/removal triggers copy + safe reclaim, including historical versions and delete markers |
| Cluster-aware listing | ListObjects, ListObjectVersions, ListMultipartUploads, and DeleteBucket safety checks work correctly across every node |
| Admin console | Live node health, storage distribution, and an object placement browser under Admin → Cluster |
See the documentation for the full API reference.
Please see Documentation
We are the ones behind the German Accounting-Software belegFuchs, and although we currently run MinIO in production, we are planning to migrate to Alarik in the future. This isn’t a marketing slogan - it’s a commitment that directly shapes our roadmap.
Because we rely on S3-compatible storage every day, we are fully invested in ensuring that Alarik continues to evolve: solid performance, long-term stability, and an open development model without licensing uncertainty. Our own planned adoption is a practical reason why we are committed to keeping Alarik actively maintained and moving forward.
TL;DR: Alarik is here to stay - it’s not going anywhere.
Alarik is built with a strong focus on low-latency I/O and highly parallel request handling. New benchmarks on a dedicated Linux machine show that Alarik delivers competitive and in many cases superior throughput compared to MinIO or RustFS, even in early beta stages.
We use MinIO’s own benchmarking tool, warp, to measure performance. Both the object store and the benchmark client run on the same Linux host, ensuring results reflect raw engine performance rather than network conditions.
These benchmarks represent the current state of the project. As Alarik’s storage engine and I/O pipeline continue to evolve, we expect performance to improve further.
We welcome contributions of any size. Please:
- Fork Alarik and create a new branch e.g. feature/my-new-feature
- Use clear, descriptive commit messages
- Open an issue before starting larger work
- Follow Swift best practices
- Add tests for new functionality where appropriate
- Keep pull requests focused and incremental
More documentation, benchmarks, SDKs, and deployment guides are on the way.
If you believe in a future of open, community-driven, high-performance object storage, consider giving the repo a ⭐ and contributing!