标签：#DevOps

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

If you are staring at An error occurred (AccessDenied) when calling the GetObject operation: Access Denied , this guide walks through every cause in the order you should check them, with the exact fix for each. I am a cloud associate and I debug this error often enough that I keep a mental checklist. Here it is, written down. Quick answer: the 8 most common causes of S3 Access Denied In Amazon S3, "Access Denied" means the request was authenticated but not authorized, or an explicit deny blocked it. In practice it is almost always one of these, roughly in order of frequency: The IAM identity (user or role) is missing the required s3: permission. The bucket policy does not allow the action, or explicitly denies it. S3 Block Public Access is on and you expected public/anonymous access. SSE-KMS : you have S3 permission but not kms:Decrypt on the encryption key. Missing s3:ListBucket , which turns a "key not found" into a 403. Cross-account access where only one side grants permission. An explicit Deny somewhere wins (SCP, permissions boundary, VPC endpoint policy, or bucket policy). Object ownership / ACLs after a cross-account upload. If you only remember one thing: an explicit Deny anywhere in the chain always beats an Allow . Start by finding a deny, then work down the list. Step 0: Confirm which identity is actually making the request Before touching any policy, confirm who you are. Most "but I have admin" cases are the wrong principal. aws sts get-caller-identity Check the Arn in the output. If it is a role you did not expect (an EC2 instance profile, a CI role, an assumed role), you have been debugging the wrong identity's permissions the whole time. This single command saves more time than any other step. Step 1: Does the IAM identity policy allow the action? S3 needs the specific action for the specific resource. The two resource types trip people up: Bucket-level actions ( s3:ListBucket , s3:GetBucketLocation ) target the bucket ARN: arn:aws:s3:::my-bucket Obj

Why Geo-Block? Not every country needs to reach your server. If you run a local business in Brazil, you don't need traffic from North Korea. If you serve customers in the EU, you probably don't need visitors from 150 other countries hitting your login page. Geo-blocking at the WAF level stops unwanted traffic before it ever reaches your application. No CPU spent. No database queries wasted. No bandwidth consumed. The Numbers from My Server After 30 days of logging, I checked where attacks came from: Traffic Source % of Total Requests % of Attacks Target countries (where my customers are) 23% 8% Non-target countries 77% 92% 77% of my traffic came from countries I don't serve, and 92% of attacks originated from those countries. Geo-blocking the non-target regions would eliminate the vast majority of malicious traffic with zero impact on real users. Setting Up Geo-Blocking in SafeLine Step 1: Go to IP Groups -> Geo Blocking in the dashboard. Step 2: Choose your approach: Option A: Allow-list mode (strictest) Block everything, then whitelist specific countries. Block : ALL Allow : United States , Canada , United Kingdom , Germany , France , Netherlands Option B: Block-list mode (targeted) Allow everything, then block specific high-noise regions. Block : Russia , China , Vietnam , North Korea , Iran Step 3: Apply the rule. Done. What Happens to Blocked Visitors Blocked IPs see a 403 Forbidden page. They can't reach your application at all — the WAF drops the connection at the proxy layer. Your app server never sees these requests. SafeLine logs every geo-blocked request to Attack Logs. You'll see: Which country the IP was from What URL they tried to access The exact timestamp Which Countries to Block Based on my 30-day log analysis and common community reports: Almost always safe to block: North Korea — 0 legitimate traffic for 99.9% of sites Iran — heavy scanner activity, minimal legitimate traffic (for non-Iranian sites) High scanner volume, consider blocking if not yo

