Coolify dropped MinIO from its catalog and the community console lost its admin tools. This guide deploys a security-patched MinIO server plus the full OpenMaxIO admin console on Coolify, then proves it works with a real S3 test you run from your own machine.
Two things broke recently if you self-host object storage. Coolify removed MinIO from its one-click catalog, and MinIO gutted the admin UI out of the community edition. Old guides no longer work.
I run MinIO in production, so I rebuilt it properly on Coolify. Current, patched, with the full admin console back. Then I tested every operation with a real S3 client until it all passed. This guide is the exact setup I landed on: paste-ready files, plus every trap I hit so you can skip them. Object storage is one box on that VPS. Standing up the whole stack, and keeping it alive when an upstream walks away like MinIO just did, is what I teach in Self Hosting 2.0 .
Two containers, two steps. Let's go.
Your two domains (optional)
Drop in the S3 API domain and the console domain you'll use for this install. We'll plug them into every copyable block on this page so you can paste with no edits. Values stay in your browser only, nothing leaves this page.
Values stay in your browser only, nothing leaves this page.
You only need this because it explains a couple of odd choices below:
The point: the MinIO server still works perfectly. It's the project that's frozen, no patches, no images. So we'll use a patched image someone rebuilt from source, plus a community fork for the UI.
MinIO server Required
Stores data, speaks S3.
OpenMaxIO console Optional
That's one service. Real setups run several on one VPS, sharing RAM, SSL, and backups without stepping on each other. That orchestration is the spine of Self Hosting 2.0 . This guide is one self-contained piece of it.
🧠No Coolify yet, or new to running a VPS? Self Hosting 2.0 takes you from a blank server to a full stack, databases, email, storage, and backups, the same way this guide does MinIO.
This assumes Coolify is already running. If it isn't, install Coolify first , then come back here.
In Coolify: open your project, click + New , choose Docker Compose Empty , paste the compose below, and Save . Read the comments. Every odd-looking line is solving a real problem.
Quick read of what you just pasted. Two services. minio is the server. console is the OpenMaxIO admin UI, an image I built, since OpenMaxIO ships code but no ready-made image. Both live on my Docker Hub on purpose: if an upstream image disappears, this guide still works. Given this whole saga, that's a real risk.
âš Provenance: my minio image is a straight mirror of coollabsio/minio:RELEASE.2025-10-15 , the patched MinIO release Coolify's founder rebuilt from source. The last official image shipped the security hole; the patched one was never published officially. Want ongoing patches instead of a pinned release? cgr.dev/chainguard/minio:latest drops straight in.
Point a DNS A-record for each subdomain at your server. Then open each service in Coolify and paste its domain into the Domains field. No port needed. The SERVICE_FQDN_MINIO_9000 and SERVICE_FQDN_CONSOLE_9090 lines in the compose already tell Coolify which port each domain maps to.
Paste this into the minio service's Domains field:
And this into the console service's Domains field:
This trap looks impossible until you know it. With everything else right, S3 calls fail with:
âš That error is lying. Your keys are fine. AWS Signature V4 locks every request to the server's hostname. It's like a key cut for one exact lock. Your client cuts it for s3.example.com . But behind a proxy, MinIO is holding a different lock: it doesn't know s3.example.com is its own front door. The key doesn't turn, so it blames the key.
Fix: tell MinIO its public URL. In Coolify, open your resource, go to Environment Variables , and add these two as literal values:
MINIO_SERVER_URL makes signatures validate. It fixes presigned URLs too, same cause. MINIO_BROWSER_REDIRECT_URL is its required companion. Add both in the env UI , not the compose. A Coolify Service Stack doesn't reliably inject literal URL values from the compose file.
Hit Deploy . When it's up, open your console domain. Coolify generated your login and shows it right on the service page, an Admin User and an Admin Password . Copy those in.
You should now see the full console: buckets, Identity → Users, Policies, Access Keys, Configuration. Everything MinIO removed, back.
Clicking around the UI proves the console reaches MinIO. It does not prove your apps can. That traffic takes the external path through the proxy, which is different. So test it like a real client.
First, create an access key in the console: Access Keys → Create . That's separate from your admin login. Keep the key and secret handy. Then test it like a real client, from your own machine.
This runs the same create, upload, download, presigned, and delete cycle a real app does, against your public endpoint. So it proves your apps can reach the storage, not just the console. Run pip install boto3 requests , fill in the top of this script, and run it:
11/11 means you're done: reachable, S3-compatible, big files via multipart, presigned URLs working. That same client config is exactly what your app code needs too.
The whole reason this guide is worth reading. Each of these cost me real time:
Make a dedicated console user. First, generate a secret key, the original openssl rand trick fails on minimal MinIO images that don't ship openssl :
Generated here in your browser, then dropped straight into the mc admin user add command below, so you never depend on openssl being inside the container. Click for a fresh one anytime.
Generated in your browser with the Web Crypto API. Nothing leaves this page.
Then run this from the MinIO container's terminal in Coolify. Paste the whole block at once, the shell runs each line in turn:
console is the new user's login (its access key) and the generated value is its secret. The last two lines grant that user full admin rights. Now log in to the console with access key console and that secret, instead of root.
Now that you have storage running on the same Coolify server, you can wire it into the rest of your stack, the same way you'd add PyRunner for scheduled Python jobs next to it.
MinIO went source-only and stopped publishing official Docker images around October 2025, and the minio/minio repo was archived in April 2026. With no maintained image to point at, Coolify dropped MinIO from its one-click catalog. The server still works fine, which is exactly what this guide gets you running.
The MinIO server itself still works well. The catch is that the last official image ( RELEASE.2025-09-07 ) ships an unpatched, high-severity security hole (a CVE), and the fix in RELEASE.2025-10-15 was never published as an official image. This guide uses a patched build rebuilt from source, so you run the fixed version.
The community console was stripped down to a plain object browser. The last release with the full console was RELEASE.2025-04-22 . To get identity, policies, and access-key management back, you run the OpenMaxIO console, the last full version of that same console, forked by the community.
OpenMaxIO is a community fork of the last full MinIO console. The MinIO console was always a separate program from the server; old MinIO just bundled them. OpenMaxIO keeps that full console alive as a standalone container you point at your MinIO server with CONSOLE_MINIO_SERVER .
Because MinIO doesn't know its own public URL. AWS Signature V4 signs each request using the host, and behind a proxy MinIO validates against the wrong host, so it reports a signature mismatch as "access key does not exist." Set MINIO_SERVER_URL and its companion MINIO_BROWSER_REDIRECT_URL to your public domains in Coolify's environment variables, then redeploy.
No. The MinIO server is the only required piece; it stores data and speaks S3. The OpenMaxIO console is an optional admin UI. Run only the server and your apps already have working object storage; add the console when you want a browser to manage buckets, users, and keys.
Yes. If you'd rather not run a frozen project, cgr.dev/chainguard/minio:latest gives you an ongoing-patched MinIO image you can drop straight into the compose.
Create a short-lived access key in the console, then use any S3 client you already trust. The MinIO mc client can list, copy, and remove objects from your terminal in a couple of commands. The boto3 script above is the most thorough check though, since it also exercises multipart uploads and presigned URLs the way a real app does. Delete the test access key when you're done either way.
This guide gets you a working, patched, fully manageable MinIO. The real work starts after, when object storage is one of several services sharing a single VPS, all of them needing backups, monitoring, and a safe update path.
That's what I cover in Self Hosting 2.0 . The full course is 34 lessons that walk through:
🔒 Before you put MinIO in front of real users, lock it down. The defaults above are the floor, not the ceiling. The short list:
I walk through each one with the exact commands and rollback notes in Self Hosting 2.0 .
Want the full system?
Hasan Aboul Hasan builds open-source tools and teaches solo developers how to build, host, and sell AI-powered products. Founder of LearnWithHasan.com , creator of SimplerLLM and PyRunner .
The exact building blocks I use to ship real products with AI — yours as a free PDF.
Have a question? Ask it in the community — it's tagged #guide and linked back here. Reading is open to everyone; posting needs a free account.