I missed the MinIO turn.

MinIO's community edition had been heading toward maintenance mode for months. I noticed when Reddit made it embarrassing to miss.

Sixth issue April 29, 2026 By Marlon McKinnie

On April 25, 2026, the MinIO repository was archived on GitHub. I did not catch it when it happened. I caught it a couple of days later when a Reddit thread surfaced it. The original poster had just been researching self-hosted S3 storage, ran into the archived repo, and asked whether MinIO was still worth adopting for a homelab. The replies were a fast tour of alternatives: Garage, SeaweedFS, RustFS, Ceph, Apache Ozone. That was useful. What I needed to decide was what to do about ArchiBotChat.

Why this mattered for ArchiBotChat specifically.

ArchiBotChat uses object storage for artifacts uploaded during a session, results written by the backend and retrieved by the frontend, and temporary files the backend manages for users. Once customers depend on that path, changing the storage backend means planning a customer migration.

The system had been using a shared MinIO path. That was fine when it was internal plumbing. It was less fine when I looked at the MinIO picture directly.

The signals had been building for a while. ItsFOSS tracked the sequence: community UI and feature removal in May 2025, the end of Docker images and prebuilt binaries in October 2025, a maintenance-mode message in December 2025, then archive events in February and April 2026. When I checked on April 26, 2026, the MinIO README described the community edition as source-only. It no longer provided precompiled binaries. Legacy releases remained for reference but weren't maintained, and MinIO directed enterprise and SLA workloads to AIStor.

MinIO can make that business choice. I still had to decide whether a source-only, maintenance-mode community path belonged under a product that hadn't launched.

Picking a replacement without pretending it was obvious.

An April 2026 Elestio comparison of RustFS, SeaweedFS, and Garage gave me a useful starting point.

RustFS was closest to MinIO's positioning: Apache 2.0, written in Rust, S3-compatible, and marketed for high performance. Elestio called it immature for production. In April 2026, its GitHub feature table marked some distributed and lifecycle work as under testing. I wasn't willing to make that the conservative pick for this product path.

Garage is built for geo-distributed and self-hosted deployments outside traditional datacenters. Good design, active project. The AGPL licensing and the multi-node topology assumptions were not a fit for the immediate use case, which was single-cluster artifact storage for ArchiBotChat.

The comparison framed SeaweedFS as the production workhorse. It also had a decision I could inspect: as of KFP 2.15, Kubeflow Pipelines changed its default object store from MinIO to SeaweedFS. SeaweedFS describes itself as S3-compatible, able to handle billions of files with O(1) disk access, and able to support file systems and Iceberg tables. I picked it.

The prelaunch decision.

ArchiBotChat had not launched yet. That changed the entire risk calculation.

Exhibit A: The decision tree If customers were already using artifact storage, the answer is a migration plan with compatibility preserved. When nothing is live yet, the answer is simpler.

if product_live:
  write migration plan
  preserve compatibility
  move customers deliberately
else:
  delete coupling
  replace backend
  prove the product path

Existing customers would have needed a careful migration: preserve the S3-compatible interface, move credentials, validate the new backend, and cut over deliberately. There were no customers on this path yet. I could delete the ArchiBotChat-specific MinIO coupling before anyone depended on it.

At that point, other services still used shared object storage. This change was limited to the ArchiBotChat artifact path before launch.

About 34 minutes from decision to passing smoke.

The migration ran in a single coding-agent session on April 26, 2026. Once I made the prelaunch deletion decision, the product smoke passed 34 minutes later. Follow-up hardening extended the session, but the storage path was already working.

The session covered application config, server code, product copy, deployment source, runtime storage config, and checks. The model still had to move between the source and deployment repositories. I just didn't have to rebuild that context at every step.

Elapsed time is the useful number here. I didn't capture a clean cost measure, and a cumulative token counter with cached context was not a bill.

Why the S3-compatible boundary paid rent.

The thing that made this fast was that ArchiBotChat was already using a generic S3-compatible object storage interface, not MinIO-specific APIs. The application called upload, download, delete, and health through that interface. Swapping the backend meant changing what sat behind that interface, not rewriting how the application talked to storage.

Exhibit B: The contract that survived The application knew only the S3-compatible storage contract exposed by the backend. It didn't call MinIO directly, which kept the swap contained.

artifact_storage:
  provider: s3-compatible
  caller: application-backend
  contract:
    - upload
    - download
    - delete
    - health

MinIO-specific endpoints, admin APIs, or health checks would have made the migration much harder. The adapter wasn't built because I predicted MinIO's change. It came from keeping application code separate from one infrastructure implementation. This is where that choice paid off.

What made the change real.

Moving config files wasn't enough. We ran the product path end to end.

Storage turn The signal only mattered after the product path passed

Signal Upstream changed The repo was archived and community editions moved to a source-only path.
Window Prelaunch No customer migration path existed yet.
Cut Remove coupling ArchiBotChat stopped depending on a MinIO-specific path.
Write Upload proof The backend accepted and stored an artifact.
Read Download proof The app read the artifact back through its own route.
Clean Delete proof The same product path removed it.

The upstream signal started the work. The prelaunch window made the cut possible. The proof was upload, download, and delete through the same route users would touch.

After the storage change reconciled, the frontend and docs stopped saying MinIO and started saying artifact storage or object store. The deployment source stopped creating a product-specific MinIO bucket and user. The runtime used the generic storage config.

Then I ran artifact upload through the backend route, download through the same path, and delete through the same path. Each step passed.

A running service and a 200 health response don't prove artifact storage. The product had to upload an artifact, read it back, and delete it through the same path customers will use. Follow-up hardening added a synthetic artifact check and recurring storage snapshots. I exercised both paths before closing the work.

I should have seen it sooner.

I did not catch the MinIO turn when it happened. The signals were there: the December 2025 maintenance-mode message landed in self-hosted and Kubernetes community threads months before the archive. I was working on other things. The system still worked. I did not look.

Open-source dependencies change. A project can change its license, support model, distribution terms, or maintenance level while your product still depends on it.

I could control how tightly ArchiBotChat was tied to MinIO. The backend owned the storage interface, and the app called that contract. The product path still worked after the backend changed. From the prelaunch decision to a passing smoke took 34 minutes.

That timing belongs to a prelaunch product. With customers already using the MinIO path, the migration would have been slower and more careful. Here, the storage boundary was in the right place and the check used the same path future customers would use.

Upstream risk is less scary when your product is not welded to one implementation.