A signed upgrade-advisory feed for self-hosters

Draft cornerstone post — GTM experiment #1, post 3 of 3 (see docs/gtm-plan.md §3). Not yet published. The category-defining explainer (the "what is this and why should I trust it?" post), to anchor the project blog / GitHub README and earn trust with the security-conscious reader. Pairs with the two "should I upgrade X" how-to posts. Reflects the locked architecture (docs/architecture.md).

The other two posts in this series answer specific questions — should I move this Proxmox cluster to 9? which Nextcloud release will break my apps? This one answers the question behind them: why does a product like this need to exist, and how can you trust advice about your infrastructure that comes from outside your network?

The problem isn’t "is an update available"

Every package manager already answers that. apt knows. Proxmox ships pve8to9. Nextcloud nags you in the web UI. The thing none of them answer is the one that actually keeps you up:

Should I install this update, and when? Will it break the apps I run? What has to happen first? Is the version I’d land on itself any good?

That’s not data. That’s judgment — and today it lives in scattered forum threads, release-notes footnotes, and the scar tissue of admins who upgraded first and found out later. You assemble it by hand, every time, for every piece of software you run, and it goes stale the week after you finish.

A few examples of judgment a version number can’t carry:

  • "Hold this Nextcloud point release — Team Folders and Office break on it; wait for the patch."

  • "Get Ceph to Squid before you touch Proxmox 9 — not after."

  • "This Docker Engine release has a docker cp flaw that gives a malicious container host root — patch now."

  • "Your PVE 8 cluster has ~10 weeks of support left; here’s the ordered path off it."

That curated, conditional, time-aware judgment is the product. Everything else is delivery.

How you deliver outside intelligence without becoming a risk

Here’s the legitimate objection, especially if you’re security-conscious or regulated: why would I let some external service see my infrastructure? You wouldn’t. So the architecture is built so you don’t have to. The model is the one Sonatype’s Repository Firewall uses — central intelligence, local enforcement, your data stays local:

  1. The advice is a signed, static feed. A human curates advisories — install / hold / wait-for-patch / blocked / eol, with conditions like "blocked until Ceph ≥ Squid" — and signs the feed with an ed25519 key. The feed is just files.

  2. You host the appliance; it pulls the feed. A small client runs in your infra. It pulls the signed feed, verifies the signature and every file’s hash before trusting a byte, reads your local inventory (from the source of truth — the Proxmox API, occ, NetBox, dpkg — not a dashboard), and evaluates the advisories against your versions and apps.

  3. Nothing about your estate ever leaves. The data direction is one-way, outbound-from-us-to-you, and pull-only. Your inventory, topology, and versions are never sent anywhere. The client has no reason to phone home, and doesn’t.

  4. It’s air-gap mirrorable. Because the feed is signed static files, you can sync it to an internal mirror exactly like a Linux package repo and run the whole thing disconnected. The signature — not the transport — is the trust anchor, so even a plain-HTTP or air-gapped mirror is safe: a tampered byte fails the hash/signature gate, fail-closed.

Why the appliance is source-available

Because the value is the feed subscription, not secret code, the appliance ships source-available. That’s deliberate: it sidesteps the "how do I trust proprietary code running in my infra?" problem entirely. Read it. Audit it. Confirm it does exactly what’s above and nothing else. The thing you pay for isn’t the binary — it’s the ongoing human work of keeping the judgment current.

What you actually get

  • Per-asset verdicts for your estate — not a generic "an update exists," but "for this cluster, with these apps, on this database: here’s the call, and here’s why."

  • Cross-product ordering — the dependency gates that cause the worst incidents (Ceph-before-Proxmox, PostgreSQL-before-GitLab) surfaced before you start.

  • CVE highlighting against your installed versions, and service-interval reminders ("cluster upgrade review overdue").

  • An audit trail — a tamper-evident, hash-chained local record of what advice you were given and since when ("we held this upgrade for a documented reason") — the paper trail a NIS2/patch-hygiene audit asks for.

  • A changelog of what the advice itself changed each time you pull, with a flag if a safety verdict was ever softened — so you’re never silently following weakened intelligence.

Today it covers Proxmox VE / Ceph, Nextcloud, PostgreSQL, GitLab, Traefik, and Docker Engine — the common backbone of a self-hosted estate — and the architecture is product-agnostic, so new software slots in as feed content without code changes.

The honest part

The feed is curated judgment, maintained by a human — which means its value is the cadence, and keeping it current is real, ongoing work (that’s the subscription). It is advice, never automatic action: CADENCE never writes to your systems. And it earns trust the only way intelligence about your infra can — by never seeing your infra, and by being checkable end to end: open the appliance source, verify the feed signature yourself, and read the upstream citation behind every verdict.

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

  • Pro (all modules, full cadence) / MSP (per managed estate, air-gap mirror rights): (pricing — see launch)

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