标签：#DevOps

Silent failure For three weeks nobody could install your plugin. The publish job was green every single day. You find out when a user asks why the version is so old. Three weeks green, zero installs This happened to us. The publish job for our JetBrains plugin reported success on every run since the middle of July. The plugin was not in the marketplace at all. The registry API answered with a 404. A search for the product name returned nothing. Meanwhile the build was green, the release notes were written, and the changelog was up to date. Nobody noticed. Not the pipeline, not the dashboard, not us. The gap between the last good release and the discovery was three weeks. Your pipeline is not lying to you This is the part worth understanding, because it is why the same thing is probably waiting in your repository too. A release pipeline has one job: get the artifact somewhere a stranger can install it. Almost every pipeline checks something else. It checks that the upload command exited zero. Those two questions agree nearly always. Our publish step went further and did the sensible thing. It caught the failure, compared the error text against a list of known-harmless cases, and exited zero for those. One of those cases was pending moderation. A new version sits in review before it becomes visible. Failing the build for that would be noise, so it was allowed through. Here is the trap. A harmless transient state and a permanent block produce the same message. Once the plugin was stuck, every later run matched the same friendly pattern and reported success. The pipeline answered its question correctly. It was the wrong question. The check that catches it, in about two minutes Ask the store, not the pipeline. That is the whole idea, and you can add it today without changing anything else. One: after publishing, fetch the public listing the way a stranger would. No credentials, no internal API, no authenticated client. Seeing what an outsider sees is the entire point. Tw

Building a Laravel application involves much more than writing PHP code. A production application needs to solve a real business problem, handle users and data reliably, survive deployments, remain secure, and continue to be maintainable as requirements change. Laravel provides an excellent foundation for building modern web applications, but the framework is only one part of the development process. A successful Laravel project typically moves through several stages, from understanding the original business idea to deploying, monitoring, and improving the application in production. Here is what that process looks like. 1. Start With the Business Problem Before thinking about controllers, models, databases, or cloud infrastructure, the first step is understanding what the application actually needs to accomplish. A project might begin with a simple request: "We need a customer portal." That's a starting point, but it isn't a specification. What should customers be able to do? Create and manage accounts? Upload documents? Manage subscriptions? Make payments? View reports? Communicate with employees? Receive notifications? Manage multiple users within an organization? These questions start turning an idea into actual application requirements. One of the easiest ways for a software project to become unnecessarily expensive is to begin development before the problem has been clearly defined. Laravel can make development faster, but building the wrong application faster doesn't solve the underlying problem. 2. Define the MVP Once the requirements become clearer, the next step is determining what belongs in the first release. I generally separate features into two categories: What does the application need in order to provide value? and What can be added later? The first category becomes the Minimum Viable Product, or MVP. For example, a new SaaS application might initially require: User registration Authentication Account management Subscription billing The application's

1. O Problema que o Docker Resolve "Na minha máquina funciona." Poucas frases resumem tão bem um problema que atormentou (e ainda atormenta) times de desenvolvimento: um código que roda perfeitamente no notebook do desenvolvedor, mas quebra no servidor de produção — porque a versão do Python é outra, uma biblioteca do sistema está faltando, uma variável de ambiente não foi configurada, ou o sistema operacional simplesmente se comporta de forma diferente. O Docker resolve exatamente isso: ele empacota uma aplicação junto com tudo que ela precisa para rodar — código, dependências, bibliotecas do sistema, variáveis de ambiente, configuração — em uma unidade isolada e portátil chamada container . Essa unidade roda da mesma forma em qualquer lugar que tenha o Docker instalado: no notebook do desenvolvedor, no servidor de CI, ou em produção. Esta é a primeira parte de uma série que vai do zero ao avançado em Docker: hoje o foco é entender o problema que ele resolve, os conceitos fundamentais e como eles se encaixam. 2. Containers vs Máquinas Virtuais A comparação mais comum ao explicar Docker é com máquinas virtuais (VMs), porque ambos resolvem um problema parecido — isolar e empacotar aplicações — mas de formas muito diferentes. Uma máquina virtual virtualiza o hardware inteiro: cada VM roda seu próprio sistema operacional completo (kernel incluso), gerenciado por um hypervisor. Isso garante isolamento forte, mas tem um custo alto: cada VM consome centenas de MBs a alguns GBs de disco e memória só para o SO, e leva de dezenas de segundos a minutos para inicializar. Um container , por outro lado, virtualiza no nível do sistema operacional: todos os containers em uma máquina compartilham o mesmo kernel do host, mas cada um enxerga seu próprio sistema de arquivos, processos e rede isolados — usando recursos do kernel Linux como namespaces (isolamento de visão) e cgroups (limites de CPU/memória). O resultado é que containers são muito mais leves: alguns MBs a poucas centenas

