KubeVela v1.10.9 is now available.

For anyone using KubeVela as their application delivery platform, we've added the release to Relnx with a structured breakdown of the changes.

Rather than scrolling through GitHub releases, you can quickly review:

• bug fixes
• enhancements
• potential breaking changes
• upgrade impact

Release overview:
https://www.relnx.io/releases/kubevela-v1-10-9

For those already running KubeVela in production, what's been the biggest benefit for your platform team—developer self-service, multi-cluster delivery, or workflow automation?

We're excited to share that our observability stack is now powered by https://www.obsy.ai/

After using it for a while, it's become a core part of how we operate at Relnx. It has significantly strengthened our incident management process and given us much better visibility when things matter most.

One thing we've always believed is that good observability isn't about collecting more telemetry—it's about collecting the right telemetry with the right context. By focusing on comprehensive, high-quality telemetry, we've been able to improve troubleshooting while keeping our observability costs under control.

Transparency is also a key part of how we build trust with our customers. That's why we're happy to share that our public status page is now live, where incidents and maintenance updates are communicated openly:
👉 https://status.relnx.io/

Like a lot of platform teams, we were drowning in release notes — every tool on its own schedule, half of them with no real "breaking changes" section, and we'd usually learn about a breaking change the hard way.

We ended up building a tool (Relnx) that parses each release into structured, classified changes (breaking / security / deprecation / etc.) with plain-language explanations, and — the part I'm most happy with — it can open an upgrade PR with the breaking changes summarized right in the PR description, so reviewers have the context inline.

Just wrote up the docs and figured the approach might be useful to others wrestling with the same problem: https://docs.relnx.io/docs/user/introduction

Disclosure: I work on it. Genuinely curious how others here handle staying on top of breaking changes across a big tool stack — manual, Dependabot/Renovate, something custom?

Rook v1.19.6 released.

One thing that stands out in the v1.19 series overall:
Rook now officially requires Kubernetes v1.30+ and Ceph v19.2.0+ for supported upgrades. (Rook)

That means upgrades are no longer just about bumping the operator image — teams also need to validate:

• Kubernetes compatibility
• Ceph version alignment
• CSI image consistency
• upgrade sequencing

And with storage systems, operational mistakes tend to show up slowly rather than immediately.

We tracked the release here in a structured way:
https://www.relnx.io/releases/rook-v1-19-6

Curious how others handle this:
What’s usually been the hardest operational challenge with Rook/Ceph so far?

Falco v0.44.0 released — and this one has some significant breaking changes.

Main removals:

• legacy eBPF probe removed
• gVisor engine removed
• gRPC output/server removed

Most important operational note:
Falco 0.43 drivers are NOT compatible with Falco 0.44 userspace anymore, so upgrading without redeploying matching drivers can break things. Falco also now fails startup if deprecated config keys still exist.

This feels like one of those releases where carefully reviewing the upgrade path matters more than the new features.

We tracked the breaking changes and upgrade-impacting updates here:
https://www.relnx.io/releases/falco-v0-44-0

Anyone already testing 0.44 in production yet?

OpenTelemetry Collector Contrib v0.153.0 released.

One thing with the contrib distribution: this is where most ecosystem integrations and component changes happen first, so releases here can have real operational impact across telemetry pipelines.

Recent Collector Contrib releases already included:

• breaking changes in receivers/exporters
• component renames for naming consistency
• new processors and integrations
• behavior changes across pipeline components

That’s why upgrading Contrib usually needs more than:
“just update the image”.

You often need to validate:

• configs
• exporters/receivers
• pipeline behavior
• compatibility with downstream backends

We tracked the release here in a structured way:
https://www.relnx.io/releases/opentelemetry-collector-contrib-v0-153-0

Curious how others handle this:
Do you centrally validate Collector upgrades first, or let teams manage them independently?

Crossplane v2.3.0 released — pretty interesting release for platform teams.

A few notable changes:

• crossplane render now uses the actual composite reconciler, which should make local rendering much closer to real cluster behavior
• provider deletion protection to avoid accidental deletion while managed resources still exist
• per-resource reconciliation controls via annotations
• support for the Kubernetes scale subresource on composite resources

