标签：#devops

Let's be honest, deploying AI models can feel like navigating a minefield. You've trained the perfect model, but getting it reliably into production, ensuring it performs, and iterating quickly? That's where things often fall apart. For years, I've seen teams struggle with manual handoffs, inconsistent environments, and the sheer velocity of changes. This is why automation in MLOps isn't just a nice-to-have; it's the non-negotiable bedrock for any serious AI initiative. From my experience building and scaling AI systems—principles you'll find explored at https://www.raviroy.in—a well-architected automated MLOps pipeline is the game-changer for moving from experimental AI to production-grade assets. What is an Automated MLOps Pipeline? MLOps, or Machine Learning Operations, is where ML, DevOps, and data engineering meet. Its purpose? To streamline the entire ML lifecycle—from experimentation and training to deployment, monitoring, and continuous improvement. Automation is the engine that makes this repeatable, efficient, and scalable. An automated MLOps pipeline acts as the backbone, orchestrating every stage of the model's journey. It ensures that trained models, along with their dependencies and configuration, can be packaged, tested, deployed, and monitored in production environments with minimal human intervention. While traditional software development benefits from Continuous Integration/Continuous Deployment (CI/CD) pipelines, MLOps automation extends these principles to account for the unique challenges of machine learning. Unlike software, ML models introduce variables like data drift (changes in input data distribution), concept drift (changes in the relationship between input and output variables), and the critical need for comprehensive model versioning (tracking not just code, but also data, features, and model artifacts). The benefits of fully embracing automation in MLOps are transformative: Speed: Accelerate the time-to-market for new models and updat

Introduction As part of learning and preparing for a migration from Azure DevOps pipelines to GitHub Actions , I decided to build a small practice project before working with a real application. Project repository: github url The goal for this exercise was straightforward: Build a Go application, create a GitHub Actions pipeline, authenticate securely to Azure, build a Docker image, and push it to Azure Container Registry (ACR). For this exercise, I deliberately stopped at ACR . Kubernetes and AKS deployment will come later. What I wanted to achieve The goal was to build a workflow that could: Run when a Pull Request is created Build and test the Go application Build a Docker image Authenticate to Azure without using a client secret Push the image to Azure Container Registry The final flow looks like this: Pull Request ↓ GitHub Actions ↓ Go Build & Test ↓ Docker Build ↓ GitHub OIDC ↓ Microsoft Entra ID ↓ Azure Container Registry ↓ Docker Image 1. The Practice Project I used a small Go REST API project for the exercise. The application itself wasn't the main focus. I mainly needed a working application that could: Build successfully with Go Run inside Docker Expose an HTTP endpoint I verified the application locally with: go run . Then tested its health endpoint: curl http://localhost:10000/health-check which returned: { "healthy" : true } I also built the Docker image locally: docker build -t go-rest-api:1.0 . and verified that the container worked: docker run --rm -p 10000:10000 go-rest-api:1.0 At this point, I knew the application and Dockerfile were working. 2. Creating the GitHub Actions Pipeline I created the workflow file: .github/workflows/ci-cd.yml The initial pipeline was intentionally simple. name : Go CI/CD on : pull_request : jobs : build : runs-on : ubuntu-latest steps : - name : Checkout code uses : actions/checkout@v4 - name : Set up Go uses : actions/setup-go@v5 with : go-version : ' 1.27' - name : Download dependencies run : go mod download - name :

