MinIO Community Is Parked. Garage Is Open

For years, MinIO was the nearly automatic answer to “we need our own S3-compatible storage.” It was easy to deploy, familiar to administrators, and supported by a large community. Then the Community Edition gradually lost prebuilt binaries and parts of its management interface, entered maintenance mode, and finally stopped being maintained.

The minio/minio repository was archived in April 2026 and is now read-only. Existing installations do not stop working because a repository was archived, and the source remains available under the AGPLv3 license. The Community Edition will not, however, receive new upstream releases, reviewed fixes, or security updates. That is not a comfortable foundation for a new storage system.

This applies specifically to MinIO Community Edition. MinIO’s commercial AIStor product continues to be developed and supported. The company did not vanish, and S3 did not fall off the internet. The practical change is that self-hosters looking for an actively maintained open-source server now need an alternative.

Fortunately, there are several. Ceph RGW is mature and powerful, although operating Ceph only to obtain an S3 endpoint can feel like buying a ship because you need a bucket. SeaweedFS offers impressive scale and several storage interfaces, with more moving parts. Newer projects such as RustFS and VersityGW are also attracting attention.

And then there is Garage, a distributed object storage system written in Rust and built specifically for small and medium-sized, self-hosted, geographically distributed clusters.

Garage was designed for the awkward network

Garage was started by the French non-profit hosting collective Deuxfleurs. Its developers wanted storage that could run across physical locations connected by ordinary internet links, not only inside one low-latency datacenter with identical servers and a network diagram suitable for framing.

It implements the familiar S3 API, so applications can use regular S3 clients, SDKs, presigned URLs, multipart uploads, and common tools such as rclone and restic. Garage is distributed as a self-contained binary, has no required external database or coordination service, and runs on both x86 and ARM systems.

Garage understands the capacity and zone assigned to each storage node. With the commonly recommended replication factor of three, it can place copies of each data chunk in three different zones. If a server, network link, or entire location disappears, other copies remain available.

Nodes can be added or removed, and Garage recalculates the cluster layout and rebalances data. It also supports block-level deduplication and optional Zstd compression, which can make a meaningful difference for documents, logs, and other repetitive or compressible data.

The most interesting design choice is what Garage does not use: there is no Raft or similar leader-based consensus mechanism ordering every request. Garage draws on Dynamo-style distributed systems and conflict-free replicated data types. Requests do not have to pass through one cluster leader, reducing the amount of sequential coordination required across slow links.

That does not repeal the laws of physics. A write replicated between distant locations must still cross the network, and stronger durability or consistency requires waiting for enough copies. What the design does is avoid adding unnecessary round trips to an already long journey.

Why it suits geographically distributed storage

Many storage systems can replicate data to another site. Garage treats multiple sites as the normal cluster topology rather than an afterthought.

Its official design documentation describes deployments over regular internet connections and recommends no more than 200 ms of latency and at least 50 Mbps of bandwidth. Zones allow the administrator to tell Garage which nodes share a physical failure domain, so replicas can be placed across independent locations instead of sitting on three servers in the same rack.

The project is already used this way. Deuxfleurs documents a nine-node cluster across three physical locations for websites, Matrix media, documents, Nix packages, and backups. Triplebit operates 15 storage nodes across three locations for websites, Mastodon and PeerTube media, Matrix, and DNS-related data.

This makes Garage interesting for:

• application assets, user uploads, media, and static websites;
• an S3 backend for services such as Matrix, Mastodon, or PeerTube;
• backup targets used by restic, rclone, and similar tools;
• container registries and package repositories;
• organizations that want storage copies outside a single datacenter or provider region.

Replication is not the same as backup. An accidental deletion or compromised credential can propagate through a healthy distributed cluster with admirable efficiency. Important data still needs separate, access-isolated, preferably immutable backup copies.

Performance: fast where its architecture matters

Garage’s developers are refreshingly direct: extreme performance is a non-goal. The project prioritizes simple operation, resilience, low resource use, and acceptable performance across unreliable or high-latency networks. It uses full replication rather than erasure coding, trading storage efficiency for simpler placement and recovery.

That means Garage should not automatically be presented as the fastest object store for every workload. A local all-NVMe benchmark, a stream of large sequential objects, millions of tiny files, and a cluster spread across continents test very different things.

The project’s own geo-distribution benchmarks simulated 100 ms links between nodes. Garage showed substantially lower latency than the tested MinIO setup for several common operations because it required fewer coordination round trips. These results illustrate the architectural advantage, but they are project-run simulated tests and should not replace a benchmark using your object sizes, concurrency, disks, and network paths.