When I first connected my GitLab CI/CD pipelines to AWS, I used the simplest solution: an IAM user with an Access Key and Secret Access Key stored as GitLab CI/CD variables. It worked. But there was one problem: those credentials were permanent. They had to be stored, protected and eventually rotated. If they were accidentally exposed in logs or compromised, they could remain valid until manually revoked. I wanted a cleaner solution. So I replaced permanent AWS credentials with OIDC federation between GitLab and AWS . The result is simple: GitLab pipelines can access AWS without storing any permanent AWS credentials. In this post, I'll explain how I implemented it, how the authentication flow works, and one important issue I faced when using it with EKS and Terraform. The architecture The authentication flow looks like this: ┌──────────────┐ │ GitLab CI │ └──────┬───────┘ │ │ OIDC token ▼ ┌──────────────┐ │ AWS STS │ └──────┬───────┘ │ │ Temporary credentials ▼ ┌──────────────┐ │ IAM Role │ └──────┬───────┘ │ ├──────────► Terraform │ ├──────────► ECR │ └──────────► EKS Instead of GitLab storing an AWS Access Key, it proves its identity to AWS using a short-lived OIDC token. AWS verifies the token and returns temporary credentials. How does OIDC authentication work? The process can be summarized in five steps: GitLab creates an OIDC token for the CI/CD job. The pipeline sends this token to AWS. AWS verifies that the token really comes from GitLab. AWS checks that the project is allowed to assume the requested IAM role. AWS STS returns temporary credentials. These credentials expire automatically. So there is nothing permanent to store or rotate inside GitLab. Step 1 — Register GitLab as an OIDC provider AWS first needs to trust GitLab as an identity provider. I configured the OIDC provider using Terraform: data "tls_certificate" "gitlab" { url = "${var.gitlab_url}/.well-known/openid-configuration" } resource "aws_iam_openid_connect_provider" "gitlab" { url = var . gi

I Automated My Entire GitOps Security Stack. The First Thing It Blocked Was My Own...

I am testing my first automated end to end social media post automation system. which is created using the free tools. But it is very efficient and productive. i can use this thing in future posting on various platforms to tell people about my learning's and update about me. Tools : Make.com = I use this tool to mainly automate my system it include flow how things works and system is linked. Hashnode = I use this as a central blog and article publishing tool other tools is connected with it so content links is properly distributed. Google Ai Studio = I use this to integrate the ai in between this whole process which just do small job to add the engaging hook and the tags for the reach Buffer = I use to connect X (twitter) with this Because Make.com remove the platform X (twitter) to His integration. After the policy change of the platform. Dev.to = I use this to improve SEO of my post over the google search engine. Challenges : I cannot integrate the github actions with the hashnode becuase this feature is become paid on hashnode. May be in future i can do this thing using self written yml file, i am guessing Not sure will this 100 % work or not. Twitter integration as i described early that twitter integration is not present in the make.com so i use the another tool Buffer. The limits calculation, Their was a limits on each tools for their specific use case so i have to intentionally calculate them properly. Even the free tear of the twitter which is X is few hundreds words that's why i have to limit the text of the post, which is hook only, The threads creation i don't think it will be their in this tools which i am using, i will definitely find it if their. Solutions : Simply use other Way if this way is closed, use different tool for twitter May be in future i create yml file for the github actions but for now i am directly writing on hashnode. The dev.to does not provide feature of direct posting it save your cycle into draft so you have to manually click on pu

