Releases · Garage

Garage 2.5.0 makes lifecycle endpoints owner-only and will not downgrade

Garage v2.5.0, published 24 October, is the S3 store this desk named when MinIO archived its repository. It ships three upgrade notes that matter more than its feature list: no downgrading an upgraded node, bucket lifecycle endpoints restricted to owner-permission keys as a deliberate security change, and a new public_endpoint setting to add to garage.toml.

By BoneSaturday 24 October 20263 min readReleases

entryread only

filedSaturday 24 October 2026

length3 min

sectionReleases

subjectGarage

sourceson the page

When MinIO archived its open-source repository, this desk named Garage as an S3 alternative, while saying that how actively either alternative is maintained is a question for its own releases page. Garage has since answered that with v2.5.0, published 24 October, and the release opens the way a project with real operators should: “This release is a stable release. Please be aware of the following when upgrading.”

What follows is three notes, and only the first is routine housekeeping.

The three upgrade notes

The first is about reversibility. “This release of Garage is not backwards-compatible: once a node is upgraded, you must not downgrade it back to older Garage versions. You can still mix-and-match nodes running older and newer versions of the v2.x branch within a cluster.”

Read that literally and it is a cluster constraint, not a single-machine one. Mixed v2.x nodes are allowed, so a cluster can run a mix of old and new while you work through it. What is not supported is rolling back a node once it has run 2.5.0, which removes the usual escape hatch when an upgrade misbehaves. The practical consequence is that the upgrade is a one-way door per node, and the decision to take it should be made before, not during, a rollback.

The second is the security change. “Access to (Put/Get/Delete)BucketLifecycle is now restricted to keys with owner permission. This breaking change has been introduced in this release for security reasons. Adapt your workflows accordingly.” That covers the three lifecycle operations by name, and the changelog entry behind it reads “s3: (breaking/security) restrict access to lifecycle configuration endpoints (#1573)”. Anything automating lifecycle rules with a key that is not an owner will start failing after the upgrade, and it will look like a permissions problem rather than a version problem.

The third is a recommendation rather than a break: “It is recommended to add the newly-added public_endpoint parameter to your garage.toml configuration files.”

The rest of the changelog

The other security entry is a crash fix: “fix panic with invalid utf8 in url after percent decode (#1581)”. No CVE identifiers appear in this release page, and nothing here suggests exploitation.

The features are the kind an operator notices slowly. A new advertise_endpoint configuration parameter (#1563, #1587), GARAGE_LOG_FORMAT=json to write JSON lines to stderr (#1568) for anyone shipping logs into something that parses them, CLI export of key-id and secret-key (#1176, #1504), the resync queue size added to garage status (#1556), and details, offset and limit parameters on the Admin API’s ListKeys and ListBuckets (#1490, #1500). There is also a block deletion metric (#1040, #1515) and, on the Kubernetes side, an admin API exposed in the Helm chart (#1466).

What this means if you moved

For someone who read the MinIO piece and started evaluating Garage, the useful signal is not any single feature: it is a stable release, dated, with breaking changes documented up front and a security entry that restricts access rather than granting it. That is what an active project looks like from the outside.

For someone already running Garage, the work is narrow and worth scheduling: inventory the keys your lifecycle tooling uses, and give those workflows an owner-permission key before you upgrade, because the release presents the change as deliberate rather than incidental. Then take the upgrade one node at a time, remembering that each node that crosses is a node you cannot put back.

What this release page does not contain is an upgrade procedure, and this piece will not invent one. The three notes above are the release’s own words; the steps belong to the project’s documentation, which is where an operator should be reading next anyway.

Sources: the Garage v2.5.0 release page.

ReleasesHomebridge 2.5.0 is a Matter release: new device types, and fixes for identity and cacheHomebridge 2.5.0 adds Matter device types for solar, battery, EV chargers, meters, tariffs and water heaters, and spends the rest of its list on behaviour that used to go wrong: air quality reporting only two levels, thermostats registering late, restored accessories losing their uniqueId or owner, and cache reads that took the accessory with them. It also bumps @matter/main to v0.18.0 and @homebridge/hap-nodejs to v2.3.0.

ReleasesMealie 3.30.0 lets you own the AI prompt, time each step, and plan a whole weekMealie 3.30.0 moves AI prompt control into the app, so prompts can be appended to, replaced or extended with global instructions, and it retires the OPENAI_CUSTOM_PROMPT_DIR variable while importing existing prompts automatically. Instruction steps gain individual durations, meal plan entries can cover a full week, and a batch of fixes tightens import scoping, locale lookup and the permissions needed to manage units, tools, labels and recipe actions.

ReleasesMemos 26.10.0 signs API clients out, stops reading /etc/secrets and makes export an admin jobMemos 26.10.0 is the first release under calendar versioning, and its upgrade notes matter more than its features: old installs need a 0.31.0 waypoint, cached access tokens expire on upgrade, the /etc/secrets files from 0.31.0 are no longer read, member export disappears, and the old upload and memo-length settings are replaced without migration. The features are a rich editor by default, per-user usage limits and declarative configuration.