A developer deployed a customer-support agent that got stuck in a retry loop with a CRM tool. No hard circuit breaker. It spent six hours overnight repeating the same broken call while he slept, and he woke up to roughly a $4,200 OpenAI bill for doing nothing useful. That's the failure mode. Not a dramatic hack — a boring loop with no external stop. Roughly 95% of enterprise generative-AI pilots in 2025 delivered no measurable return, and almost none of those were model failures. Teams optimized the brain and skipped the nervous system. A read-only chatbot is a wiki with better search. A deployed agent does things — writes to a database, calls an API, refunds a customer. That shift from reading to doing is where pilots die. The useful mental model: treat the LLM as a fallible kernel, not a magic box. You don't trust a kernel blindly. You wrap it in checks, limits, and a way to roll back. Agents break three assumptions your ops playbook depends on Non-determinism. The same input can produce different actions on different days. An agent succeeds Monday and fails on the identical request Tuesday. Call it ghost debugging — the bug won't sit still long enough to catch. Design for a 3% to 15% tool-call failure rate as a normal state, not an exception. Cost grows with loop length, not request count. This is the mechanism most guides skip. The agent loops: think, call a tool, read the result, think again. Frameworks append every step and every tool error to the running history, then resend the whole cumulative log on the next call. Token use grows quadratically. A 20-step loop is not twice a 10-step loop — each step re-pays for everything before it. Related trap: past roughly the 40% context-fill mark, answers get worse. Load the window with tool definitions and raw JSON and you're doing your real work in the dumb zone. Every tool you connect widens the blast radius. Which brings us to the controls. Four controls the agent cannot touch Wire these before you touch agent logi

After a decade in insurance operations, I decided to make my pivot into cloud engineering official by doing the Cloud Resume Challenge ! I wanted to build it according to real-world best practices, so in addition to the steps the challenge provides, I incorporated a private S3 bucket secured with CloudFront Origin Access Control, a dedicated least-privilege IAM user scoped to only the permissions my CI/CD pipeline needed, and mocked unit tests with moto so nothing touches real AWS resources during testing. The site is live at derekjackson.click . It's a static resume served over HTTPS through CloudFront , backed by a Lambda -powered visitor counter, fully codified in Terraform , and deployed automatically via GitHub Actions . Here's how I built it and, more importantly, everything that went wrong along the way. The Architecture Frontend: S3 stores the static site, fully private with Block Public Access on. CloudFront sits in front of S3, using Origin Access Control (OAC) so CloudFront can read the private bucket. AWS Certificate Manager issues the HTTPS certificate (requested in us-east-1 , a hard CloudFront requirement regardless of where the rest of the infrastructure is deployed.) Route 53 hosts the domain and holds the alias record pointing it at CloudFront. Backend: DynamoDB has a single item, on-demand table holds the visitor count. Lambda (Python) atomically increments that count on every request, avoiding race conditions from concurrent visitors. API Gateway (HTTP API) exposes the Lambda over a public GET /visitor-count endpoint the frontend calls when the page is loaded. Operations: Code is written, stored and edited locally. 2. pytest and moto test the Lambda function against a fully mocked DynamoDB before anything touches AWS. 3.After successful testing, git push commits the code to main initiating the pipeline. 4. GitHub Actions deploys frontend changes to S3 and backend changes to Lambda on every push to main . 5. Terraform codifies and imports all 13 l

Your Budget Alert Won't Save You: Building a Real Cloud Spend Circuit Breaker You set up budget alerts. You get the email. You nod wisely. And then... you keep spending. The money is already gone by the time the alert arrives. Budget alerts are reactive by design. They tell you after the fact. A circuit breaker is different — it proactively interrupts the flow before spend spirals out of control. In this article, I'll show you how to build a real cloud spend circuit breaker using AWS Budgets + CloudWatch + SNS + Lambda, with Terraform, that can actually stop or throttle spend in near-real-time. Why Budget Alerts Fail Problem Why It Matters 8-hour metric granularity AWS Billing metrics are sampled every 8 hours. An alert at 100% threshold means the bill already exceeded your limit. Forecasted spend is optimistic Cost Explorer forecasts use historical averages and don't account for bursty, unpredictable workloads. Email delays Budget notifications arrive via SNS email subscription, which can take minutes to hours to be confirmed and delivered. No enforcement mechanism An alert is just a notification. There's no built-in way to stop spend at the infrastructure level. Threshold blindness Setting a single 100% threshold means you only learn you've overspent, with no warning lane. The Circuit Breaker Architecture The solution combines three AWS services into a closed-loop system: AWS Budgets — Tracks actual and forecasted spend, fires alerts at configurable thresholds CloudWatch Alarms — Monitors the budget state and triggers Lambda execution Lambda + SNS — Executes remediation actions and notifies stakeholders The Key Differentiator: Forecasted + Actual Dual Thresholds Most people set one alert at 100%. That's too late. Instead, use three thresholds: Threshold Type Purpose 80% ACTUAL Warning: "Hey, you're at 80% of budget. Keep an eye on it." 100% ACTUAL Danger: "You've hit your monthly limit. Time to review." 110% FORECASTED Proactive: "Forecast predicts you'll exceed b