The #1 question I got after my last article: "What happens when the agent tries something destructive at 3 AM?" Every CISO I've worked with asks some version of this. They don't care how fast your agent investigates. They care about blast radius. What can it touch? What can it break? Who approved it? Where's the audit trail? This article answers all of that. I gave Kiro Crew a P1 incident and told it to fix it. Then I watched it hit a wall. If you're new to this series, catch up here: Kiro Crew Series The scenario: a real P1 on FinPay FinPay is a payment processing platform. Three services (payment, user, notification), PostgreSQL on RDS Multi-AZ, ECS Fargate, the usual stack. 26 commits of realistic history. CI/CD via GitHub Actions. Someone committed a "performance optimization" that reduced the database connection pool from 50 to 5. Deployed at 5:30 PM on a Wednesday. By 2:47 AM, the pool was exhausted. Transactions started failing. Success rate dropped from 99.8% to 34%. I gave the agent the alert and said: fix it. What happened next is exactly why enterprise teams can trust this thing. Layer 1: Investigation passes freely The agent's first instinct was to investigate. It ran: git log --oneline -10 to check recent deployments cat services/payment-service/config.js to read the configuration grep -rn pool services/payment-service/ to find pool settings All three ran automatically. No approval popup. No human intervention. Why? Read-only operations don't need permission. The agent can look at anything it needs to understand the problem. Reading code, checking logs, searching files. None of that changes state. None of that can break anything. Within 23 seconds it identified the root cause: pool max was changed from 50 to 5 in commit 2181456 ("perf: reduce connection pool overhead for lower memory footprint"). A well-intentioned optimization that was never load-tested. This is the same investigation pattern from Part 2. Fast, accurate, no human bottleneck for the det

If you love the simplicity of Docker Swarm (native Compose files, lightweight single binary) but miss the advanced capabilities of Kubernetes (targeted label placement, SRE-grade observability, built-in DNS service discovery, and zero-trust ingress), meet Gubernator (gbnt) . We are excited to release Gubernator v2.13.0 , introducing three massive feature suites natively integrated into a single binary and a modern Material Design 3 Flutter Web Dashboard: Google SRE Multi-Burn-Rate SLO Engine & Interactive Suite CoreDNS 4-Tab Management Suite & Interactive Dig Playground Caddy Ingress & Zero-Trust Reverse Proxy Suite Fun Fact: The entirety of Gubernator's codebase, multi-node deployment pipelines, and SRE features were designed, built, and pair-programmed using **Google Antigravity (AGY) , Google DeepMind's agentic AI coding assistant! Let's dive into what's new and how you can level up your self-hosted or production container clusters! 1. Google SRE Multi-Burn-Rate SLO Engine & Web Suite Defining Service Level Objectives (SLOs) and tracking Error Budgets is the gold standard of Site Reliability Engineering. Until now, implementing SLOs meant running heavy Kubernetes CRDs (via tools like Sloth or Pyrra) or using costly SaaS platforms. Gubernator v2.13.0 brings Google SRE Workbook (Chapter 5) compliant multi-burn-rate alerting straight to simple docker-compose.yml services: version : " 3.8" services : payment-api : image : hashicorp/http-echo:latest labels : gbnt.slo.enable : " true" gbnt.slo.target : " 99.9" gbnt.slo.window : " 30d" gbnt.slo.template : " caddy-http" gbnt.slo.journey : " Checkout Flow" What makes Gubernator's SLO Suite unique? Google Multi-Burn-Rate Alerting : Automatically generates standard 4-window Prometheus recording and alert rules ( Critical Page 1h/6h & Warning Ticket 3d/14d ). Dynamic "No-Code" Management : Click "+ Configure / Add SLO" in the Web UI or call POST /v1/slo/edit to create, edit, or disable SLOs on the fly without editing Compose

