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.

This is the start/index post for a series of blog posts about the internals of Terraform. In this series, I will deep dive into different parts of Terraform and explain how they work under the hood.

The end-goal of this is to enable the reader to develop a deeper understanding of Terraform and how it works. After reading this, I would hope you are able to contribute to Terraform itself, add a new block to the language, or change existing behavior. I will not try to cover every single detail of Terraform, but I will try to cover the most important parts and give you a good overview of how different parts of Terraform work together.

My hope is that this series helps the reader to at least get a step closer to understanding the internals of Terraform. I won’t be covering anything related to language design and graph theory here; there are too many holes in my knowledge there as well. Maybe I’ll write something to that end in the future as well, probably not.

Open-source platform replacement for Terraform Enterprise.

In this article, I'll show how the Argo Workflows Executor Plugin lets you extend the Argo Workflows controller without maintaining your own fork—simply by implementing a small HTTP server in any language. As a bonus, this same mechanism reduces the number of extra pods in your DAGs and lightens the load on the Kubernetes scheduler. If you're new to Argo, I'll briefly cover the architecture and where plugins fit in. We'll finish with practical examples and key configuration details.

K8sQuest is a local, game-based Kubernetes training platform with an interactive GUI-like terminal interface. Each mission breaks something in Kubernetes. Your job is to fix it.