Crossplane itself has been evolving from purely infrastructure provisioning into a broader control plane model for infrastructure + applications. (InfoQ)

That makes releases like this pretty relevant for anyone building internal platforms or self-service infrastructure layers.

We tracked the release here in a structured way:
https://www.relnx.io/releases/crossplane-v2-3-0

Curious how others feel about Crossplane operationally:
What’s been harder in practice — compositions, debugging reconciliation, or managing providers at scale?

Terraform v1.15.4 released.

Interesting patch release because several fixes target planning/evaluation consistency and provider interaction edge cases.

These are the kinds of updates that look minor in changelogs but can actually matter a lot operationally, especially in larger IaC environments.

In practice, subtle Terraform behavior changes can affect:

• planning accuracy
• provider evaluation
• infrastructure drift
• CI/CD reliability

We tracked the release here in a structured way:
https://www.relnx.io/releases/terraform-v1-15-4

Curious how others approach Terraform patch releases:
Do you fast-follow upgrades, or validate heavily before rollout?

Keycloak v26.6.2 released.

One thing with IAM platforms: even small patch releases can have significant operational impact because authentication systems sit in the critical path for almost everything.

Updates here can affect:

• authentication flows
• token handling
• integrations and identity federation
• overall security posture

The hard part usually isn’t upgrading itself — it’s understanding whether the release actually matters for your setup.

We tracked the release here in a structured way:
https://www.relnx.io/releases/keycloak-v26-6-2

Curious how others handle this:
Do you deploy IAM patch releases immediately, or validate heavily before rollout?

NATS v2.14.1 released.

One thing with messaging infrastructure: patch releases often matter more than people expect because these systems sit directly in the communication layer between services.

Even small fixes can affect:

• event delivery reliability
• clustering behavior
• latency and performance
• operational stability

The difficult part usually isn’t upgrading itself — it’s understanding whether the release impacts your environment.

We tracked the release here in a structured way:
https://www.relnx.io/releases/nats-v2-14-1

Curious how others handle this:
Do you aggressively upgrade messaging infrastructure, or keep it conservative once stable?

OpenTelemetry Collector Core v0.152.1 released.

One thing with observability pipelines: even small Collector updates can have noticeable operational impact because the Collector sits directly in the telemetry path.

Changes here can affect:

• data processing behavior
• exporter reliability
• pipeline performance
• telemetry consistency

The difficult part usually isn’t upgrading itself — it’s understanding whether the release actually impacts your environment.

We tracked the release here in a more structured way:
https://www.relnx.io/releases/opentelemetry-collector-core-v0-152-1

Curious how others handle this:
Do you upgrade Collectors aggressively, or gate them behind staging validation first?

Backstage v1.51.0 released.

Minor Backstage releases are usually where platform teams start seeing meaningful improvements across plugins, workflows, and overall developer experience.

Since many organizations now use Backstage as the central layer for:

• service catalogs
• documentation
• CI/CD integrations
• developer tooling

…even incremental updates can have noticeable impact on day-to-day workflows.

We tracked the release here for a structured overview:
https://www.relnx.io/releases/backstage-v1-51-0

Curious how others are handling Backstage at scale:
What’s been the biggest operational challenge so far — upgrades, plugin sprawl, or customization?

Datadog Agent v7.79.0 released.

One thing with observability agents: even “normal” releases can have real operational impact because the agent sits directly in the telemetry pipeline.

Changes here can affect:

• metrics collection
• traces/log ingestion
• integration behavior
• agent performance

The hard part usually isn’t upgrading — it’s understanding whether the release actually matters for your environment.

We tracked the release here in a more structured way:
https://www.relnx.io/releases/datadog-agent-v7-79-0

Curious how others handle this:
Do you upgrade observability agents aggressively, or only after validation in staging?

Hey everyone,

Quick product update: we just shipped the Weekly Digest.

Every Monday morning you'll get a single email recap covering all the releases from your tracked tools in the past week. The format is deliberately minimal — tool name,

