DevOps&SRE Library

OpenRun is an Apache-2.0 licensed open source web app deployment platform for deploying internal tools. OpenRun makes it easy to declaratively deploy containerized web apps. OpenRun can deploy apps on a single-node or onto a Kubernetes cluster. OpenRun provides declarative GitOps based blue-green deployment, OAuth/OIDC/SAML access controls, TLS certs & secrets management. OpenRun is built for teams to easily deploy internal tools, with full RBAC support. OpenRun apps are deployed directly from the git repo, no build server required. OpenRun scales idles apps down to zero and supports atomic updates across multiple apps.

Chainloop is an open-source evidence store for your Software Supply Chain attestations, Software Bill of Materials (SBOMs), VEX, SARIF, QA reports, and more. With Chainloop, Security, Compliance, and Risk management teams can define security and compliance policies, what evidence and artifacts they want to receive, and where to store them. On the other hand, developers are shielded from all this complexity by being given simple instructions on what to provide when instrumenting their CI/CD pipelines.

This article walks through a production deployment that solves all of the above using llm-d for intelligent inference scheduling, Istio as a Gateway API provider with Inference Extension support, and LiteLLM as a unified API gateway.

Step-by-step guide to deploying a private Amazon EKS cluster with zero public API exposure, self-hosted OpenVPN access, kube-prometheus-stack monitoring, and Route 53 private DNS — all automated with Terraform.

Here we’ll walk through a small, concrete demo where a single hub control plane actively reconciles cert-manager.io/v1 Certificate resources across multiple downstream clusters, issues TLS Secrets, and does so safely from multiple controller replicas without relying on leader election.

In this post, we'll take a polyglot microservice app from local source code to a production Kubernetes cluster with TLS, Auth0 login, and Stripe webhooks — all working end-to-end. No cloud staging environment. No Docker Compose. No YAML by hand.

A practical guide to packaging kong custom plugins as Helm charts, deploying them as ConfigMaps, and automating releases with GitHub Actions

In this article we explain how we built a new observability platform over the span of approximately two years to address a variety of problems.

How we eliminated crash loops and hundreds of errors and why “high availability” was making everything worse.

A few years ago, Roland Huss and I wrote Kubernetes Patterns, a catalogue of repeatable solutions for building cloud-native applications on Kubernetes. The book covers patterns across six categories: foundational, behavioral, structural, configuration, security, and advanced, everything from health probes and init containers to controllers, operators, and elastic scaling. Recently, Roland and Daniele Zonca co-authored a new book, Generative AI on Kubernetes, which covers the operational side of running LLMs on Kubernetes. I was a reviewer on that book, and the more I read through it, the more I recognized patterns from our original work, just applied to a very different class of workload. Deployments, StatefulSets, Init Containers, DaemonSets. They were all there. Just with bigger numbers.

Here is a high-level summary of how Kubernetes patterns apply to LLM workloads, which Roland and I will cover in more detail in our upcoming KubeCon + CloudNativeCon Europe 2026 talk in Amsterdam.

Cluster API is a Kubernetes subproject focused on providing declarative APIs and tooling to simplify provisioning, upgrading, and operating multiple Kubernetes clusters.

Started by the Kubernetes Special Interest Group (SIG) Cluster Lifecycle, the Cluster API project uses Kubernetes-style APIs and patterns to automate cluster lifecycle management for platform operators. The supporting infrastructure, like virtual machines, networks, load balancers, and VPCs, as well as the Kubernetes cluster configuration are all defined in the same way that application developers operate deploying and managing their workloads. This enables consistent and repeatable cluster deployments across a wide variety of infrastructure environments.

eBPF egress firewall for Kubernetes

Docker-compatible container CLI built on Apple's Containerization framework. Same commands, same flags — mocker run, ps, stop, build, compose, stats — all working on macOS 26.

In this guide, I'll explain how to collect Prometheus metrics from an application running in a Kubernetes cluster and push the data to a Prometheus instance on a VM in a different geographic region using Prometheus's remote write endpoint.

Image Trust with Cosign and Kyverno

In this article we deploy ArgoCD in a bare-metal Kubernetes cluster built on Proxmox.

How treating Service Level Objectives as declarative infrastructure changed the way I think about reliability.

How we built an intelligent 'finally task' that turns 170,000 lines of logs into a 10-line diagnosis in under 30 seconds.

A practical guide to building the technical-financial baseline that tells you whether autoscaling will actually save money — and how much.

There’s a particular kind of infrastructure bug that’s deeply annoying to debug: the kind that only appears when your cluster is under load. Everything runs fine in steady state. Then you push a release, or traffic spikes and your autoscaler kicks in, and suddenly you’re chasing 502s that resolve on their own a few minutes later. Your first instinct is to blame the app. Then the deployment. Then the cluster. Then yourself.

We hit exactly this pattern at Simon AI. The culprit turned out to be something fundamental about how nginx handles DNS — and fixing it properly required waiting for a feature that was finally open-sourced at the end of 2024.

Here’s what we found, what we tried, and how we solved it.