Classic Machine Learning Through the Eyes of an SRE — Part 4 When a computation is too hard, don't compute harder. Change coordinates until it becomes easy. Every engineer has made this move. Pick the right data structure and the impossible query goes O(1). Re-index the table and the report that took an hour takes a second. Move the problem into a space where it's trivial, solve it there, come back. That's the kernel trick. SVM's famous move isn't building a curvy model — it's finding a FLAT cut in a transformed space, which corresponds to a curved boundary back in your original features. The separator stays linear in the transformed space. The space did the work. And here's the part that makes it a trick rather than just a projection: the data never actually goes up there. The optimization only ever needs inner products between pairs of points, and a kernel function computes what that inner product would be in the high-dimensional space, directly from the original coordinates. You get the geometry of a space you never built. Some kernels correspond to infinitely many dimensions, which would otherwise be an awkward amount of memory to allocate. The bet it makes SVM bets that the most ROBUST boundary is the one with the widest margin — maximum distance from the nearest points on each side. And here's the part that rewired me: only those nearest points matter. They're the support vectors. The non-support-vector points don't directly determine the final boundary at all. Compare that to the forest, which averages over EVERYTHING. SVM is the opposite extreme: the borderline cases that become support vectors define the decision boundary. In delivery-risk terms — the projects that teach you where the line is aren't the disasters or the easy wins. They're the borderline ones that barely breached and barely survived. SVM formalizes that. Everything old returns After trees and forests threw away gradient descent, SVM brings some of the regression toolkit back: an explicit los

Almost every cost discussion about AI agents opens with a model price per million tokens, which is the one number that tells you the least. The bill you actually receive is a stack of four things: API calls, infrastructure, the one time build, and the recurring costs nobody put in the estimate. Here is how the stack usually breaks down and which layer is worth attacking first. Where The Money Actually Goes For a typical business agent, a support bot or an internal automation running on a managed platform, monthly operating cost lands between 200 and 1,000 dollars. API calls are 40 to 60 percent of that. Hosting, a vector database for memory, and monitoring share the rest. The spread on either side is wide: a solo developer on open source models and a small VPS can stay under 50 dollars a month, while an enterprise running multi agent systems on frontier models regularly spends 5,000 to 13,000 a month before anyone counts the build. Infrastructure has its own shape. Serverless is the cheapest entry, and a moderate agent handling 10,000 to 20,000 interactions a month usually runs 50 to 200 dollars in compute with no idle charge. Containers on ECS, Cloud Run or Kubernetes cost 100 to 500 and buy persistent connections and steady latency. Self hosted GPU starts around 200 a month for a T4 class instance and passes 1,000 for A100 or H100 class, which only pays off at volumes high enough to amortize it. Vector storage adds 20 to 500, and pgvector on a Postgres you already run removes that line entirely. Model Choice Is A Routing Decision The price spread between tiers is large enough that treating model selection as one global choice is the expensive mistake. Frontier reasoning models sit at the top of the range, mid tier models cost a fraction of that, and the lightweight tier is cheaper again by roughly an order of magnitude. An agent that sends every step to the top tier is paying reasoning prices for string formatting. The fix is routing per step rather than per agent

The deadline nobody missed Every expiry story we've written here has the same shape. A certificate lapses, nobody was watching, something breaks, and everyone is surprised. A Splunk license at a federal agency. Microsoft's own network connectivity tool. Same plot, different logo. This one is the opposite, and that's what makes it worth reading. On October 19, 2026, roughly ten weeks from this writing, the Microsoft Windows Production PCA 2011 certificate expires. It sits under the trust chain for the Windows boot process on essentially every PC shipped in the last fifteen years. Nobody forgot it. The expiry date has been printed inside the certificate since 2011. Microsoft has been publishing guidance for over two years, shipping replacement certificates through Windows Update since 2024, running OEM briefings, and pushing an automatic rollout that requires most users to do nothing at all. It is August. It still isn't done. What's actually expiring Three certificates, four replacements, three dates, all in 2026: Certificate Expires Replaced by Microsoft Corporation KEK CA 2011 June 24, 2026 Microsoft Corporation KEK 2K CA 2023 Microsoft Corporation UEFI CA 2011 June 27, 2026 Microsoft UEFI CA 2023 Microsoft Corporation UEFI CA 2011 June 27, 2026 Microsoft Option ROM UEFI CA 2023 Microsoft Windows Production PCA 2011 October 19, 2026 Windows UEFI CA 2023 Both June dates have already passed. October is the one that matters most, because that's the certificate used to sign the Windows Boot Manager itself. Devices that don't pick up the 2023 certificates keep booting and keep taking normal Windows updates. What they lose is the ability to receive new protections for the early boot path: updates to Boot Manager, Secure Boot database changes, revocation lists, and mitigations for bootkit vulnerabilities discovered from here on. In other words, the machine doesn't fail. It just quietly stops being patchable in the one layer that sits below your antivirus, your EDR agent, a

