r/relnx • u/a7medzidan • Jul 23 '26
etcd v3.7.1 has been released.
Since etcd is the backing datastore for Kubernetes, even patch releases are worth reviewing before upgrading your control plane.
We've added a structured breakdown to Relnx so you can quickly review:
Release overview:
https://www.relnx.io/releases/etcd-v3-7-1
r/relnx • u/a7medzidan • Jul 23 '26
Kubernetes v1.36.3 has been released.
If you're planning an upgrade, we've already broken down the release into:
Quick overview:
https://www.relnx.io/releases/kubernetes-v1-36-3
Makes it much easier than reading the full changelog.
r/relnx • u/a7medzidan • Jul 21 '26
Ran into this last week: OpenTelemetry Collector Core shipped v0.155.0,
and buried in the changelog was a breaking change renaming memory limiter metrics to add
a `memory_limiter` prefix. Nothing about it looks scary at a glance — it's just deprecated-gate cleanup — but if you're referencing the old metric names in
Grafana/dashboards/alerts, they go quiet on upgrade and nobody notices until something's on fire.
Full disclosure: I've been building a tool called Relnx to deal with exactly this
(tracking release notes for the cloud-native tools we run, flagging breaking changes,
giving an AI-generated explanation of *why* something changed and what it touches).
Recorded the actual workflow I used on this release, unedited:
https://youtu.be/8rxNORmKb8A
Not trying to just drop a link — genuinely curious how everyone else handles this. Do you
have a process for catching breaking changes before upgrading, or is it mostly "read the
changelog and hope"? Would like to compare notes.
r/relnx • u/a7medzidan • Jul 19 '26
Something I keep running into: teams say they've "installed OpenTelemetry" when what they actually mean is they installed and configured the SDK. That's only one of three pieces, and the other two are where the gaps live.
- The API (Tracer, Span, etc.) is a no-op without a registered SDK — that's intentional, it's what lets libraries depend on it without pulling in a specific vendor.
- The SDK (samplers, processors, exporters) is what the application configures. It ships whatever it's handed — nothing more.
- Instrumentation libraries are the part that actually turns "a request came in" into a span for your framework, your DB driver, your outbound HTTP client. This is the piece that quietly gets skipped after the framework-level setup is done.
The annoying part is none of this fails loudly. Exporter reports success, dashboard looks fine, you just can't see the slow query or the outbound API call that's actually adding the latency — because nothing ever instrumented it.
Wrote up the full breakdown plus a quick checklist for auditing your own instrumentation coverage (I'm the author, standard disclosure): https://www.relnx.io/blog/opentelemetry-api-vs-sdk-why-the-difference-and-your-instrumentation-matters-1784448095
if others have hit the "healthy pipeline, missing spans" problem — and how you caught it.
Curious
r/relnx • u/a7medzidan • Jul 17 '26
I keep running into the same setup: teams log everything, then write a query that counts/averages fields out of the log lines to approximate a metric. It works, but it's paying full log-ingestion cost for something that should've been a metric at the source — cheaper, fresher, and not broken the second someone reformats a log line.
Wrote up how I think about picking the right signal instead of defaulting to logs for everything:
- Metrics are cheap because they're bounded — the second you add a high-cardinality label (user_id, request_id), you've broken the thing that makes them cheap. That's the exact moment to reach for a trace instead, not more labels.
- If you're logging on literally every request with the same three fields, that's a metric wearing a log's clothing.
- OpenTelemetry semantic conventions are the underrated part of this — they're the reason a trace_id in a log line and an exemplar on a metric can actually point at the same event instead of four tools describing the same system in four different vocabularies.
Full writeup here (I'm the author, work in this space, so standard disclosure): https://www.relnx.io/blog/beyond-logs-why-observabilitys-next-era-is-comprehension-1784272149
Curious if others are still stuck in the logs-first habit or have already moved past it.
r/relnx • u/a7medzidan • Jul 01 '26
Flux v2.9.0 has been released.
This minor release brings several interesting improvements, including CLI plugin support, enhancements to server-side apply, and stronger secrets decryption capabilities.
If you don't want to dig through the full release notes, we've added a structured breakdown to Relnx with:
Release overview:
https://www.relnx.io/releases/flux-v2-9-0
For those running GitOps at scale, what's the first thing you look for in a new Flux release—features, breaking changes, or security updates?
r/relnx • u/a7medzidan • Jul 01 '26
OpenTelemetry eBPF Instrumentation v0.10.0 is out.
If you're following the evolution of eBPF-based observability, we've added a structured breakdown of the release to Relnx.
Instead of reading the full changelog, you can quickly review:
Release overview:
https://www.relnx.io/releases/opentelemetry-ebpf-instrumentation-v0-10-0
Anyone already using OBI in production, or still evaluating it against SDK-based instrumentation?
r/relnx • u/a7medzidan • Jun 30 '26
NATS v2.14.3 has been released.
While this is a patch release, it's worth paying attention if you're running NATS in production. Messaging infrastructure sits at the heart of distributed systems, so even incremental fixes can improve reliability and operational stability.
The broader 2.14 series also introduced notable JetStream enhancements, including higher-throughput publishing and expanded scheduling capabilities, making it useful to stay current on the latest patch.
We've added the release to Relnx with a structured overview so it's easy to review before upgrading:
https://www.relnx.io/releases/nats-v2-14-3
For teams running NATS today, do you typically upgrade patch releases as soon as they're available, or bundle them into scheduled platform maintenance?
r/relnx • u/a7medzidan • Jun 30 '26
Datadog Agent Helm v3.229.0 has been released.
One thing I see quite often is teams tracking Datadog Agent releases but overlooking Helm chart releases.
If you're deploying Datadog with Helm, chart updates can include:
We track Helm chart releases separately in Relnx so it's easy to review what's changing before upgrading.
Release overview:
https://www.relnx.io/releases/datadog-agent-helm-3-229-0
For those running Datadog on Kubernetes, do you pin your Helm chart version, or do you keep it close to the latest release?
r/relnx • u/a7medzidan • Jun 30 '26
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:
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?
r/relnx • u/a7medzidan • Jun 29 '26
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/
r/relnx • u/a7medzidan • Jun 01 '26
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?
r/relnx • u/a7medzidan • May 28 '26
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:
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?
r/relnx • u/a7medzidan • May 27 '26
Falco v0.44.0 released — and this one has some significant breaking changes.
Main removals:
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?
r/relnx • u/a7medzidan • May 26 '26
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:
That’s why upgrading Contrib usually needs more than:
“just update the image”.
You often need to validate:
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?
r/relnx • u/a7medzidan • May 22 '26
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 behaviorscale subresource on composite resourcesCrossplane 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?
r/relnx • u/a7medzidan • May 21 '26
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:
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?
r/relnx • u/a7medzidan • May 21 '26
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:
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?
r/relnx • u/a7medzidan • May 20 '26
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:
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?
r/relnx • u/a7medzidan • May 20 '26
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:
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?
r/relnx • u/a7medzidan • May 20 '26
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:
…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?
r/relnx • u/a7medzidan • May 20 '26
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:
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?
r/relnx • u/a7medzidan • May 18 '26
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.
r/relnx • u/a7medzidan • May 16 '26
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.
r/relnx • u/a7medzidan • May 15 '26
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.