Original Article published on ZeroLabs . Designing Production-Grade OpenClaw Skills: Schemas, Tool Calling, and Dynamic Dispatch Key Takeaway: A deep engineering walkthrough on creating modular, reusable skills for OpenClaw agents with strict JSON schemas, fallback execution paths, and error telemetry. Structured verification, strict boundaries, and deterministic tooling prevent production failure. Implemented directly across the ZeroLabs and OpenClaw platform architecture. Image credit: labs.zeroshot.studio Why this matters: Engineering reliable systems requires moving past unstructured prompts into hardened execution contracts. Contents What is an OpenClaw skill? How do you structure the SKILL.md specification? How do you implement reliable Python tool scripts? What is dynamic dispatch and context management? FAQ What is an OpenClaw skill? In OpenClaw, a skill is a self-contained directory containing instructions, configuration schemas, and executable scripts. Instead of writing monolithic prompts that describe every possible task, skills allow agents to discover, load, and execute specialized capabilities on demand. flowchart TD A[User Request] --> B[OpenClaw Router Agent] B -->|Matches Capability| C[Load skill: domain-seo-audit] C --> D[Read SKILL.md Frontmatter & Rules] D --> E[Execute Scoped Python Script / Tool] E --> F[Return Formatted Output to Context] How do you structure the SKILL.md specification? Every skill must reside in its own subdirectory under skills/<skill-name>/ with a root SKILL.md file: --- name : domain-seo-audit description : " Scans a target URL for Core Web Vitals, OpenGraph tags, and indexability issues." version : 1.0.0 parameters : type : object properties : url : type : string format : uri description : " The full target URL to audit (including https://)." check_mobile : type : boolean default : true description : " Whether to emulate mobile viewport checks." required : - url --- # Domain SEO Audit Skill ## Overview Use this skill whe

Original Article published on ZeroLabs . Taming Vibe-Coded Technical Debt: Automated Test Harnesses for AI-Generated Repos Key Takeaway: A pragmatic strategy for refactoring AI-generated codebases, eliminating dead boilerplate, and establishing regression test harnesses before shipping to production. Structured verification, strict boundaries, and deterministic tooling prevent production failure. Implemented directly across the ZeroLabs and OpenClaw platform architecture. Image credit: labs.zeroshot.studio Why this matters: Engineering reliable systems requires moving past unstructured prompts into hardened execution contracts. Contents What causes vibe-coded technical debt? How do you build a safety test harness? What is the 4-step refactoring loop for AI code? How do you clean dead dependencies and boilerplate? FAQ What causes vibe-coded technical debt? AI coding models are optimized to satisfy the user's immediate prompt. When asked to add a feature, models often take the path of least resistance: Copy-Pasting Logic : Duplicating utility functions across multiple files rather than importing shared modules. Swallowing Errors : Wrapping fragile database or network calls in broad try/except: pass blocks. Dependency Sprawl : Installing heavy npm packages or Python libraries for trivial single-line operations. flowchart TD A[Vibe Coded Prototype] --> B[Generate Smoke & Contract Tests] B --> C[Run Static Analysis & Linters] C --> D[Identify Duplication & Dead Imports] D --> E[Scoped AI Refactor on Single Module] E --> F[Run Test Suite] F -->|Pass| G[Commit Refactor] F -->|Fail| E How do you build a safety test harness? Before asking an AI agent to clean up or refactor an existing repository, you must write automated smoke tests that verify critical user journeys. If you don't have tests, ask the agent to write tests before modifying any implementation code: # tests/test_smoke_endpoints.py import pytest import httpx BASE_URL = ' http://localhost:3000 ' def test_homepage