You know the ritual. terragrunt run --all -- plan Then you scroll. Past forty units of Refreshing state… . Past the ninth identical count instance. Past a tags_all.LastModified that changes on every single run because your CI stamps a timestamp into it. Somewhere in there are the two lines you actually needed to see — probably the # forces replacement on a database. You scroll back up. You lose it. You pipe it to a file and grep for must be replaced . You approve anyway, because it's 6pm. I got tired of that, so I wrote tgsieve . What it does It runs the plan for you, reads the structured output instead of the prose, throws away the noise you declared as noise, collapses everything that repeats, and prints what's left. DESTROY / REPLACE (1) envs/prod/a ± aws_db_instance.main engine_version "14.7" → "15.3" forces replacement UPDATE (5) 5 units envs/dev/a, envs/dev/b, envs/prod/a, +2 more ~ null_resource.pin triggers.region "eu-central-1" → "us-west-2" SUMMARY ±1 replace ~5 update severity: 1 high, 5 medium hid 214 attributes across 3 rules (--explain to see them) That's five units of a real terragrunt plan — the same run terraform prints as several hundred lines. The report nests three deep — where , then what , then which fields : UPDATE (5) envs/prod/c ← the unit, said once ~ aws_s3_bucket.this ← the resource tags_all.entity "tgb" → "tgc" ← the attributes that changed A change that's identical across units replaces the directory with the set it covers, so the first column always answers the same question: where . It doesn't scrape text This matters, because the obvious implementation is fragile garbage. You might reach for terragrunt run --all -- plan -json . It doesn't work: terragrunt forwards terraform's own NDJSON straight through, so lines from units running in parallel interleave with no way to tell them apart. So tgsieve asks terragrunt for machine-readable artifacts and reads those: What Flag it passes What it gets per-unit plans --json-out-dir one tfplan.j

It's 3 AM. A production service is misbehaving, you're on-call, and you'd love an agent that can pull the service's health and tee up a restart for you. The catch is obvious: an agent with raw access to a DevOps API is a liability. One bad call could scale you into a huge bill or delete an incident record you needed. So the real question isn't "can the agent reach the API." It's "which calls should it be allowed to make at all, and how should the dangerous ones be treated differently from the safe ones." That decision is what Skillgate handles, and it's the part we actually build and run in this post. Scope, up front This post is about the classification and curation layer: turning an OpenAPI spec into a governed set of skills. Skillgate decides which endpoints become tools, marks which are read-only, flags which writes should require approval, and denies the destructive ones outright. Wiring an approval flag to a live human-approval pause, and making that pause survive a crash, is the job of the Agent OS runtime, not Skillgate. We link to it at the end. The demo here does not implement that runtime, and this post does not pretend it does. The problem Skillgate solves Point an LLM at a DevOps API and you have three bad options: Expose nothing. The agent is useless. Expose everything. Now the model can call DELETE and scale on a whim. Hand-whitelist every route. It works until the API changes, then it rots. Skillgate replaces all three with opt-in curation plus automatic risk classification. You choose a small surface, and every endpoint on it gets a class based on its method and shape. From REST endpoint to agent skill Skillgate's input is an ordinary REST API described by an OpenAPI spec. Nothing about the API is agent-aware. It's the same deploy, scaling, and incident routes your platform already exposes. Each endpoint is described in the standard OpenAPI shape: a method, a path, some parameters, a description, and tags. A representative operation from the DevOps

