We are happy to announce the latest release of NXLog Platform, version 1.12. This release introduces full version history for agent configurations, giving you a clear audit trail and the ability to instantly restore any previous version. It also brings a redesigned Customer Portal with a streamlined onboarding experience and improved navigation. Want a quick overview? Watch a short demo showcasing configuration version history, one of the key new features in this release:

Compliance frameworks don’t have a checkbox for "we know it’s a problem, but we can’t afford to fix it right now." Yet that’s the position thousands of organizations find themselves in — bound by regulation to meet security standards that their operating systems are physically incapable of supporting. If you run Windows XP, Server 2003, or any other unsupported OS in a regulated environment, the compliance obligation doesn’t go away just because the upgrade path is blocked.

NXLog Platform can now be installed using the official Helm chart, following the same Kubernetes deployment standard as any other enterprise Kubernetes application. Red Hat OpenShift is also fully supported using native OpenShift Routes. According to the CNCF 2025 Annual Cloud Native Survey, 82% of container users run Kubernetes in production, and 81% prefer Helm as their package manager of choice. Kubernetes adoption spans every major cloud provider and distribution, including GKE (32%), AKS (17%), OpenShift (13%), and Amazon EKS, and continues to grow as the default substrate for enterprise infrastructure.

Somewhere in a hospital basement, an MRI machine hums along on Windows XP. Down the road, a CNC controller on a factory floor runs Windows Server 2003. Across town, a municipal utility manages water treatment with software that hasn’t seen an update since the second Bush administration. These aren’t edge cases. They’re everywhere — and they represent one of the most underestimated risks in enterprise security today. Still here, still running It would be reasonable to assume that operating systems from the early 2000s have no place in a modern network.

Filebeat and Vector both move logs, but they solve different design problems. Filebeat is a shipper that fits neatly into Elastic-centric pipelines. Vector is a data pipeline runtime that can collect, reshape, split, and forward the same stream to several destinations before storage. The cost of choosing badly does not show up on day one. It shows up later as duplicate agents, extra relay tiers, backend-specific parsing rules, or migration work when a second destination appears.

As organizations collect more telemetry data, their pipelines grow in complexity and scale. Telemetry pipelines are dynamic, continually adjusted to improve data quality, reduce costs, and meet evolving observability requirements. At this scale, even small configuration changes can significantly affect how much data moves through your pipeline. Without clear visibility, you rely on assumptions. Did the new filtering rule actually reduce the amount of data you’re sending to the SIEM?