Original Article published on ZeroLabs . Context Engineering with Claude Code: The Spec-First Pipeline for Production Codebases Key Takeaway: How to structure markdown specification files, linting contracts, and context boundaries to eliminate hallucinated refactors when coding with Claude Code and modern CLI agents. Structured verification, strict boundaries, and deterministic tooling prevent production failure. Implemented directly across the ZeroLabs and OpenClaw platform architecture. Image credit: labs.zeroshot.studio Why this matters: Engineering reliable systems requires moving past unstructured prompts into hardened execution contracts. Contents What is the problem with unstructured conversational prompting? How does the Spec-First Pipeline work? What belongs in a production feature spec? How do you enforce automated verification loops? FAQ What is the problem with unstructured conversational prompting? When developers ask CLI coding agents to 'Fix the user profile page' or 'Refactor our database queries' , the model must guess which files to edit, what interfaces to preserve, and how to verify correctness. This ambiguity leads to three common failure modes: Collateral Damage : The agent modifies unrelated utility functions, introducing silent regressions across the codebase. Context Saturation : The agent reads dozens of unnecessary files, exhausting its context window and forgetting the primary objective. Premature Completion : The agent claims a task is complete without running linters, compilers, or test suites. flowchart TD A[Feature Request / Bug] --> B[Draft SPEC.md in Repo] B --> C[Review Interface & Target Files] C --> D[Feed Spec to Claude Code / CLI Agent] D --> E[Agent Edits Code in Target Files] E --> F[Run Deterministic Test Suite] F -->|Tests Fail| E F -->|Tests Pass| G[Commit & Open PR] How does the Spec-First Pipeline work? The Spec-First Pipeline replaces open-ended chatting with a deterministic three-stage workflow: Stage Artifact Action O

HashiCorp has released Packer v1.16.0, adding native support for generating, signing, and verifying SLSA provenance attestations for every image the tool builds. The release provides teams with a secure, tamper-proof record of how a machine image was made. It does this without needing extra supply-chain tools. By Claudio Masolo

Introduction ingress-nginx was retired in March 2026. There are no more releases and no more security patches. It routes traffic into roughly half of all Kubernetes clusters, which makes this a problem for a lot of teams. Installing a retired project is still completely silent. I tried it last week and got no warning at any step. Most migration guides treat this as an annotation mapping exercise. But the real problem is not the annotations. It is everything that keeps working afterwards while quietly doing the wrong thing. The environment Everything below was tested on a single-node cluster: Ubuntu 26.04 LTS (kernel 7.0.0-31) k3s v1.36.4+k3s1 Helm v3.21.4 HAProxy 3.2.9 (host, LTS branch) ingress-nginx chart 4.15.1 / app 1.15.1 (retired March 2026) HAProxy Kubernetes Ingress Controller (HAProxy 3.2.23) Traffic path: Cloudflare (proxied) → HAProxy on the host → ingress controller → pod. This is the chain I run in production, so it is the one I tested. Many teams run something close to this, with a CDN in front and a proxy on the host. Step 1: Installing a retired project produces no warning bash helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx helm repo update helm install ingress-nginx ingress-nginx/ingress-nginx \ --namespace ingress-nginx --create-namespace \ --set controller.service.type=NodePort \ --set controller.service.nodePorts.http=30080 \ --set controller.service.nodePorts.https=30443 NAME: ingress-nginx STATUS: deployed REVISION: 1 The chart repository still answers, the install succeeds, and no step mentions that the project is over. Automation makes this worse: a pipeline that installs this chart keeps working, and nobody reads the output anyway. Step 2: Three layers, three wrong IPs The test application is traefik/whoami , which prints the IP it sees and every header it receives. Request from an external machine, through Cloudflare: RemoteAddr: 10.42.0.6:36848 Cf-Connecting-Ip: 203.0.113.5 X-Forwarded-For: 10.42.0.1 X-Real-Ip: 10.4

