Immutable Infrastructure
debt(d7/e9/b9/t5)
Closest to 'only careful code review or runtime testing' (d7). Detection tools listed (docker, terraform, packer, ansible) are infrastructure tools, not automated static analysis that flags violations. The detection_hints explicitly mark automated as 'no'. Detecting drift from immutability — such as someone SSH-ing into production or making undocumented changes — requires careful review of deployment processes, audit logs, or runtime observation. There's no compiler or linter that catches 'you modified a running server'. You might notice via infrastructure-as-code diffs or monitoring, but it's fundamentally a process/discipline issue caught through review.
Closest to 'architectural rework' (e9). The quick_fix describes building a new Docker image for every release with blue-green deployment — but transitioning from mutable infrastructure (SSH-based deploys, snowflake servers) to immutable infrastructure is a wholesale architectural transformation. It requires setting up image build pipelines, container orchestration or immutable VM workflows, CI/CD changes, new deployment strategies, and retraining teams. This touches every aspect of how software is deployed and operated. Remediating a violation (e.g., undoing drift from SSH changes) also requires rebuilding and redeploying from scratch.
Closest to 'defines the system's shape' (b9). Immutable infrastructure is a foundational architectural decision that shapes every deployment, every operational procedure, and every team workflow. It applies broadly across all contexts (web, cli) and all environments. Once adopted, every future change — how you deploy, how you debug, how you handle config, how you manage state — is shaped by this commitment. It's a rewrite-or-live-with-it level decision that defines the system's operational architecture.
Closest to 'notable trap' (t5). The misconception field states developers think 'immutable infrastructure means you can never update a server' — confusing immutability with inability to change. This is a documented gotcha: the concept's name suggests rigidity, but the actual practice is about replacing rather than modifying. Common mistakes like SSH-ing in for 'quick fixes' or not baking dependencies into images show that developers familiar with mutable server management will naturally guess wrong about the workflow. It's not catastrophic (t9) since the concept is well-documented and most devs eventually learn it, but it contradicts ingrained habits.
Also Known As
TL;DR
Explanation
Immutable infrastructure treats servers as disposable artifacts: once deployed, a server is never patched, reconfigured, or updated in place. To release a new version, a new machine image (AMI, Docker image, VM snapshot) is built with the change baked in, tested, and swapped in via blue/green or rolling deployment. Benefits: no configuration drift between instances, trivial rollback (re-deploy the previous image), reproducible environments, and easier security patching (rebuild from base). PHP applications must be truly stateless (no local session files, no on-disk uploads) to work with immutable infrastructure — all state lives in external services (Redis, S3, RDS).
Diagram
flowchart LR
subgraph Mutable - Traditional
SERVER[Server] -->|SSH in| PATCH[patch, configure, update]
PATCH -->|snowflake server| UNIQUE[Unique state<br/>cannot reproduce]
end
subgraph Immutable - Modern
IMAGE[Build new<br/>Docker image / AMI]
IMAGE -->|deploy| NEW[New instances]
NEW -->|route traffic| LB[Load Balancer]
LB -.->|terminate| OLD[Old instances<br/>destroyed]
end
style UNIQUE fill:#f85149,color:#fff
style NEW fill:#238636,color:#fff
Common Misconception
Why It Matters
Common Mistakes
- SSH-ing into production servers to make 'quick fixes' — breaks immutability and creates undocumented drift.
- Not baking application dependencies into the image — runtime installs create environment inconsistency.
- Images that are too large due to including build tools — use multi-stage Docker builds to keep runtime images lean.
- No image versioning — unable to roll back to a previous known-good image.
Code Examples
# Mutable infrastructure anti-pattern:
ssh prod-server-1
apt-get install -y php8.3-gd # Undocumented — only on server 1
# Server 2 now has different packages — drift
# Next server provisioned from IaC is missing this package# Immutable infrastructure — never modify running servers
# Build new images, swap them in, discard old ones
# Docker image build + tag:
$ docker build -t yourapp:git-$(git rev-parse --short HEAD) .
$ docker push registry.yourapp.com/yourapp:git-abc1234
# Kubernetes rolling deploy:
$ kubectl set image deployment/app php=registry.yourapp.com/yourapp:git-abc1234
$ kubectl rollout status deployment/app
# Automatic rollback:
$ kubectl rollout undo deployment/app
# Benefits:
# - No 'works on my machine' — all envs run same image
# - Rollback = re-deploy previous image tag
# - No config drift — servers can't diverge
# PHP app requirements:
# - Stateless: sessions in Redis, uploads in S3 (not local disk)
# - Config from env vars: .env loaded per environment