Garage vs MinIO vs Managed S3 for Self-Hosting

Your photo app asks for an S3 endpoint. Your backup tool asks for one too. So should you run your own object store, or pay someone else to keep the objects?

My blunt answer: do not put the only copy of your backups in an object store on the same VPS as the data you’re backing up. A beautifully configured S3 API does not make a second failure domain appear. Once that’s settled, Garage, MinIO, and managed storage solve quite different problems.

The short verdict

• Managed S3-compatible storage is my default for off-site backups and small teams that do not want to operate storage infrastructure.
• Garage is compelling when you own multiple machines or sites and want a distributed, lightweight store you control. A single node is a lab, not redundancy.
• MinIO may fit an existing deployment that already relies on its tooling. For a new installation, inspect the current release, license, and support situation before committing your data to it.

None of these is a drop-in substitute for a verified restore. An upload success message only proves that one write worked.

Compare the failure modes, not just the feature lists

The comparison most people make is price per gigabyte. I would start with the boring questions: Can you restore after losing the entire VPS? Can your application actually use the provider’s S3 subset? Who gets paged when storage stops answering?

Garage: attractive when the topology is the point

Garage’s quick start makes it easy to try a single node. The project explicitly warns that this arrangement has no redundancy and that its example container does not persist data unless you mount volumes. That warning matters more than a benchmark screenshot.

Garage earns its place when you want to spread storage across infrastructure you already operate, with a topology you can reason about. Running one copy next to your app may simplify local object uploads, but it does not protect you from a provider account problem, a deleted VPS, or a bad backup script.

S3 compatibility has boundaries. Garage’s documentation calls out unimplemented features such as ACLs and policy support; read its compatibility reference against the actual API calls your client makes. A basic PutObject test is not enough if your app also creates buckets, manages policies, or depends on presigned URLs.

MinIO: ask which distribution you’re actually deploying

MinIO is familiar to many self-hosters, and that familiarity has value. Existing procedures, client tooling, and a working restore path can beat a fashionable migration.

But I would not choose a new object store from an old Compose snippet. Check the upstream repository, its current release and documentation, licensing, and the support path available for your use case. Pin a tested version, and test an upgrade with disposable data before touching the real bucket.

The operational burden is still yours. Disks fill, credentials leak, upgrades fail, and a reverse proxy can break uploads or signed requests. If you’re hosting backups, ask whether running MinIO is making your recovery story simpler or just adding one more service to recover first.

Managed storage: boring can be a design advantage

For VPS backups, I prefer an object store outside the VPS and ideally outside the same provider account. You trade infrastructure control for a smaller operational to-do list. That is not surrender; it is choosing which failures you want to own.

Read the actual bill model before signing up: storage, requests, retrieval, and outbound transfer can be priced separately. Check retention and object-lock capabilities if you need protection against accidental deletion or compromised credentials. Never assume a provider implements a feature because its marketing page says “S3-compatible.”

Separate credentials for backups, restrict their scope when supported, and keep a recovery copy of the credentials somewhere that survives the original server. Encryption at the backup-tool layer is worth considering even if the provider encrypts disks; those protections address different threats.

A five-minute compatibility trial

Before moving your app’s only data, create a disposable bucket and exercise the real client against it. Test object upload, download, listing, deletion, and any app-specific calls. If you rely on multipart uploads or presigned URLs, test those too.

Then perform a restore from a different machine. Try it with the primary VPS switched off in your mental model: do you still have the decryption key, credentials, documented bucket name, and a working client? If not, you have an upload pipeline, not a recovery plan.

For Docker deployments, also verify where the service persists metadata and objects. An object store with an ephemeral volume can look healthy right up until you recreate the container. Our backup guide covers the broader restore drill, including databases that need consistent dumps rather than a blind file copy.

Don’t confuse a commercial VPN with backup transport

A commercial VPN can help protect your connection on untrusted Wi-Fi while administering a server. It does not make a bucket redundant, encrypt your backup files end to end, or replace scoped storage credentials.

What I’d choose

If I had one VPS and needed reliable backups, I’d start with managed object storage in another failure domain, plus client-side encryption and a scheduled restore test. I wouldn’t host Garage or MinIO just to save a small monthly bill while making the only backup depend on the machine it protects.

If I owned several independent machines and wanted to learn or operate distributed storage, I’d trial Garage with disposable data first. If I already had a stable MinIO setup, I’d keep it until a concrete operational or compatibility reason justified migration. Pick the failure you can recover from, then test that recovery before trusting the architecture.