Introduction Repository migrations are often perceived as straightforward infrastructure activities. In reality, developers frequently face a more complicated challenge: "What happens to the work that is already in progress?" I recently faced a situation where an ongoing feature was being developed in a repository originally hosted in one Git platform while the organization migrated to another platform. The challenge was not simply moving code. The challenge was safely migrating active work without: Losing commits Pushing to deprecated branches Creating merge conflicts Breaking the development workflow Introducing confusion among team members This article summarizes the lessons learned and the approach that ensured a smooth transition. The Situation The development team received guidance similar to: Stop pushing to branches originally created in the old repository platform. Create new branches in the new platform. Verify branch history before using migrated branches. Use new authentication credentials for the new platform. At first glance the instructions seemed simple. However, there was already: Ongoing feature development Local commits Existing branch history Local test configurations New authentication requirements The biggest question became: "How can existing work be moved safely without starting over?" Step 1: Verify the Current State Before making any migration-related changes, it is important to understand exactly where the work exists. A few simple checks help answer: Which branch am I on? Are there uncommitted files? Have commits already been created? Which remote repository am I connected to? Understanding the current state prevents accidental mistakes later. One of the most valuable lessons was: Never assume your local branch matches the remote branch. Verify first. Act second. Step 2: Separate Real Changes from Local Testing In most projects there are usually two types of modifications: Functional Changes Actual feature development or defect fixes inte

Ninety-eight percent of the production container images I audit in financial services contain at least one critical vulnerability, and nearly half of those vulnerabilities have a fix available that the engineering team simply hasn't bothered to apply. It matters because when you’re pulling down a python:3.11-buster image, you aren't just getting an interpreter. You’re getting a Debian distribution, a shell, a package manager, and enough attack surface to keep a red team busy for a month. In a regulated environment, that’s not just tech debt; that’s a liability that will get you a stern email from compliance during your next SOC2 audit. Why I chose this topic: I spent three weeks last quarter cleaning up a Log4j-style mess that only existed because a legacy data job was pulling a bloated, unpatched base image. I’m writing this because I’m tired of seeing production clusters running bloated images that act as a buffet for bad actors. You’re currently facing a binary choice: continue to ship heavy, "convenient" images that make debugging easy but security impossible, or embrace the friction of minimal, hardened artifacts that keep you out of the headlines. The contenders Most data engineers in my circles land on one of three paths when containerizing their PySpark or Pandas workloads. First, there’s the "Standard Distro" approach. This is FROM python:3.11-slim or FROM ubuntu:22.04 . It’s familiar, it has apt , and you can pip install anything without breaking a sweat. Second, we have the "Distroless" camp. This is Google’s gcr.io/distroless/python3 . It contains absolutely nothing but your app and its runtime dependencies. No shell, no package manager, no local tools. Third, there is the "Alpine/Musl" route. This is FROM python:3.11-alpine . It’s tiny, but it swaps the standard glibc for musl, which is a recipe for disaster if your data science libraries rely on C-extensions. Photo by CHUTTERSNAP on Unsplash The hidden cost of "easy" images If you’re using python:3.11-

