KUBERNETES UPGRADE REVIEW FOR PLATFORM TEAMS
Which changes in a new release matter for the way you run it? Prufyx connects supported upgrade constraints to your configuration, locally, with the upstream evidence, what needs attention and what to check next.
Evaluation runs on your machine, offline. No account, no hosted service, no configuration leaves your environment.
OPEN SOURCE · EARLY ALPHAExplore recorded examples and the source on GitHub, or browse the exact supported checks. Build the CLI from source; an official prebuilt release and knowledge feed are not published yet.
THE WORK BEHIND AN UPGRADE
Keeping Argo CD, Prometheus and the rest of a Kubernetes stack up to date means tracing removed settings, changed defaults and migration requirements back to each environment's configuration.
Two clusters can run the same version with different flags, values and dependencies. A version list alone cannot tell you whether the same upgrade needs the same preparation.
Prufyx is being built to turn that research into a local review of your current environment and proposed change: specific issues, supporting evidence and the next action. Today's preview covers exact, named checks shown below.
FROM YOUR SETTINGS TO A REVIEWABLE RESULT
The current checks connect a supported version transition and configuration condition to a result you can inspect locally.
Choose the current and target versions and provide the inputs required by the check. The examples below use local JSON values or supported workload declarations.
A reviewed rule checks a specific configuration condition against pinned upstream evidence. You can see which setting is affected and why it matters for that transition.
Review the required correction, a pass for the named check, or the missing evidence and next review step. A scoped pass does not clear the whole upgrade.
WHERE IT FITS IN YOUR WORKFLOW
GitOps keeps a cluster aligned with its declared state. The proposed change still needs a review: does a setting disappear, change meaning or require a migration in the target version?
Prufyx's local checks provide evidence for that review. Your team decides what to change, approves the release and keeps control of apply, sync and rollout.
A GitHub Action runs prufyx scan on pull requests today (build from source). Operators can also run supported checks explicitly with local inputs. Automated GitOps release gates are planned.
These are recorded cases from a synthetic, no-cluster run of the development CLI (prufyx check prometheus-mode --demo). This page does not run the CLI, verify runtime behavior, or connect to a cluster.
--enable-feature=agentATTENTION · DECLARED MODE CHANGES
The current 2.55.1 declaration selects Agent mode with --enable-feature=agent. The same flag in the proposed 3.1.0 declaration selects Server mode.
This identifies a declared mode change. It does not assert that the process fails to start.
ATTENTION: declared Agent mode changes to Server. Aggregate decision remains UNKNOWN.
PASS applies only to declared mode preservation. Every case keeps the aggregate decision UNKNOWN. Runtime mode, startup, data safety, remote-write behavior, and whole-upgrade compatibility are outside this check.
cert-manager 1.20.3 → 1.21.1. The check examines three removed monitoring settings in a local, already merged JSON values file. This page shows a recorded result; it does not read or upload configuration.
prometheus.servicemonitor.pathThe reviewed 1.21.1 chart rejects this key. Its metrics endpoint uses /metrics and http-metrics. The same check covers prometheus.servicemonitor.targetPort and prometheus.podmonitor.path.
The target chart digests and source revision are recorded in the report. Declared versions select that contract; they do not prove which chart is deployed.
Inspect the pinned target schema ↗Helm also catches this schema rejection. Prufyx provides a focused migration explanation and a reproducible local report. It does not validate the full chart schema. Absence passes only these three settings; explicitly bypassed schema validation produces ATTENTION when a removed override would be ignored.
Named checks and transitions, with their inputs and limits visible. Unsupported or missing evidence stays UNKNOWN.
Read-only collection is explicitly configured. Component configuration is optional. The opt-in v3 profile derives selected declared facts from supported Kubernetes workloads.
The cert-manager check reads proposed JSON values without cluster access. The Prometheus check uses a fresh v3 observation and a proposed apps/v1 Deployment or StatefulSet JSON file. Evaluation is offline.
Other versions or image pins, wrapper commands, ambiguous matches, stale observations, and incomplete controller reads remain UNKNOWN. They cannot produce a scoped PASS.
You choose which supported component inputs to provide. The retained v3 facts omit raw command lines, environment values, workload names, private image references, configuration dumps, Secrets, ConfigMap contents, credentials, and raw Kubernetes objects. This is a reviewed projection of supported inputs, not a collector for every process in a cluster.
The website receives none of these inputs. It has no cluster connection or upload form.
The recorded native mode demonstration covers only Prometheus 2.55.1 → 3.1.0, using the reviewed linux/arm64/v8 platform manifests and admitted direct-entrypoint argument forms.
docker.io/prom/prometheus:v2.55.1@sha256:f4def6b3b61109a6eeea59945d578bb7e926c36cb0e036a23e3ceb8b6de024addocker.io/prom/prometheus:v3.1.0@sha256:0ea5254abf85f87901e8cfbd18fd243c59162c338ce0acd86aa2b0153d83dce2The equivalent prom/prometheus repository spelling is accepted. A multi-platform index digest or a version tag alone is insufficient.
The CLI requires explicit observation identity, capture time, evaluation time, and maximum age. The proposed input is a local JSON file with mode 0600. Multiple matching containers or unresolved command forms remain UNKNOWN.
The open-source CLI pairs exact configuration checks with versioned knowledge. You can inspect the supported transitions and keep evaluation local. Whole-upgrade compatibility remains UNKNOWN.
How deep is the coverage? Over the last five minor upgrades of 55 projects (275 upgrades between release lines), 0 are decided as a whole, 44 have a rule for one exact version pair, and 231 have no valid rule. Kubernetes has no rule for upgrades after 1.32 yet. How this is measured →
The development CLI can explicitly download a signed knowledge package, verify it locally and preserve an older revision for replay. Existing checks do not refresh silently.
A separate local release-plan file can bind explicit URL and digest assertions for compatible CNCF constraints. It is unsigned, does not establish publisher trust or bootstrap authority, and does not make an official metadata feed available.
After a signed knowledge package is imported, newly reviewed exact version pairs can reuse existing canonical facts and admitted input formats without a CLI update. Neutral community-project checks are embedded in the CLI and are not refreshed through the signed CNCF updater. New fact types or input formats may require a CLI update. Local prepare cncf adapters support only documented input forms; expanding preparation from raw inputs may require a CLI update.
argocd-cm inheritance check is implemented in the CLI. It evaluates only the supplied ConfigMap setting server.rbac.disableApplicationFineGrainedRBACInheritance together with explicit operator intent: with intent true, setting true is a scoped blocker and setting false is a scoped pass; intent false or absent, and an absent or malformed setting, remain UNKNOWN. Separate neutral checks cover an explicitly required removed MariaDB 10.11.8 → 11.4.2 InnoDB defragmentation behavior and the MariaDB Operator 26.3.0 → 26.6.0 Galera data-plane prerequisite. These checks do not inspect RBAC, reproduce application runtime, or prove a whole upgrade safe.assess recognises more components from reviewed container-image sources, and reports a component whose image has no usable version as indeterminate rather than mismatched; the knowledge store installed by db update is used by check and scan and an invalid or expired store is refused; check --strict-exit makes a scoped PASS exit 14 so CI cannot read it as a complete pass; scan shows terminal and bidirectional control characters from the input as visible escapes; derived Kubernetes API-removal rules name the removed kinds and the version to migrate to; scan leaves removed APIs in Helm subcharts that may not be rendered as UNKNOWN; assess reports what it observed and prints pure JSON with --format json; release builds are reproducible and carry their build identity, and the GitHub Action verifies attestation by default; a coverage report measures how much of each project's recent upgrades the rules decide. Full list in the changelog.FUTURE DIRECTION · NOT AVAILABLE IN THE COMMUNITY PREVIEW
The next direction is testing specific upgrade scenarios in representative, non-production environments, with customer-controlled execution. Each test would state what it reproduces, approximates and leaves out.
This is planned work. Managed test environments are not available, and a representative test would provide evidence only for the scenario it exercises.
For air-gapped and restricted environments
Prufyx evaluates offline and takes its knowledge as a signed package that you import from a local file, verified against a trust root you obtain independently. There is no automatic update and no startup refresh; nothing changes unless you run it. Because no data leaves your environment and there is no hosted Prufyx evaluation service, there is nothing of yours for us to hold or certify; your own controls still apply. See how offline import works →
db verify and imported with db import from a local file, without a network connection.db update fetches from a URL you choose and sends no configuration, report or path. No account, no telemetry, no startup refresh.assess with an explicit kubeconfig, context and acknowledgement. Nothing is uploaded.For air-gapped and highly regulated environments
Each Prufyx result is deterministic: the same input, knowledge and evaluation time (--now) give the same report, and the report records the input digest, the rule evidence and the build identity. A saved check report can be replayed with --replay-report and must reproduce byte for byte. When the evidence does not decide a question, the answer is UNKNOWN, not a guess. See replayable reports →
Open source
Tell us which component and version transition took time to review, what you had to investigate and which evidence helped you decide. That is the work Prufyx is being built to reduce.
The Prufyx repository includes the reviewed source, examples and contribution workflow. The code is licensed under the AGPL-3.0 and the reviewed knowledge data under CC BY-SA 4.0. Evaluation is designed to stay local and requires no account or model. It does not publish an official prebuilt CLI or metadata feed.
Maintained by Spas Atanasov. The project has not measured customer time or cost savings.
Describe the problem in general terms and share public source links only. Please do not send configuration, credentials or cluster data.
Discuss your upgradeEmail opens your mail app. Nothing is sent automatically.
Maintaining a project? Contribute evidence →Support Prufyx
Prufyx is built in the open by an independent maintainer. Keeping cited upstream knowledge current across the projects with rules today and the 255 catalogued ones takes real compute. We need one build-and-research workstation.
Help operators understand a real change in your software. The open-source CLI includes an offline evidence-packet validator, examples and a contribution template. Read the contribution guide and upstream evidence workflow before proposing a bounded project check.
Identify the project, exact versions and affected options. Pin the upstream source and the lines supporting the claim. Use public or synthetic examples.
Provide a blocking case, a non-blocking case and the missing-evidence boundary. Run the local packet validator. Its receipt confirms a consistent candidate; it does not verify upstream evidence or prove that an upgrade works.
Independent source review and tests come before acceptance. Accepted rules can then enter a separately verified knowledge package. Submission never publishes a rule automatically.
Maintainers can explicitly capture a bounded set of immutable public GitHub files and check their declared file and line hashes. Offline tools verify individual source collections or multiple collections together, reject conflicting metadata and count shared files once. A review-record verifier checks a bounded record's packet, corpus and receipt bindings alongside exact versions, source spans, scoped claims and declared review decisions. It does not verify upstream claims, authenticate a maintainer decision, or publish or adopt a rule. These tools are separate from the product CLI and receive no customer configuration. Saved release notes do not add compatibility coverage by themselves.
Model-assisted extraction is a future option for public, permissioned sources. A model cannot approve a compatibility claim. Customer configurations are not training submissions.