MinIO vs Garage: when each one fits the decision
If your team already runs or is planning a small S3 store, the choice between MinIO and Garage turns on two questions: does the workload need features Garage leaves out, and do your nodes span several sites over ordinary internet links. The MinIO community server is released under the GNU AGPL v3.0, but its last tagged community release is RELEASE.2025-10-15T17-29-55Z, published on October 16, 2025, the repositories are archived (read-only), and the README says the community edition is distributed as source code only, with legacy binaries no longer receiving updates. Garage is also AGPL-3.0 licensed and was still receiving tagged releases, with v2.4.1 the latest tag in the supplied mirror listing. Before you decide, confirm with your own tests which S3 operations your applications call, because MinIO publishes no public S3 compatibility list that Garage's documentation could compare against.
MinIO remains a fair fit where the cluster sits in one site, latency is controlled, and you want erasure-coded local storage with strong consistency. Garage's own related-work page describes those choices as storage optimizations that make MinIO latency sensitive, and it treats them as non-goals. If your backup tooling depends on object lock or bucket versioning, Garage is a poor match: its S3 compatibility page lists both as not implemented, along with bucket policies, server-side encryption configuration, replication and event notifications. Garage uses its own per-access-key, per-bucket permissions instead. Ask your backup vendor and application owners to list the exact S3 calls they use, then test those calls against a Garage cluster in a staging environment.
Garage is designed for nodes spread across several sites on ordinary internet connections. Its deployment guide recommends at least three nodes for three-way replication, with copies placed in different zones, and its site lists requirements of 200 ms or less latency and 50 Mbps or more between nodes. Garage's related-work page says MinIO has no knowledge of sites and severe limits on adding or removing drives, so a site loss is harder to contain. Plan a site-loss test, confirm the latency and bandwidth between your sites against those figures, and decide where the metadata engine runs, since the deployment guide warns about LMDB corruption after unclean shutdowns and offers SQLite as an alternative. If you need object lock or versioning, you may have to keep MinIO or move to another platform, which the sibling comparisons cover.
Which store fits which scenario
This table maps common self-hosted object storage scenarios to the store that fits better, with the reason from each project's documented design. Rows marked for confirmation depend on an S3 feature that Garage does not implement, so run your own tests before deciding.
| Scenario | Better fit | Why |
|---|---|---|
| Multi-site backups with no site-level single point of failure | Garage | Garage is designed for several sites linked by ordinary internet connections and places the three copies of each chunk in different zones. Garage's related-work page says MinIO has no knowledge of sites, so it cannot spread data to limit the impact of losing one site. |
| Backups that need object lock or immutability | MinIO (confirm with AIStor or another store) | Garage's S3 compatibility page lists object lock and bucket versioning as not implemented. The community MinIO edition is archived, so confirm the lock behavior you need in your own tests before relying on either store. |
| Applications that depend on bucket policies or versioning | Confirm with your own tests | Garage does not implement bucket policies or bucket versioning and uses its own per-access-key, per-bucket permission system. Check each application's S3 calls against Garage's compatibility page before choosing it. |
| A single-site cluster on local drives with erasure coding | MinIO (confirm support path) | MinIO chose erasure coding and strong consistency as design goals, which suits a stable cluster in one location. Its community edition is source-only and archived, so plan for patching and support in your own environment. |
| A team that wants one binary to operate | Garage | Garage ships as one self-contained binary with no dependencies and lists modest hardware requirements, including 1 GB RAM and at least 16 GB of disk. Operating a single binary across sites is simpler than running an erasure-coded cluster. |
| Clusters that need drives added or removed often | Garage (confirm for your topology) | Garage's related-work page says MinIO has severe limitations on adding or removing drives from a cluster. Test your expected changes on Garage before committing to it. |
| Links with high latency between sites | Garage | Garage is built to run across sites with up to 200 ms latency and at least 50 Mbps between nodes, while MinIO's erasure coding and strong consistency make it latency sensitive. |
How Garage and MinIO are built and deployed
Garage and MinIO make different bets about hardware, consistency and how capacity grows. The cards below cover what each design asks of your team at install time and during routine changes, so you can judge which model fits a small, multi-site or Kubernetes-hosted store.
Garage as a single binary
Garage ships as one self-contained binary with no external dependencies, so the install step is copying one file onto each node and writing its configuration. Its replication is organized around zones, where a zone is a group of servers, and each data chunk is stored in three zones. Check that your sites map cleanly onto zones before you commit, because zone layout is the main design decision you cannot treat as an afterthought.
MinIO erasure-coded clusters
MinIO stores objects with erasure coding and strong consistency, which the Garage project describes as a latency-sensitive design choice. Erasure-coded sets are built from drives on the same cluster, so the layout favors well-connected hardware in one place. For Kubernetes, the MinIO Operator is the documented deployment path, and teams should confirm how that operator is maintained now that the community repositories are archived.
Three nodes for three-way replication
Garage's deployment guide recommends at least three nodes to get three-way replication, with copies always placed in different locations. A two-node setup can hold data but cannot give you that placement guarantee, so size the first deployment with three failure domains from day one. Ask which locations your three nodes will occupy, since two nodes in one rack defeat the purpose of the layout.
Garage metadata engine choice
Garage uses LMDB as its default and fastest metadata engine, but its guide warns that LMDB files are not portable across CPU architectures and that corruption has been reported after unclean shutdowns. SQLite is offered as the more robust alternative. If you run mixed hardware or expect power loss, choose the engine during planning, because switching it later means working through the data layout rather than flipping a setting.
MinIO source-only installation
The MinIO community edition is now distributed as source code only, with no further pre-compiled binaries, and legacy binaries will not receive updates. You install it with go install using Go 1.24 or later, or build a Docker image from the provided Dockerfile. Your team then owns the compile, patch and image rebuild cycle, which is a recurring cost to plan for alongside the AGPL obligations that apply to any modified deployment.
Day-two changes: drives and sites
The Garage project says MinIO has severe limits on adding or removing drives from a cluster and has no knowledge of sites, so it cannot spread data to limit the impact of losing a site. Garage is designed to distribute data across zones and to run across sites linked by ordinary internet connections. Before choosing, write down how you will add a site or retire a node, and ask both vendors to demonstrate that procedure in a test environment.
MinIO vs Garage on capability, licensing and support
This table compares MinIO community edition and Garage on the S3 features, licensing, maintenance status, multi-site behavior and hardware needs that decide a small self-hosted store. Read the Garage column as documented gaps, and the MinIO column as items to test yourself, since MinIO does not publish a public S3 compatibility list. The main takeaway is that Garage is explicit about what it leaves out, while MinIO's community build is no longer maintained.
| Capability | MinIO community edition | Garage |
|---|---|---|
| License | GNU AGPL v3.0; commercial licensing available through AIStor | AGPL-3.0; main repository on Deuxfleurs' Forgejo with a GitHub mirror |
| Last release or maintenance status | Repository archived and no longer maintained; last tagged release RELEASE.2025-10-15T17-29-55Z (October 16, 2025); source-only with no new binaries | Active; v2.4.0 tagged September 6, 2026 and v2.4.1 on September 7, 2026 |
| S3 bucket versioning | Confirm in your own tests; not listed in a public compatibility list | Not implemented |
| Object lock | Confirm in your own tests; not listed in a public compatibility list | Not implemented; matters if backups rely on object locking |
| Bucket policies | Confirm in your own tests; not listed in a public compatibility list | Not implemented; access uses per-access-key, per-bucket permissions |
| ACLs | Confirm in your own tests | Not implemented |
| Server-side encryption configuration | Confirm in your own tests | Not implemented; SSE-C is supported instead |
| SSE-C | Confirm in your own tests | Supported |
| Lifecycle rules | Confirm in your own tests | Limited to AbortIncompleteMultipartUpload and Expiration |
| Multipart uploads and presigned URLs | Confirm in your own tests | Both supported, along with CORS and signature v4 |
| Deployment unit | Server built from source with Go 1.24 or later, or a Docker image built from the Dockerfile; Kubernetes via the MinIO Operator | One self-contained binary with no dependencies |
| Site awareness | Erasure-coded clusters with no knowledge of sites, so it cannot limit the impact of losing a site | Stores each chunk across three zones; copies placed in different locations |
| Drive add and remove behavior | Documented by Garage as severely limited; confirm current behavior with MinIO before relying on it | Designed for adding and removing nodes across sites; confirm procedure in the deployment guide |
| Support path | Best effort through GitHub and Slack; SLA-backed support only through AIStor | No commercial support tier published in the supplied facts; confirm with the Garage project before procurement |
| Hardware requirements | Erasure coding and strong consistency make it latency sensitive; confirm sizing with MinIO | x86_64 or ARMv7/ARMv8, 1 GB RAM, at least 16 GB disk, 200 ms or less latency and 50 Mbps or more between nodes |
Which S3 features Garage leaves out and what that breaks
Versioning and object lock matter most when a bucket holds backups, because they protect data from the people and processes that write to it. Versioning keeps prior object revisions so an overwrite or delete can be reversed, and object lock stops those revisions from being removed for a set retention period. Garage's S3 compatibility page lists bucket versioning and object lock as not implemented, and it also does not implement bucket policies, ACLs, server-side encryption configuration, replication, event notifications or tagging. If your backup jobs depend on MinIO object locking or versioned buckets, you must either map those controls to another mechanism (for example, a backup tool's own immutability or a separate copy under different credentials) or keep MinIO for that workload. Do not assume a backup target is protected until you have tested the restore path.
Bucket policies matter when several teams, services or external parties share a bucket and need access rules that go beyond one credential. Garage uses its own permission system instead: access is granted per access key and per bucket, so each key is either allowed or denied on a given bucket. In practice this is coarser than a policy document that can scope actions to prefixes, conditions or specific principals. Before moving a shared bucket, list every access pattern it serves today, including anonymous read, prefix-level grants, and cross-account access, and decide whether a per-key, per-bucket model can express each one. Where it cannot, the workload needs to stay on an engine that supports policies, or the access model must change in the applications.
Run your own compatibility tests before deciding. Garage's S3 compatibility page leaves MinIO out of its comparison tables because MinIO does not publish a public S3 compatibility list, so there is no published baseline to compare against. Build a test set from the exact clients you use, such as backup software, SDKs, mc scripts and lifecycle jobs, and run it against a Garage test cluster with versioning-dependent and lock-dependent paths included. Record which calls fail, which succeed silently with different behavior, and which lifecycle rules you rely on, since Garage supports only AbortIncompleteMultipartUpload and Expiration. Ask your backup vendor and application owners to confirm their behavior in writing before any production bucket moves.
AGPL obligations and editions for each platform
The MinIO community server is released under the GNU AGPL v3.0. The license applies to the community code itself, and the project's README states that any commercial or proprietary use must be validated against AGPLv3 obligations. The README also says commercial licensing is available through AIStor, which is the vendor's separate commercial line, so an organization that wants to keep proprietary changes private or avoid AGPL duties has a path to evaluate beyond the community code.
- Source-only distribution: The README says the community edition is distributed as source code only, with no more pre-compiled binary releases, and legacy binaries will not receive updates. Teams that rely on prebuilt artifacts must build and sign their own.
- Community support: Support is best effort through GitHub and Slack. The README describes SLA-backed support as available only through AIStor.
- Commercial path: AIStor Free is described as a standalone edition under a free license, and AIStor Enterprise is described as a distributed edition with commercial support. Confirm the license terms and what each edition includes directly with the vendor.
- Network use: Under AGPLv3, an operator who modifies the code and lets users interact with it over a network generally has source-availability duties for those modifications. Confirm your exact obligations with counsel.
- Archived repository: The minio/minio repository is archived and read-only, so future fixes will not appear there.
Before you deploy or keep running the community server, have counsel review the AGPLv3 analysis for your specific use, and confirm with MinIO which commercial terms apply to your environment.
Garage is licensed under AGPL-3.0, the same family of license as the MinIO community server. That means the network-use duties discussed for MinIO apply here as well, so an operator who modifies Garage and offers it to users over a network should assume source-availability obligations for those changes. Garage is a free, self-hosted project, and the supplied facts do not describe a paid edition or commercial support tier for it, so confirm with the maintainers whether any commercial arrangements exist.
- Main repository: The main repository is hosted on Deuxfleurs' own Forgejo instance, with a read-only mirror on GitHub. Source access and contributions should be checked against the Deuxfleurs repository, not the mirror alone.
- Release tracking: Garage v2.0.0 was tagged on June 14, 2025, v2.4.0 on September 6, 2026 and v2.4.1 on September 7, 2026, according to the tags of the GitHub mirror.
- Funding history: Development has been funded by NGI POINTER (2021 to 2022), NLnet and NGI0 Entrust (2023 to 2024) and the NLnet NGI0 Commons Fund (2025), according to the Garage site.
- Support model: The supplied facts do not describe SLA-backed support for Garage. Ask the project or a service partner what support options exist and what they cover.
- Modified deployments: If you patch Garage for your environment, plan to publish or offer those changes under AGPL-3.0 when the network-use duty applies.
Confirm the current license file in the repository, the current funding status and any support arrangements before you rely on them in a procurement decision.
The AGPL is distinct from the GPL because it extends source-availability duties to people who interact with a modified program over a network, even if they never receive a copy of the binary. Both MinIO and Garage use AGPL-3.0 terms, so the same question applies to each: does your team modify the software, and do users, applications or partners reach it over a network? An unmodified deployment used only internally usually raises fewer issues than a patched build exposed to outside parties, but the exact line is a legal question.
- Unmodified use: Running the released code without changes generally keeps the duty narrow. Record exactly which version and source revision you run, so you can show what was deployed.
- Modified use: Patches, custom authentication hooks or changed console code can trigger source-offer duties when offered over a network. Keep those changes isolated so they are easy to identify and publish.
- Internal versus external users: Whether a service is internal or customer-facing can change the analysis. Ask counsel how your organization's network boundaries and third-party access affect it.
- Vendor-supplied builds: Commercial editions and vendor builds may carry separate terms. Compare the license that governs the exact artifact you deploy.
- Contributor terms: Check whether any contributor agreement applies before you send changes upstream.
Ask counsel to map each deployment, including integrations and vendor add-ons, against the AGPL duties before going live.
Procurement teams compare these two platforms on license text, support and the commercial route, but the answers differ in kind. For MinIO, the commercial route is defined by a vendor product line, AIStor, with its own terms. For Garage, the supplied facts describe an AGPL project with public funding history and no described paid tier. Writing down the questions in advance keeps the evaluation consistent and prevents assumptions about what a free license includes.
- For MinIO: Ask which AIStor edition, if any, covers your use, what support is included, what the license grants for your deployment, and whether the community code will receive security fixes.
- For Garage: Ask who maintains security fixes, what the response expectations are, and whether any commercial support exists through the project or third parties.
- Both: Ask for the exact license file and version you will deploy, and confirm it matches the source you reviewed.
- Both: Ask how a change of license or product direction would affect existing deployments, and what migration support is available.
- Both: Ask whether the vendor or project offers indemnity or written assurances, and what those cover.
Record the answers in writing with the quote or contract, and confirm all licensing points with your legal and procurement advisers.
What drives the running cost of each store
The license fee is often the smallest line in a self-hosted object store budget. Hardware, the people who run the store, the support path, release tracking and the compatibility testing you do before cutover all recur or land in the first months, and each one moves differently for MinIO and Garage.
Hardware and disk layout
Garage's published minimums are 1 GB RAM, at least 16 GB of disk, an x86_64 or ARMv7/ARMv8 CPU, latency of 200 ms or less and 50 Mbps or more between nodes. Its deployment guide suggests SSD for metadata and large HDDs for data, with XFS for the data directory and no RAID, since Garage handles multiple HDDs per node itself. MinIO's erasure-coded layout sets its own drive count and failure tolerance per cluster, so ask your architect to size drives, nodes and spares in writing before comparing hardware bills.
Staff skills and on-call load
Your cost here is the hours your engineers spend learning the store, patching it and answering pages at night. MinIO's erasure-coded clusters need people who understand drive replacement and healing across a fixed set of drives. Garage's sites and zones need people who understand replication placement and metadata engine choices, such as LMDB versus SQLite. Ask for the expected on-call rotation and the skills you must hire or train for, not a generic training estimate.
Support paths and their limits
MinIO's README says community support is best effort through GitHub and Slack, and that SLA-backed support is only available through AIStor. Garage's community path is documented on its own site and repository. If you need a contracted response time, the cost of that support is a commercial decision, so ask each vendor for written terms and compare what an incident looks like under each one.
Release tracking and upgrade effort
MinIO's community repositories are archived and read-only, and its last tagged community release was RELEASE.2025-10-15T17-29-55Z, published October 16, 2025. Garage publishes tagged releases, including v2.4.1 on September 7, 2026. Your upgrade cost depends on whether you must patch a source-only build yourself, which means assigning someone to watch advisories and rebuild, versus following a tagged release train that you test and roll out.
Compatibility testing before cutover
Garage's S3 compatibility page advises running your own tests before any serious decision, and it omits MinIO from its tables because MinIO does not publish a compatibility list. Your cost is the time to test the calls your applications, backup tools and lifecycle jobs make, including versioning, object lock and bucket policies, which Garage does not implement. Budget this as an internal project and ask any implementation partner for a written test plan with defined pass criteria.
What to ask for in a quote
A fee or effort figure is only meaningful from a written scope that names the systems, data volumes, sites, retention rules and acceptance tests. Ask for the deliverables, the assumptions behind each hour, what is one-time (design, migration, testing) and what recurs (patching, monitoring, support retainers), and which parts are your responsibility. DeployOpen agrees scope, deliverables and timelines in writing before work starts, so request that document for any figure you compare.
Moving buckets off MinIO without losing data
This sequence moves each bucket from the archived MinIO community server to a Garage cluster only after its features are mapped, its clients are tested and its copies are verified. The source stays untouched until the target proves it holds the same objects.
Inventory buckets and the features each one uses
List every bucket, its object count and total size, and whether it uses versioning, object lock, bucket policies, lifecycle rules, notifications, replication or tags. Record which access keys and clients read and write each bucket, because Garage uses its own per-access-key, per-bucket permissions and those must be rebuilt. The step is done when every bucket has a row in a written inventory that your security and application owners have reviewed.
Test compatibility with your actual client tools
Point the real clients, such as backup agents, the mc command-line client, SDKs and CI jobs, at a test Garage bucket and run the operations they perform in production, including multipart uploads, presigned URLs and CORS where used. Garage's S3 compatibility page lists what it does not implement, and it advises running your own tests before any serious decision, since MinIO publishes no comparable list. The step closes when each client either passes or has a documented workaround.
Decide the fate of each bucket
For each bucket, choose one of three outcomes: move to Garage as-is, keep on MinIO for now, or redesign. Buckets that depend on object lock, versioned retention or bucket policies are the usual candidates for redesign, because Garage does not implement bucket versioning, object lock or bucket policies. Record the decision and its owner in the inventory. The step is complete when every bucket has one outcome and no bucket is left undecided.
Build the target cluster with its replication zones
Deploy Garage on nodes placed so that the three zones map to real failure domains, such as separate racks, rooms or sites, since Garage stores each data chunk in three zones and places copies in different locations. Follow the deployment guide for metadata on SSD, data on large HDDs and the filesystem recommendations, and confirm the network meets the stated latency and bandwidth requirements between nodes. The step closes when the cluster reports healthy and a test object survives the loss of one node in a lab run.
Copy objects and verify checksums and counts
Copy each approved bucket from MinIO to Garage with a tool you can audit, and keep a log of source and target object counts, sizes and checksums. Compare the two sides object by object for every bucket, and investigate any mismatch before continuing. Object keys and data transfer through this copy, but access keys, policies and lifecycle settings do not, so export the key list separately for re-creation. The step closes when every bucket's counts and checksums match and the log is archived with the change record.
Cut over clients by endpoint and keep MinIO read-only
Switch each application or service to the Garage endpoint, bucket by bucket, using a scheduled change for each group of clients. Set the MinIO buckets to read-only during the window so no writes split the two stores, and keep them readable as a fallback. Rebuild the access policies, monitoring and backup jobs on the new endpoint before a client goes live. The step is done when every client reads and writes against Garage and no errors appear in its logs.
Hold the source read-only until verification completes
Leave the MinIO source in read-only mode for a period your change plan defines, and run a final comparison of object counts and checksums after the last client has moved. Confirm that backups written to Garage restore correctly in a test, since restore is the proof that matters for backup buckets. Do not decommission until the restore test and the final comparison both pass and the owners sign off. The step closes with a signed verification record for each bucket.
Decommission MinIO and retain the evidence
Once verification is signed off, remove MinIO services, stop scheduled jobs that reference the old endpoint, and delete the source data according to your retention rules. Keep the inventory, the compatibility test results, the copy logs and the restore evidence for your audit trail. Since the community edition receives no further updates and its last tagged release is dated October 16, 2025, do not leave it running as a fallback past the agreed window. The step is done when the old endpoint no longer answers and the evidence is filed.
Where implementation projects usually run long
The longest part of a Garage deployment is usually the physical layout, not the install. Garage ships as one self-contained binary, but its deployment guide recommends at least three nodes for three-way replication with copies placed in different zones, so the first design task is mapping servers to zones that match real failure domains such as separate racks, buildings or sites. Size the disks next: the guide recommends metadata on SSD, data on large HDDs, XFS for the data directory and a checksumming filesystem such as BTRFS or ZFS for metadata, with multiple HDDs per node handled natively without RAID. For MinIO, the equivalent work is drive layout and erasure settings. Erasure-coded sets have to be sized before data arrives, and expanding or rebalancing later is where teams lose time. Confirm the current erasure coding behavior in the minio/minio README and your own drive counts before committing hardware, since the community edition is now source-only and archived.
The delays that recur in both options come from three places. First, client compatibility: if your backup tools, lifecycle jobs or applications rely on object lock, bucket versioning or bucket policies, Garage does not implement them, and many clients fail quietly rather than returning a clear error. Run your actual client workflows against a test bucket, including restore paths, before migration is scheduled. Second, multi-site network tests: Garage's site lists a requirement of 200 ms or less latency and 50 Mbps or more between nodes. Measure those figures between your real sites under load, not only in a lab, and test what happens when one site drops. Third, the metadata engine: Garage's guide describes LMDB as the default and fastest engine, warns that LMDB files are not portable across CPU architectures and reports corruption after unclean shutdowns, while SQLite is offered as a more robust alternative. Choosing between them is hard to reverse, so decide it during design and test power-loss recovery before go-live.
Identity wiring and monitoring complete the picture. Garage uses its own per-access-key, per-bucket permission system, so each application's keys, bucket grants and rotation process need to be designed and documented, and any existing MinIO IAM policies must be translated by hand. MinIO's identity model depends on your configuration of its own users and policies, so map those separately. For monitoring, confirm which metrics and health checks each option exposes and wire them into your existing alerting before the first production bucket is created. Ask any implementation partner to put in writing which client tests, network measurements and failure drills are in scope, because those items, not the install, decide when the project is finished.
Questions buyers ask before choosing between MinIO and Garage
Is the archived MinIO community edition safe to use for a new install?
Treat it as unsafe for a new install unless you accept running software that no longer receives updates. The MinIO README says the repository is no longer maintained and points to AIStor Free and AIStor Enterprise as alternatives. The community edition is now distributed as source code only, and legacy binaries will not receive updates. The last tagged community release is RELEASE.2025-10-15T17-29-55Z, published on October 16, 2025, and the minio/minio, minio/operator and minio/mc repositories are archived. Support for the community software is best effort through GitHub and Slack, with SLA-backed support only through AIStor. Before deciding, confirm with MinIO which edition you would be licensing and what its update path is.
What does AGPL mean for an internal-only deployment compared with a service offered to others?
AGPL-3.0 obligations apply both to MinIO's community server and to Garage, so the choice does not change the license question. An internal deployment used only by your own staff generally raises different obligations than a service you offer to outside users over a network. The MinIO README says any commercial or proprietary use must be validated against AGPLv3 obligations, and commercial licensing is available through AIStor. Garage is also AGPL-3.0. Have your legal team review how you modify, host and provide access to each product, and confirm the terms with the project and your counsel rather than relying on a summary.
Can Garage replace MinIO backups that rely on object lock?
Not as a direct drop-in. Garage's S3 compatibility page lists bucket versioning and object lock as missing, and it does not implement bucket policies or server-side encryption configuration. If your backup process depends on immutable retention or versioned buckets, Garage cannot provide that behavior natively. Options to evaluate include redesigning the backup chain with a different target, using a separate tool that enforces retention, or keeping a MinIO-compatible or alternative store for those buckets. Confirm the exact S3 calls your backup software makes and test them against any candidate, since Garage's own page advises running your own tests before a serious decision.
How much effort does a move off MinIO involve, and what drives it?
The effort depends mostly on bucket count, data volume, the S3 features your applications use, and how much the target store must match. Moving objects is usually the smaller part. The larger work is inventorying buckets, checking which S3 calls clients make, reproducing access rules, and rewiring applications, backup jobs and lifecycle rules. Garage supports multipart uploads, CORS, presigned URLs, and lifecycle rules limited to AbortIncompleteMultipartUpload and Expiration, so anything beyond that needs a plan. Ask for a written scope that lists buckets, S3 features in use, cutover method and rollback steps before accepting a timeline or quote.
What does a Garage deployment need from our own team?
Your team owns the hardware, network and day-to-day operation, so plan for staff who can run Linux servers, storage and monitoring. Garage ships as one self-contained binary, and its site lists requirements of an x86_64 CPU from about the last decade or ARMv7/ARMv8, 1 GB RAM, at least 16 GB of disk, 200 ms or less latency and 50 Mbps or more between nodes. The deployment guide recommends at least three nodes for three-way replication, with copies placed in different locations, metadata on SSD, data on large HDDs, and XFS for the data directory. Confirm that your sites meet the latency and bandwidth limits before committing to a multi-site design.
Can our own team carry out the migration without outside help?
It is possible for a team with solid storage and Linux skills and a small, well-documented set of buckets, but the answer depends on your risk tolerance and available time. The hard parts are verifying S3 compatibility for your specific clients, choosing the metadata engine, and rehearsing cutover and rollback. Garage's deployment guide describes LMDB as the default metadata engine but warns about portability across CPU architectures and reported corruption after unclean shutdowns, and it offers SQLite as a more robust alternative. Your team should test those choices in a staging cluster before moving production data. If you want outside help, DeployOpen can assess the work and prepare a written scope.
How does a fixed-scope engagement get agreed in writing before work starts?
DeployOpen typically works from a fixed scope, with the scope, deliverables and timelines agreed in writing before work begins. For a storage move, the written scope should list the buckets and data volumes in scope, the S3 features your clients use, the target design, the cutover and rollback plan, the test evidence you will receive, and what you must provide, such as access, hardware and named contacts. DeployOpen does not publish a price list, so a quote follows from that written scope. Ask for the assumptions behind the quote, what changes would reopen it, and how ongoing support or upgrades are priced if you want them after the move.
How DeployOpen helps choose, implement or move off MinIO
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For MinIO vs Garage, we start by working out which S3 features your applications and backup tools actually need, then build and document the storage layer you choose, whether that is a replacement or a run-alongside setup.
How we scope
- Inventory which S3 calls, versioning, object lock, bucket policies and lifecycle rules your applications and backup tools depend on.
- Confirm the number of sites, the failure domains you need to survive and the network latency and bandwidth between them.
- Agree the written scope, deliverables and timelines before work starts, since most engagements are fixed-scope.
How we build
- Run your own compatibility tests against Garage and MinIO using your real client libraries, because neither vendor's published list replaces that check.
- Size metadata and data disks, filesystems and node counts against the hardware requirements you confirm for your environment.
- Configure the multi-site layout, access keys and per-bucket permissions, and test node loss before go-live.
How we hand over
- Document the topology, backup and restore procedures, key management and the bucket-by-bucket migration plan from MinIO.
- Provide the license and AGPL-3.0 obligation notes your legal team needs for both the current and the chosen platform.
- Walk your operations team through upgrades, monitoring and the runbook for replacing a failed node or site.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover.
- Retest the storage layer after each Garage release you adopt, so application compatibility stays documented.
- Prepare the controls and evidence your compliance assessors may ask for, while independent auditors issue any attestation.