⚡ TL;DR Four things about controller mechanics are widely half-understood: what Reconcile receives, where its work comes from, what a periodic resync is, and what a predicate turns off. I built an operator, broke it five ways, and measured each mechanism directly. The reconcile function runs in 2.71ms mean, 77/77 under 25ms , a short resync period costs zero additional API requests , and GenerationChangedPredicate cut steady-state reconciles by 48.5% without touching live repair at all. That last combination is the one that matters at scale. Repo, raw data, and harness: kirPoNik/k8s-drift-operator . 🧩 The four barriers Everyone who runs Kubernetes knows the platform repairs itself. Delete a pod, it comes back. Scale a Deployment by accident, something puts it back. Almost nobody who relies on that property can say how it works, and the gaps are specific and consequential. I keep meeting the same four: People think a controller is told what changed. It is not, and the reason it is not is the single most important design decision in Kubernetes. People think a controller polls the API server. It does not, and knowing what it does instead tells you where your API load actually comes from. People think a resync is a re-check against the cluster. It is not, which is why a short resync period is nearly free — and why the number that is expensive sits somewhere else entirely. People treat a predicate as a pure optimisation. It is a filter with a silent cost, and the cost is not the one the documentation warns you about first. So I built the smallest system that has the self-healing property, broke it on purpose ten times per failure mode, and instrumented each of those four mechanisms until I could state what it does rather than what it is said to do. What I built. One CRD called Echo , holding an image, a replica count, and a greeting. A controller keeps three child objects in sync with it — a Deployment, a Service, and a ConfigMap holding the greeting — with owner referen

I was testing out CH-Ops - an admin GUI for self-hosted ClickHouse - on a simple setup: 1 shard, 2 replicas. Stumbled onto the replication queue almost by accident. Here's what I did: I stopped one of the nodes (let's call it Node B), then inserted some data through the other one (Node A). Just wanted to see what would happen. Then, while Node B was still down, I checked it in CH-Ops. It had stuff sitting in its replication queue. My first assumption was: okay, this must be showing what's left to replicate across the cluster - the total pending replication work. So I switched over and checked Node A, the one that was actually up and had just received the insert. Its queue was empty. That didn't match what I expected at all. If the queue was a cluster-wide "here's what still needs to replicate" view, Node A should've shown something too - it was the one that had the fresh data now waiting to reach Node B. Instead it was Node B, the down one, sitting there with pending tasks. That mismatch is what sent me digging. Turns out the queue isn't cluster-wide at all - it's specific to each ClickHouse instance. Once I brought Node B back up, its queue drained in seconds and the data showed up. That whole experiment is basically the entire post in miniature. Here's the mental model I ended up with. A Queue Belongs to a Replica, Not to the Table This is the first thing to get straight. With a ReplicatedMergeTree table, you can have multiple replicas holding copies of the same data. It's tempting to think of replication as one shared pipe between them. It isn't. Each replica keeps its own local replication queue . So if you see: Replica 1 → queue_size = 0 Replica 2 → queue_size = 25 that doesn't mean 25 operations are waiting somewhere in the middle for both replicas to pick up. It means Replica 2, specifically, has 25 tasks it hasn't finished yet. Once that clicked for me, the rest of the system made a lot more sense. So Where Do These Tasks Come From? Replication in ClickHouse

Every guide I write ends in the same handful of questions. How much hardware do I actually need? What happens when one box dies? Are my backups real or just a feeling? A guide can walk you through a setup, but it can't do arithmetic about your lab — so I built eleven small tools that can, at peira.dev/tools . They're free, none ask who you are, and seven of the eleven keep working once the page has loaded — network unplugged, laptop in a cupboard, whatever. They share one lab profile This is the part that makes them a set rather than eleven unrelated pages. Describe your lab once — tick your services in the sizing calculator, press Save to profile — and the others pick it up. The failure simulator opens with your nodes already modelled; the backup planner knows what data you have; the power-loss playbook knows what's plugged in. Lab doc hands the whole thing back as a Markdown file. Nothing about that profile leaves your browser. No account, no sync, no server that could leak it — which is also why it doesn't follow you between devices. The Markdown export is how you carry it elsewhere. Plan the build Sizing calculator — asks what you want to run and recommends nodes, RAM, and storage. It cares most about RAM, because that's the constraint that actually bites; vCPUs overcommit happily, memory doesn't. Tick "survive one node failure" and it insists on three nodes (a two-node cluster loses quorum the moment one dies). Node failure simulator — kill a node and see which workloads fit on the survivors. It places the critical ones first and names the stranded ones. 3-2-1 backup planner — three copies, two devices, one offsite (the rule CISA recommends ). It's blunt: a snapshot on the same disk as the original is versioning, not a backup. Fix what's broken The overlay network diagnostic is a decision tree born from a miserable afternoon: a container couldn't reach a machine across a Tailscale subnet router, and three layers had to be right — the route in the guest, the ACL