The 10-Minute Tax For many years, as a CDK developer, I'd run cdk synth , then cdk deploy , and then cross my fingers — either it deployed cleanly, or it failed somewhere in the middle of a CloudFormation run that had already been going for ten minutes: ❌ MyStack failed: UPDATE_ROLLBACK_COMPLETE Resource handler returned message: "The runtime parameter of nodejs16.x is no longer supported" (HandlerErrorCode: InvalidRequest) Ten minutes. For something CDK could have told you before it ever talked to CloudFormation. These days I let AI agents write a good chunk of my CDK code, which made this even worse — an agent can't iterate when every failed attempt costs it ten minutes. 🤖 AI Agent development loop: Attempt 1: cdk deploy → ⏱️ 10 min → ❌ deprecated runtime Attempt 2: cdk deploy → ⏱️ 10 min → ❌ invalid memory size Attempt 3: cdk deploy → ⏱️ 10 min → ❌ security group rule conflict Attempt 4: cdk deploy → ⏱️ 10 min → ✅ finally works Total time wasted: 30 minutes on things that were knowable at synth time. And if you're deploying something heavy like an Amazon EKS cluster, the penalty stretches to 25-30 minutes per failed attempt. What if the CDK could catch all of those on cdk synth — in seconds? The CDK Lifecycle: Where Validation Fits Before I show off the new validation, it helps to see where it plugs into the lifecycle every cdk deploy goes through: Stage What Happens Executed By 1. Construction Execute main.ts , call new Stack() , build the construct tree in memory CDK App (local) 2. Synth app.synth() traverses the tree, produces CloudFormation template to cdk.out/ CDK App (local) 3. Template Validation 🆕 Post-synth offline validation — default rule set + registered policy plugins CDK App (aws-cdk-lib, local) 4. Create Change Set 🆕 CloudFormation pre-deployment validation — 6 types of online checks against real account state CloudFormation (AWS) 5. Execute Change Set CloudFormation provisions/updates/deletes actual AWS resources CloudFormation (AWS) The gap was a

I remember the old days of manual scaling. You'd jump into a CLI, check your metrics, realize you needed another node or a capacity adjustment, log into a web console, navigate three layers deep into some proprietary dashboard, and hope you didn't click the wrong thing while trying to find a specific cluster ID. Now we have AI agents. But most people are using them wrong. They treat Claude or Cursor as just better search engines for code, rather than giving them hands. If you're running high-availability workloads on something like TiDB Cloud, the friction isn't in writing the SQL—you already know how to do that. The friction is in the operational visibility: knowing exactly what’s happening across your serverless instances versus your dedicated clusters without leaving your IDE. The Gap Between Code and Infrastructure The reason I spend so much time building things like MCPFusion is precisely because of this disconnect. An LLM might help you write a complex join perfectly, but if it doesn't know whether the target TiDB X instance is actually healthy or which project ID handles your staging environment, it's basically flying blind. You end up copy-pasting JSON blobs from your terminal into the chat window just to give the model context. That's slow, prone to error, and frankly, beneath what modern tooling should look like. This is why we released the TiDB Cloud (Serverless Distributed SQL) MCP server on Vinkius. It closes that loop. What This Actually Does (And Doesn't) Let's be very clear about what this tool allows you to do through an agent like Claude or Cursor. We aren't looking for "magic" here; we want predictable utility. The current implementation focuses on discovery and inspection. In DevOps terms, it provides a controlled read-only view of your topology. Here is what's available: Organization Discovery: You can call list_projects to see everything sitting under your umbrella and pull metadata via get_project . This solves the "what was that project ID ag

