Which Nextcloud releases to hold, and why

Draft cornerstone post — GTM experiment #1, post 2 of 3 (see docs/gtm-plan.md §3). Not yet published. For a project blog + cross-post to r/selfhosted and the Nextcloud forums. Grounded in the same curated, cited judgment CADENCE ships (feed-sample/nextcloud). Re-verify version/EOL specifics against the linked sources before publishing — Nextcloud’s calendar moves fast.

If you self-host Nextcloud, you’ve learned the lesson the hard way at least once: "a new version is available" is not the same as "you should install it." Nextcloud ships fast, and a point release that is perfectly fine for a vanilla install can break a specific app you depend on. The skill isn’t upgrading — it’s knowing which releases to take immediately, which to hold, and which are non-negotiable. Here’s how to think about it.

1. First, the part that isn’t optional: the EOL clock

Apps and aesthetics are where the drama is, but the support window is where the risk is. Nextcloud supports only a rolling set of recent majors:

  • Version 31 and earlier are end-of-life (31 reached EOL around 2026-02-28). If you’re on 31 or below, you are running unpatched server software that holds everyone’s files — that’s not a "hold" situation, that’s a "schedule the move now" situation.

  • Version 32 is supported, but on a runway — its support ends around 2026-09-30. It’s a fine place to be today, but it’s a waypoint, not a destination: plan the hop to a newer major before the runway lapses.

  • 34 is the current line.

The takeaway: never let the base version fall out of support to avoid an app-compatibility headache. Running EOL to keep an app working is trading a known, bounded annoyance for an unbounded security risk. Fix the app problem (below) — don’t hide from it by staying on a dead release.

🔎 Source to check: the Nextcloud maintenance/release schedule.

2. The actual "which to hold" question: apps, not the core

Here’s the part the built-in updater notification will never tell you. The core server is usually fine. The thing that breaks is the interaction between a specific release and a specific app you have installed. A point release can ship a change that a popular app hasn’t caught up to yet, and you only find out after you’ve upgraded and your users can’t open documents.

A concrete, real example of the pattern: a server release that interacts badly with the Team Folders (groupfolders) and Nextcloud Office (richdocuments) apps — tracked upstream as nextcloud/server#55416. For an install that has those apps, the right verdict on that release isn’t "install" — it’s "blocked: this combination is known to break." For an install without them, the same release is fine.

That conditionality is the whole game:

  • The verdict depends on your installed apps, not just the version number.

  • "Hold" is often "hold for the next patch" — the fix is usually a release or two away, not a fundamental problem. The skill is knowing whether to wait days or weeks.

  • A generic "is an update available?" check cannot express "blocked if you run Team Folders + Office" — but that’s exactly the judgment that saves your weekend.

Practical rule: before any Nextcloud upgrade, list your installed apps and their versions, and check each against the target release. The release that’s safe for your neighbor’s install may be the one that breaks yours.

3. Don’t forget the database underneath

Nextcloud upgrades also carry dependencies on the layer below. A current Nextcloud expects a reasonably current PostgreSQL (think PostgreSQL ≥ 13 as a floor for recent lines, moving up over time). It’s a classic ordering trap: you plan the Nextcloud hop, kick it off, and discover the database is too old for the target version. Check — and if needed, upgrade — PostgreSQL first, then Nextcloud.

This is the same shape as the Proxmox→Ceph ordering: the question is never one product in isolation, it’s the product plus what it sits on.

🔎 Source: the Nextcloud system requirements.

4. A decision checklist

Before you upgrade Nextcloud:

  • Is your current base in support? If you’re on 31 or earlier (EOL), the upgrade isn’t optional — schedule it, app friction notwithstanding.

  • List your installed apps + versions. Check the target release against each — especially Office (richdocuments) and Team Folders (groupfolders), which are common breakage points.

  • Is there a known issue for your app combo on the target release? If yes → hold for the patch, don’t install.

  • Is PostgreSQL (and PHP) current enough for the target version? Upgrade the dependency first.

  • Are you on a runway version (e.g. 32)? Fine for now — but plan the next hop before its support window closes.

5. Why this is exhausting to track by hand — and what we built

Re-read the checklist. Every line is conditional and time-sensitive: depends on your apps, depends on your database, depends on where the EOL clock is this month. That’s hours of forum-reading per upgrade, repeated every quarter, for every stack you run. It’s exactly the kind of judgment that’s valuable precisely because it’s tedious to assemble and goes stale.

That’s CADENCE: a curated, signed upgrade-advisory feed. A human maintains the judgment — install / hold / wait-for-patch / blocked / EOL, with conditions like "blocked if Team Folders + Office are installed" or "blocked until PostgreSQL ≥ 13" — and a small, source-available appliance you host pulls the signed feed and evaluates it against your install’s actual apps and versions (your inventory never leaves your network). You get the verdict for your Nextcloud, not a generic one — plus a changelog of what the advice changed since last time, and an alert if a safety verdict was ever softened.

It covers Nextcloud, Proxmox/Ceph, PostgreSQL, GitLab, Traefik, and Docker Engine today.

  • Try the free Community feed + the source-available appliance: (GitHub link — pending launch)

  • Run Nextcloud for clients? We’re taking a handful of MSP design partners.

(Curated judgment current as of mid-2026; CADENCE’s job is to keep it current. Always confirm against the linked upstream sources before a production upgrade.)