Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/arjunprabhulal/devops-skills/immutable-infrastructurenpx skills add arjunprabhulal/devops-skills --skill immutable-infrastructuregit clone --depth 1 https://github.com/arjunprabhulal/devops-skillsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/arjunprabhulal/devops-skills/immutable-infrastructure)<a href="https://agentmods.dev/skills/arjunprabhulal/devops-skills/immutable-infrastructure"><img src="https://agentmods.dev/badge/skills/arjunprabhulal/devops-skills/immutable-infrastructure.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00114 | $0.01408 |
| Opus 5 | $0.00057 | $0.00704 |
| Sonnet 5 | $0.00023 | $0.00282 |
| Haiku 4.5 | $0.00011 | $0.00141 |
Grade A, and why
immutable-infrastructure scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 4d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 120 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Immutable Infrastructure
Every server that's ever been SSH'd into to fix something is now a unique, undocumented artifact — its actual state exists only on that machine, not in any repo. Multiply that by a fleet and you get servers that have quietly diverged from each other in ways nobody can enumerate, discovered only when one of them fails differently than the rest.
Immutable infrastructure closes that gap by removing the option: nothing is ever changed on a running instance. To make a change, you build a new image and replace the instance that's running the old one. There is no in-place path, so there's no drift to accumulate.
Servers are cattle, not pets — you don't nurse a sick one back to health, you replace it and move on, and the fact that you can tell them apart at all is the bug.
1. Bake the change into the image, never onto the running instance
The rule is absolute, not a preference: if a change needs to happen, it happens in the image build pipeline, and a new instance rolls out. SSH access for routine changes shouldn't just be discouraged — the access itself should be hard to get, because the two-second fix under pressure is exactly how drift gets reintroduced.
- Remove standing SSH access for config changes — break-glass access for genuine incident debugging is different from routine access for "quick fixes."
- Automate every provisioning step in the image build, so nothing about a running instance depends on a human having remembered to run a command against it.
- Treat any manual change discovered on a running instance as an incident, not a shortcut that saved time — it means the image no longer describes reality.
Done when: no instance in the fleet has ever received a change that isn't also in the image it was built from.
2. Build the golden image the same way every time, from a pipeline
A golden image is only trustworthy if it's reproducible — built by a pipeline from a versioned definition (Packer template, Dockerfile, or equivalent), not assembled once by hand and then snapshotted. A hand-built image is a pet wearing a cattle costume.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 4d ago First seen · 120 lines · 114 tokens per session scan A ca05ac35eac5
immutable-infrastructure is a skill published in the GitHub repository arjunprabhulal/devops-skills (2 stars, last pushed 10d ago), licensed MIT. It adds 114 tokens to every session and 1,408 once invoked, about $0.0006 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
gke-ai-troubleshooting-handle-disruption-gpu-tpu
Diagnoses, predicts, and mitigates node disruptions during Compute Engine host maintenance and hardware or software maintenance events for GPU and TPU workloads on GKE. Use when diagnosing node disruptions, predicting host maintenance events on GPU/TPU nodepools, inspecting node interruption PromQL metrics, auditing…
gke-ai-troubleshooting-jobset-interruption
Diagnoses GKE JobSet interruptions, restarts, and preemptions for AI/ML training workloads autonomously. Use when troubleshooting JobSet restart loops, spot VM preemptions, node readiness failures, host VM issues, or coordinator worker crashes. Don't use for general GKE cluster creation, basic workload deployment, or…
gke-alert-configuration
Configures alerting policies in Terraform for Google Kubernetes Engine (GKE) clusters, workloads, and services using PromQL and Google Cloud Managed Service for Prometheus. Use when writing, analyzing, validating, or deploying Terraform alerting policies to monitor GKE service latency, traffic, error rates using…
gke-app-onboarding
Manages GKE application onboarding, covering containerization, deployment manifests, and migration. Use when onboarding or deploying an application to GKE for the first time, or containerizing an app for GKE. Don't use for general GKE cluster administration or upgrades (use gke-basics or gke-upgrades instead).
gke-backup-dr
Configures Backup for GKE: the BackupRestore cluster addon, BackupPlan and RestorePlan resources, restore workflows, and CMEK-encrypted backups. Use for backup policies, disaster recovery, or GKE cluster restores. Don't use for database backups.
gke-basics
Manages core GKE cluster provisioning, credentials, Autopilot vs Standard selection, and workload deployment. Use when creating GKE clusters, fetching kubectl credentials, configuring Workload Identity, or deciding between Autopilot and Standard modes. Don't use for specialized GKE networking (use gke-networking)…