Adding a “Control de Obra” Module to Ventas → Desarrollos (NestJS + Next.js) TL;DR: I built a brand‑new Construction feature (Control de Obra) inside the Ventas → Desarrollos flow, wiring a NestJS controller, a migration for branding_settings , and a Next.js page. While doing that I also fixed the setToken bug that stopped the BrokerDashboard from refreshing its session. The result is a clean, testable API endpoint and a functional UI component that talks to it. The Problem Our product needed a way for sales teams to track the construction status of each development (obra). The UI already had a “Desarrollos” list, but the backend had no endpoint to create, read, update, or delete construction records. At the same time the BrokerDashboard ( apps/web/src/app/portal-broker/page.tsx ) was failing to refresh the user session after a token rotation. The console showed: Error: setToken is not a function at Object.<anonymous> (src/portal-broker/page.tsx:78:15) Both issues were blockers: No API → the UI could only display static data. Stale token handling → users were logged out unexpectedly after a token refresh. What I Tried First I first tried to reuse the existing VentasPropertiesController ( apps/api/src/ventas/ventas-properties.controller.ts ). The controller was already imported in AppModule , but it was dead code (the class had no routes) and its methods lacked the AuthGuard we use across the API. I added a couple of ad‑hoc routes inside that controller, but: The routes conflicted with the existing /ventas namespace. The controller’s @UseGuards(AuthGuard) was missing, causing 401 errors in the browser. The migration for branding_settings was still out of sync, leading to a “column does not exist” error when the new endpoint tried to read branding data. After a few hours of chasing 404s and 401s, I decided the cleanest path was to create a dedicated module for construction and keep migrations in sync. The Implementation 1. Register the new controller in AppModule // a

Pinterest has revealed the Resource Provisioner Pipeline (RPP), its own Terraform execution engine. It ensures least-privilege access and needs dual-control reviews. This is important for the company’s AWS infrastructure, as it adds strict guardrails to the GitHub Actions workflows. By Claudio Masolo

Long-running agents are usually tested at startup and during normal operation. The awkward middle is ignored: what happens when you need to deploy a new image, rotate a credential, migrate a database, or restart the host while the agent is halfway through a tool call? A process supervisor can restart a crashed agent. It cannot decide whether a browser checkout was committed, whether a webhook was acknowledged, or whether a tool call is safe to replay. That decision belongs in the agent runtime. This post presents a small maintenance-window protocol for agents that run for hours or days. It has four goals: stop accepting new work; let safe work finish or reach a checkpoint; make ambiguous work visible instead of guessing; resume with an explicit recovery decision. 1. Model maintenance as a state transition Do not treat maintenance as kill -TERM followed by hope. Give the runtime a durable state machine: RUNNING -> DRAINING -> QUIESCED -> STOPPED | +-> NEEDS_REVIEW DRAINING rejects new jobs but allows an active job to continue until its next checkpoint or deadline. QUIESCED means there are no unclassified side effects in flight. NEEDS_REVIEW is the safe outcome when the process died after sending a request but before recording the response. Persist the transition, not just an in-memory flag. A minimal record can look like this: { "runtime" : "agent-7" , "maintenance_id" : "mw-2026-08-10-001" , "state" : "DRAINING" , "started_at" : "2026-08-10T08:00:00Z" , "accepting_work" : false , "active_runs" : 2 } If the host disappears, the replacement process can see that the previous shutdown never reached QUIESCED . That is much more useful than inferring health from a missing PID. 2. Put checkpoints around side effects An LLM step is usually replayable. A payment, email, browser click, deployment, or Git push may not be. Record a checkpoint immediately before and after every non-idempotent boundary: PLANNED -> DISPATCHED -> ACKNOWLEDGED -> OBSERVED On restart: PLANNED can be

GitHub Code Quality is now generally available on GitHub Enterprise Cloud and GitHub Team. The service combines CodeQL analysis with AI-assisted detection of maintainability and reliability problems, then uses Copilot Autofix to suggest changes for review in pull requests, according to an announcement from GitHub. By Matt Saunders

Cloud Native Buildpacks, which graduated within the CNCF in July 2026, move base image choice out of per-service Dockerfiles into a single builder owned by platform engineering, enabling fleet-wide patching. BellSoft's hardened Paketo builder is the latest sign that vendors now treat the builder, not the Dockerfile, as the container security control point. By Mark Silvester