Independent production reports are encouraging. One published MinIO-to-Garage migration report found lower resource use, quick recovery after a pod restart, no visible difference for its everyday DuckDB workload, and better behavior during concurrent backfill writes. Its dataset was only 1.8 GB and the production observation period was short, so the report is useful experience rather than a universal performance verdict.

Community feedback follows a similar pattern. In self-hosting discussions, several users praise Garage’s small memory footprint, simple deployment, and stable three-node clusters, including nodes connected over the internet. Criticism usually concerns the more limited S3 feature set, lack of a rich built-in management interface, and configuration details such as CORS. These reports are anecdotal, but they reveal practical tradeoffs that a benchmark graph can hide.

The sensible approach is to test Garage with the real client. Upload and retrieve representative objects, run multipart transfers, exercise listings and deletions, interrupt a node, throttle a link, and watch recovery. Storage benchmarks are easy to win when they avoid the uncomfortable parts of storage.

Active project, deliberately limited scope

Garage has been developed since 2020 and used in production by its creators since its first release. The code is AGPLv3, the development repository and GitHub mirror are public, releases continue on the 2.x branch, and the project has received several rounds of European public funding through NGI programmes.

The community is visibly growing as former MinIO users evaluate alternatives. There are deployment guides for systemd, Docker, Kubernetes, and Ansible, along with third-party web interfaces and Kubernetes operators. The project also publishes its governance structure: at the time of writing, it has a lead developer and three maintainers. That is an active team, but still a small one, and organizations should include project governance in their risk assessment just as they would for any infrastructure dependency.

Garage also does not claim complete AWS S3 compatibility. Its compatibility documentation lists important omissions:

• no object versioning;
• no S3 Object Lock or legal holds;
• no standard S3 bucket policies or ACL model;
• no bucket notification API;
• only partial lifecycle support;
• no S3-managed server-side encryption.

Garage provides its own per-key, per-bucket permissions, supports client-provided encryption keys, and expects disk or client-side encryption for other cases. Separately, its replication-based architecture deliberately omits erasure coding.

For ordinary object storage, media, application files, and many backup workflows, the implemented S3 subset can be entirely sufficient. For Veeam immutability, compliance retention, complex AWS policies, or an application that depends on an obscure S3 endpoint, it may not be.

Test compatibility before migrating. “S3-compatible” is a family resemblance, not a promise that every distant cousin behaves identically at dinner.

Why ITLDC is a natural place to build a Garage cluster

Garage becomes more useful when its nodes occupy genuinely independent failure domains. Three virtual servers on one physical node are three processes, not three locations. Even three servers in one building still share some combination of power, cooling, connectivity, and local events.

ITLDC operates infrastructure in many independent datacenter locations across Europe and the United States. Customers can combine NVMe VDS instances for metadata, gateways, and smaller storage workloads with dedicated servers where larger local disks and predictable I/O are required. A cluster can be placed in several cities or countries instead of being limited to availability zones owned by one hyperscaler.

That is a particularly good match for Garage’s assumptions:

• nodes can be assigned to different physical zones;
• capacity can grow by adding servers without rebuilding the entire platform;
• lightweight gateway nodes can be placed closer to applications or users;
• geographic replicas can remain under one administrator’s control;
• deployments can start small and expand after real workload measurements.

Choose locations based on measured latency, bandwidth, legal requirements, and where the applications run. Replication consumes network traffic. With three full replicas, plan for close to three times the original data size before accounting for deduplication and compression, then leave room for metadata, temporary data, and normal growth. Fast disks do not compensate for an undersized uplink, and a beautiful topology diagram does not compensate for an untested restore procedure.

ITLDC’s range of independent locations gives Garage the physical separation it was designed to use. You choose the topology, operating system, encryption, replication mode, and backup policy; our infrastructure provides the places to put the nodes.

MinIO is not your last S3 server

There is no need to switch off a working MinIO Community cluster in panic. There is a need to stop treating an archived, unmaintained server as if future security fixes will arrive normally. Inventory its data and clients, test alternatives, create a migration plan, and keep verified backups before moving anything.

Garage is not MinIO with a different logo. It is a smaller, opinionated object store that favors geographic resilience, low overhead, and operational simplicity over exhaustive S3 features and maximum benchmark throughput. For many self-hosted applications, that is not a compromise. It is a better match.

And if the goal is to keep copies in several genuinely independent places, Garage and ITLDC’s distributed locations make a very practical pair.