Tuning guides talk about throughput. Nobody pages you about throughput. They page you about symptoms, and the useful skill is mapping a symptom back to a cause before you spend money on hardware. Three failure modes account for most of what I find on inherited servers. Each has a distinct signature. The 502 nobody can reproduce Server has 8GB. PHP-FPM is set to 100 workers. Each worker uses 60MB under load. That's 6GB of PHP, plus MariaDB, plus Nginx, plus the OS. Under normal traffic you never approach 100 workers, so it looks fine for months. Then a marketing email goes out, concurrency spikes, and the kernel runs out of memory. The OOM killer picks a process and terminates it, usually the biggest one, which is a PHP-FPM worker holding an in-flight request. User gets a 502. The application log has nothing, because the process died before it could write anything. Nginx logs recv() failed (104: Connection reset by peer) . Ten minutes later everything looks normal. sudo dmesg -T | grep -i "killed process" sudo journalctl -k | grep -i oom Hits there mean you don't have a mystery. You have a pm.max_children value nobody checked against real memory. The site that degrades all day and resets overnight TTFB is 180ms at 8am. By 4pm it's 900ms. Nobody deployed. Overnight it's fast again because something restarted PHP-FPM. That's OPcache running out of room. When the cache fills, it stops caching new scripts or wipes and rebuilds, and every miss pays full parse-and-compile again. It degrades gradually, which is why it goes unnoticed for months. The counters are oom_restarts and hash_restarts from opcache_get_status() . Here's the part that trips people up. OPcache state is per SAPI. Run that function from the CLI and you're reading the CLI cache, which is empty, separate, and tells you nothing about your site. You have to ask through PHP-FPM. <?php // drop in webroot, lock to your IP, delete when done $allowed = [ '203.0.113.42' ]; if ( ! in_array ( $_SERVER [ 'REMOTE_ADDR'

CERN engineers announced a shift from Red Hat-based distributions to Debian for its accelerator control systems. This decision stems from Red Hat's tightening compiler mandates, which threatened legacy hardware. The transition, focused on 2,200 specialized control machines, is set for completion in late 2026, while CERN's other systems will remain with Red Hat and AlmaLinux. By Olimpiu Pop

> Your load balancer can distribute traffic perfectly and still overload a server. Here's the part of Round Robin we often overlook. Three servers. Six requests. Request 1 → Server A Request 2 → Server B Request 3 → Server C Request 4 → Server A Request 5 → Server B Request 6 → Server C Perfect. Every server got exactly two requests. So the load is balanced... right? Not necessarily. This is where a simple load-balancing diagram can hide a surprisingly important production problem: Equal traffic does not mean equal work. The Problem Isn't the Algorithm Round Robin is beautifully simple. You have three servers: A → B → C → A → B → C Each new request goes to the next server. For many systems, that's perfectly reasonable. The interesting part is what happens when the requests aren't equal. Imagine this traffic: GET /health POST /generate-report GET /profile POST /export-large-file GET /products POST /process-video Round Robin might still produce: Server A → 2 requests Server B → 2 requests Server C → 2 requests On paper: A = B = C In production: Server A ███░░░░░░░ 25% Server B █████░░░░░ 48% Server C █████████░ 91% Same request count. Very different workload. One Request Is Not One Unit of Work A health-check request might finish in a few milliseconds. Generating a large report could involve: multiple database queries significant memory CPU-heavy processing external API calls several seconds of execution To a basic Round Robin strategy, both are still: 1 request And that's the trap. We often think we're distributing load . What we're actually distributing is requests . Those are not always the same thing. Servers Aren't Always Equal Either There's another assumption hiding here. Imagine: Server A → 8 CPU / 16 GB Server B → 8 CPU / 16 GB Server C → 2 CPU / 4 GB Sending roughly 33% of traffic to each server probably isn't what you want. That's where Weighted Round Robin helps. A → Weight 4 B → Weight 4 C → Weight 1 The stronger servers receive more traffic. Better. But

