Predastore publishes MinIO migration guide as archived object store goes unpatched

MinIO users left without security patches after the project's archival now have a step-by-step exit route, published on dev.to by the team behind Predastore.

An exit route for an archived object store

According to the guide, MinIO was officially archived in April 2026. With no security patches or bug fixes arriving, the post says administrators have been hunting for a maintained replacement, and it positions Predastore as one candidate.

The authors are quick to note that Predastore did not spring up in response: they say work began about a year and a half before publication, originally aimed at object storage for hardware-limited edge sites sitting on unreliable networks. The project has not fully reached that goal, they admit, but in its current form it handles the mainstream workloads MinIO was known for.

Predastore's architecture in brief

A cluster has two layers: hosts and nodes. A host is a single Predastore process, launched through the s3d binary, and each host can run multiple nodes with one of three roles:

• gate: exposes the S3 HTTP API, with at most one gate per host process.
• meta: a Raft replica holding bucket and object records, including where each object's shards reside.
• blob: a key-value store writing encrypted, erasure-coded shards to append-only segment files, with its storage location set through the data_dir config field.

Every host has its own IP address, and each node listens on a separate port so all nodes are individually addressable. Clusters need at least one node of every role, and the authors recommend pointing each blob node at its own disk for isolation. They also flag that design decisions are not final — the author is not yet sold on the "blob" label and invites naming suggestions via GitHub issues.

Standalone or under Spinifex

The first migration decision is deployment mode. Standalone offers a fixed set of service accounts, a single tenant, no external dependencies, and manual distribution of keys and certificates to nodes. Running under Spinifex brings IAM users, groups and roles, STS, multiple tenants, and automatic key and certificate distribution. The guide points readers to the project's README for help choosing between them.

Running alongside MinIO on the same drives

The most practically useful detail is that no new hardware is required. Predastore can occupy a .predastore directory on each drive MinIO already uses until the migration finishes. The leading dot is load-bearing: according to the guide, MinIO interprets any other top-level directory on its drives as a bucket and removes it along with that bucket.

Space planning matters, though. Each drive needs roughly as much free space again as MinIO consumes on it, plus headroom for re-syncs. The directories are bind-mounted into /var/lib/predastore with systemd options that make the service wait for the mount and refuse to start without it. The guide also advises leaving the mount-point directories owned by root, so that a missing mount stops Predastore from quietly writing to the system disk in its place.

Build requirements and configuration

For the simplest topology — a single node with one or more drives, in standalone mode — the guide asks for Linux with systemd, Go 1.27 or newer (most distribution packages of Go reportedly lag a few versions behind), git, make and openssl, plus the AWS CLI for post-install checks. Predastore is built from source; the guide targets v1.21.0, and notes that the install tooling (make install, predastore-keygen, the example config) first shipped in v1.20.0, so older tags will not work with these steps.

Configuration is minimal at this stage: copy the example TOML into place and set the region field to match whatever MinIO clients are already configured with, which the guide ties to how S3 clients sign their requests.

Coverage gaps to check first

Predastore is young and does not yet implement the whole S3 surface. The guide's central warning is to review the project's S3 API coverage page before starting; if an operation your workload depends on is absent, the team asks for a GitHub issue and says requests can sometimes land in a minor release. The guide is structured as a numbered sequence of at least five steps — mode selection and cluster setup come first, and step 5 is where you finish with MinIO.

Why it matters

An archived storage system is an unpatched one, and object stores tend to hold exactly the data that hurts to lose. That makes migration guidance genuinely valuable, especially guidance that avoids new hardware and lets the replacement run side-by-side on existing drives. The caveats deserve equal weight: this is a first-party guide written by Predastore's own developers, the project is roughly a year and a half old, and its S3 coverage is incomplete. Operators relying on less common S3 operations should verify support before committing — but for straightforward deployments, the guide meaningfully lowers the cost of leaving an unmaintained system behind.