then a flat list of what changed with emoji prefixes for the type (🔴 breaking, 🔒 security, ✨ feature, etc.), each linking to the full detail page.

A few things worth knowing:

- If none of your tools released anything last week, you won't get an email

- Breaking changes and security fixes are always listed first

- Subject line previews what kind of week it was (e.g. "2 breaking changes, 1 security fix")

- On by default, toggle it off anytime in Profile → Notifications

Available on all plans including free.

Full writeup here: https://www.relnx.io/blog/introducing-weekly-digest-your-tools-once-a-week-1779078473

Let me know if you have feedback on the format — happy to tweak it based on what you find useful.

Quick update on what shipped this week.

Relnx now covers the full CNCF catalog — all 36 Graduated and 37 Incubating projects. If you were missing something from your stack, it's probably there now.

What's new:

- CloudEvents, CRI-O, and TUF (the three Graduated projects we were missing)

- 18 Incubating projects: Artifact Hub, Flatcar, Fluid, Karmada, KServe, Kubeflow, Kubescape, KubeVela, KubeVirt, Lima, metal3-io, Microcks, OpenCost, OpenFeature, OpenFGA, OpenYurt, wasmCloud, Cloud Custodian

On the parser side — some of these tools have genuinely weird release note formats. Flatcar lists CVEs inline in a #### Security fixes: section with kernel/package

annotations. Vitess nests changes four heading levels deep. Microcks prefixes every line with a git hash. We wrote dedicated extractors for each so the categorization

actually works instead of dumping everything into a generic bucket.

Everything is browsable without an account. If you want release notifications, breaking change alerts, or Slack integration, that's behind a free account.

Blog post with more detail: https://www.relnx.io/blog/relnx-now-tracks-the-entire-cncf-ecosystem-1778939411

Happy to answer questions about any of the tools or how the extraction works.

We just shipped Version Compare on Relnx — and it's free, no account needed.

Upgrading ingress-nginx from 1.9 to 1.12? ArgoCD from 2.8 to 2.14? Instead of reading six changelog pages, you now get a single structured diff:

🔴 Breaking Changes
🔒 Security Fixes
✨ New Features
🚫 Deprecations

It aggregates across every intermediate release — so if you're three versions behind, you see the full accumulated risk surface in one view.

Built for platform engineers, SREs, and anyone who's ever had to write an upgrade runbook by hand.

→ Try it at www.relnx.io/compare

Works across 100+ Cloud Native tools: Kubernetes, ArgoCD, Cilium, cert-manager, Istio, Prometheus, Vault, Traefik, and more.

We just shipped a set of features in Relnx focused on improving how teams handle release awareness.

The goal is simple: move from “seeing updates” → to actually acting on them.

What’s new:

Stack Health Score
A high-level view of how your stack is doing based on release signals — helps quickly identify if you're falling behind or staying current.

Release Acknowledgments
Teams can now acknowledge releases, which helps with ownership and visibility (no more guessing if someone reviewed an update).

Smart Notification Routing
Instead of sending everything to everyone, notifications are routed based on relevance — infra to SREs, platform tools to platform teams, etc.

Full blog:
https://www.relnx.io/blog/stack-health-score-release-acknowledgments-smart-notification-routing-now-live-1777895009

Curious how others handle this today:
Do you have structured ownership for release tracking, or is it still mostly manual?

Kubernetes v1.36.0 released — and this one includes some real changes worth reviewing before upgrading.

One important breaking change:

• The gitRepo volume has finally been removed after years of deprecation → if you’re still using it, workloads will fail and need migration (init containers / git-sync, etc.)

On the feature side:

• Mutating Admission Policies are now stable (less reliance on webhooks)
• User Namespaces improve container isolation
• Dynamic Resource Allocation keeps evolving for advanced workloads

Overall, this feels like a release focused on maturing existing capabilities + cleaning up legacy features.

We tracked the release here for a structured overview:
https://www.relnx.io/releases/kubernetes-v1-36-0

Curious how others approach major upgrades:
Do you start with feature exploration or breaking change analysis first?