Everyone backs up. Almost nobody restores. So the backup sits there, growing, quietly reassuring, and completely untested. It is not a safety net. It is a photograph of one. The day you need it is the worst possible day to discover that the job has been failing since March. That the archive is encrypted with a key that lived on the machine you are trying to recover. That it holds the database but not the uploads. That it takes nine hours, and the business gave you two. None of that is exotic. All of it is ordinary. An attacker who reaches your data will reach your backups next, because they sit on the same network, under the same account, behind the same key. That is not a backup. That is a second copy of the same hostage. So test the restore. Not the theory. The restore. Into a clean place. With a clock running. By someone who was not there when it was built. Write down how long it took, because that number is your real promise to everyone downstream. Everything else is marketing. Keep one copy somewhere your production credentials cannot reach. Keep one copy that cannot be deleted, even by you, even when you are certain. And do not trust the log line that says the job succeeded. A green tick is a claim. It is not evidence. Security is not only keeping people out. It is being able to come back after somebody gets in. Anybody can copy data. The skill is putting it back while the phone is ringing and nobody agrees on what happened. Practise the boring version too. Not only the fire. One deleted table on an ordinary Tuesday, because that is usually how it starts. Not an attacker. A person, a missing clause, and a bad afternoon. Restore it once before you need it. Then it is a backup. Until then it is a wish with a filename. – Serguey Asael Shinder

You write instructions for your coding agent. It ignores one of them. You rewrite it more forcefully, in bold, with "IMPORTANT" in front. It still ignores it. Before blaming the model, check whether it ever saw the text. Each of the three cases below is documented behaviour of a tool you already use, each one drops part of your instructions on the floor, and none of them prints a warning. 1. Cursor ignores .md files in .cursor/rules Project rules in Cursor must use the .mdc extension. Cursor's own docs put it plainly: a plain .md file there is ignored by the rules system, because it has nowhere to declare the description , globs and alwaysApply frontmatter that tells Cursor when to apply it. So a file sitting in exactly the right directory, with exactly the right content, does nothing. No error at startup, no "rule skipped" line, nothing in the UI. Ten-second check: find .cursor/rules -name '*.md' 2>/dev/null Any output is a rule that isn't loading. Rename to .mdc and add the frontmatter. A detail that makes this worse: people who set up .md rules a while ago report that they used to work. If that's right, a working setup stopped working at some point during an update, and nothing announced it — so "I checked this once" is not protection. 2. Codex truncates your AGENTS.md files — as a set, not one by one Codex reads the AGENTS.md files that apply to your working directory: a global one, the repo root, and the nested ones on the path. It concatenates them, and the 32 KB truncation applies to that combined payload . This is the part that catches people, because every individual file looks fine: AGENTS.md 12 KB ✓ fine packages/api/AGENTS.md 12 KB ✓ fine packages/web/AGENTS.md 12 KB ✓ fine ----- 36 KB ✗ 4 KB never reaches the model Nobody wrote a "too big" file. The rule you carefully put at the bottom of the last one simply isn't there when the model reads. Check it: find . -name AGENTS.md -not -path '*/node_modules/*' | xargs wc -c Add your global ~/.codex/AGENTS.md t