a structural diff that understands syntax

This case study explains how JVM tuning, a smaller Hikari pool, and faster HPA scale-up doubled traffic capacity while reducing baseline pods.

This article distills incident-driven lessons on troubleshooting, configuration mistakes, and operational habits that make Kubernetes outages worse.

This article covers rebuilding a Kubernetes platform for GPU workloads to reach 99.9% uptime after operational instability.

At VictoriaMetrics, we built vlagent as a high-performance log collector for VictoriaLogs. To validate its performance and correctness under a real production-like load, we developed a benchmark suite and ran it against 8 popular log collectors. This post covers the methodology, throughput results, resource usage, and delivery correctness.

This tutorial walks through building a Go game server with Agones, matchmaking, Fleet allocation, and autoscaling on Kubernetes.

This tutorial shows how to migrate PostgreSQL to CloudNativePG on Kubernetes with logical replication and no downtime.

This tutorial shows how to deploy NGINX Gateway Fabric on GKE with Terraform, split traffic paths, and automate TLS certificates.

This interview compares the cost and operational tradeoffs of moving a Kubernetes workload from GKE Autopilot to Hetzner with Edka.

A horizontal autoscaler for Kubernetes workloads, saving cloud costs by scaling workloads down after hours. This is a golang port and successor of the popular (py-)kube-downscaler with improvements and quality of life changes.

This tool analyzes Karpenter NodePool usage and offers AI-powered recommendations to reduce AWS EC2 costs while maintaining performance.

Explore OCI container images without running them.

eBPF-powered Linux observability with AI incident detection.

Visualize your cluster topology, browse resources, stream logs, exec into pods, inspect container image filesystems, manage Helm releases, monitor GitOps workflows (FluxCD & ArgoCD), and forward ports — all from a single binary with zero cluster-side installation.

OneCLI is an open-source gateway that sits between your AI agents and the services they call. Instead of baking API keys into every agent, you store credentials once in OneCLI and the gateway injects them transparently. Agents never see the secrets.

Why we built it: AI agents need to call dozens of APIs, but giving each agent raw credentials is a security risk. OneCLI solves this with a single gateway that handles auth, so you get one place to manage access, rotate keys, and see what every agent is doing.

How it works: You store your real API credentials in OneCLI and give your agents placeholder keys (e.g. FAKE_KEY). When an agent makes an HTTP call through the gateway, the OneCLI gateway matches the request to the right credentials, swaps the FAKE_KEY for the REAL_KEY, decrypts them, and injects them into the outbound request. The agent never touches the real secrets. It just makes normal HTTP calls and the gateway handles the swap.

I’ve been staring at a Terraform module for the last ten minutes, and I can’t stop thinking about a question that would have been absurd two years ago: why am I writing this?

Not “why am I provisioning this infrastructure.” That part makes sense. But why am I writing HCL, a domain-specific language that exists to describe infrastructure in a way that humans can read, when I have an AI agent sitting in my terminal that can call the AWS API directly?

It’s the kind of question that sounds naive until you realise the same logic is playing out across every layer of the stack. And the more I look at it, the more I think we’re watching the early stages of a fundamental shift in how we interact with machines.