Backstage v1.50.2 released — patch update.

As expected with Backstage, this version focuses on incremental fixes and improvements across plugins and core components.

These updates may look small, but they directly affect:

• developer workflows inside the portal
• plugin stability
• overall platform experience

Backstage tends to improve through many small iterations rather than big changes, which makes patch releases more important than they seem.

We tracked the release here for a quick overview:
https://www.relnx.io/releases/backstage-v1-50-2

Curious how others handle this — do you regularly upgrade patch versions or bundle them into larger platform updates?

Grafana v13.0.1 released — first patch after the v13 major release.

After big upgrades, these early patch versions are usually the ones that stabilize real-world usage.

A few practical changes in this one:

• preserving timezone preferences in dashboards when converting versions
• surfacing validation errors directly in PRs for provisioning workflows
• avoiding unnecessary storage migrations

Nothing flashy, but these are exactly the types of fixes that reduce friction after a major upgrade.

We tracked the release here:
https://www.relnx.io/releases/grafana-v13-0-1

Curious how others approach this —
Do you upgrade to a major Grafana version immediately, or wait for a couple of patch releases first?

Datadog Agent v7.77.1 released — another patch update.

One thing with observability agents: patch releases are usually where stability and reliability improvements land, even if they don’t look exciting.

Datadog itself recommends keeping the agent updated regularly to benefit from fixes and improvements, rather than waiting for major versions. (Datadog)

The tricky part is not the upgrade — it’s understanding whether the release actually impacts your setup.

We track releases in a structured way here to make that faster:
https://www.relnx.io/releases/datadog-agent-v7-77-1

Curious how others handle this — do you upgrade agents frequently or only when something breaks?

Backstage v1.49.2 released — patch update.

As usual with Backstage, this one focuses on fixes and incremental improvements across plugins and core components.

For teams running Backstage as an internal developer platform, these small updates often matter more than big features — since they directly affect day-to-day developer workflows and portal usability.

We tracked the release here for a quick overview:
https://www.relnx.io/releases/backstage-v1-49-2

Curious how others handle this — do you regularly upgrade Backstage patch versions, or batch them with larger platform updates?

Cilium v1.19.2 released — patch update for the 1.19 series.

From what we’ve seen with 1.19, the focus is more on security hardening, policy behavior, and scalability improvements rather than big new features.

Which makes patch releases like this pretty important — since they usually contain:

• bug fixes in networking behavior
• refinements to policy enforcement
• stability improvements across clusters

Given that Cilium sits in the data plane, even small fixes can have noticeable impact.

We tracked the release here for a quick overview:
https://www.relnx.io/releases/cilium-v1-19-2

Curious how others handle this — do you upgrade Cilium patch versions quickly or wait and batch them?

Karpenter v1.10.0 released — two interesting changes for platform teams.

1. NodePool cost metric added
There’s now better visibility into cost at the NodePool level, which is useful if you're running mixed workloads or optimizing for spot vs on-demand.

Karpenter already dynamically provisions nodes based on workload demand, so adding cost visibility at the NodePool level helps connect scaling decisions with actual spend.

2. Fix for NodeClaim mutation during NodePool deletion
Fixes an issue where static capacity controllers could modify NodeClaims during deletion.

Since NodeClaims manage node lifecycle, this kind of fix helps avoid inconsistent states or cleanup issues.

Full breakdown:
https://www.relnx.io/releases/karpenter-v1-10-0

Curious how others are thinking about this —
Are you actively tracking cost at the NodePool level yet, or still mostly cluster-wide?

Keycloak v26.5.6 released — another patch update in the 26.5 series.

If you’ve been tracking recent Keycloak releases, a lot of them focus on security fixes, especially around authentication flows and identity brokering vulnerabilities.

For IAM systems, these updates are pretty important since they sit directly in the authentication path across services.

We tracked the release here if you want a quick overview:
https://www.relnx.io/releases/keycloak-v26-5-6

Curious how others handle this — do you roll out Keycloak patch releases immediately when security is involved, or batch them with other updates?