The Problem Your login page, search endpoint, or contact form is getting hammered. Rate limiting is the fix — but implementing it in application code means finding every endpoint, writing middleware, choosing a storage backend, and deploying changes. On a WAF, you set it once and it applies everywhere. Why WAF-Level Rate Limiting Is Better Approach Code-Level WAF-Level Setup time Hours to days 5 minutes Code changes Required None Applies to One endpoint at a time All routes with one rule Storage Redis/Memcached needed Built into WAF Performance impact Hits your app server Blocked at proxy Updates Deploy new code Change a rule in dashboard Step-by-Step: Rate Limit Setup 1. Log into SafeLine Dashboard Go to https://<your-ip>:9443 . Navigate to Rules -> Add Rule -> Rate Limiting. 2. Create Your First Rule — Login Protection Name: Login brute force protection Match: URL contains /login OR /wp-login.php OR /auth Limit: 5 requests per minute per IP Action: Block (return 429 Too Many Requests) Block duration: 15 minutes This stops credential stuffing cold. An attacker who tries 5 wrong passwords in 60 seconds gets blocked for 15 minutes. That's a maximum of 480 attempts per day — vs unlimited without rate limiting. 3. Search Endpoint Protection Name: Search rate limit Match: URL contains /search OR /query Limit: 30 requests per minute per IP Action: Challenge (JS captcha) Search endpoints are expensive. A single user running a script can do 1,000+ queries per minute and degrade performance for everyone. 30/min is generous for humans but stops scripts. 4. Global Baseline Name: Global request limit Match: /* Limit: 300 requests per minute per IP Action: Throttle Catches anything that slips through specific rules. 300/min = 5/sec, which is more than any human needs. What Happens When a Limit Is Hit SafeLine logs every rate limit trigger to the Attack Log. You'll see: Which IP triggered it Which endpoint they were hitting Time of the trigger Whether they got blocked, challenge

AI agents don't usually become unreliable all at once. They degrade quietly. One session the agent...

I don't know about you, but I re-lookup cron syntax every single time. Is it 0 12 * * 1-5 ? Or */5 ? Honestly — nobody keeps this in their head. Instead of another cheat-sheet I'll forget, I built a builder: Pick day, hour, minute from dropdowns See the expression translated to plain English live Preview the next 5 runs in your timezone (this catches the classic "off by one" DST surprises) Get copy-paste snippets for Python, Node.js, Bash, Docker, GitHub Actions and n8n Free, no signup, runs fully client-side: https://cron-generator-kappa.vercel.app If you like it, the cheat-sheet guide is here: https://cron-generator-kappa.vercel.app/guides/cron-cheat-sheet

The Infrastructure: Setting Up Jenkins on AWS The foundation of this project began by provisioning an Ubuntu EC2 instance on AWS. Setting up the environment meant defining strict networking rules (opening Port 22 for SSH and Port 8080 for the Jenkins UI) and structuring the Jenkins environment with clear access controls. In Jenkins, maintaining a secure and organized environment generally falls into two roles: Administrators: Responsible for managing the Jenkins cluster, installing necessary plugins, and handling data backups. Users: Focused purely on creating jobs to run their respective workflows. The Magic of Docker-out-of-Docker (DooD) One of the most critical architectural choices was deciding how to let Jenkins build Docker images without installing a heavy, nested Docker engine inside the Jenkins container itself. The solution was a Docker-out-of-Docker configuration. By running the following command, I spun up the Jenkins container while binding it directly to the host machine's Docker socket: docker run -p 8080:8080 -p 50000:50000 -d \ -v jenkins_home:/var/jenkins_home \ -v /var/run/docker.sock:/var/run/docker.sock \ -v $( which docker ) :/usr/bin/docker jenkins/jenkins:lts This single command did a lot of heavy lifting. It mapped port 8080 for the UI and 50000 for Jenkins agent communication. More importantly, mapping /var/run/docker.sock gave the Jenkins container the ability to pass docker build and docker push commands directly to the EC2 host’s Docker engine. (Just remember to ensure your jenkins user has the right permissions to access that socket!). Hitting the Wall: The Limitations of Freestyle Jobs Initially, I set up the application lifecycle running npm install , npm test , and npm pack using a standard Jenkins Freestyle job. Freestyle jobs are great for quick, isolated tasks. However, their limitations become glaringly obvious when you try to build a project with multiple automation steps. Orchestrating a complex workflow by chaining multiple Fr