Guides to configuration as code
Everything you need to run infrastructure as reviewable, revertible, grep-able code - From first export to production-grade drift detection.
Browse every guide
Six deep-dive guides that take you from your first export to production-grade drift detection. Read them in order, or jump to the one that solves today's problem.
What Is Codenization? Managing Services as Code
Codenization turns live service configuration, like DNS, IAM, schemas, and monitors, into declarative Ruby DSL files you can grep, review, and re-apply. Learn where the approach came from, how the export-review-apply loop works, and when to choose it.
Read guideExport, Review, Apply: The Codenize Workflow
The practical getting-started guide: export live configuration with one command, commit it to Git, preview every change with a dry-run, and apply idempotently. Includes repo layout, review checklists, CI wiring, credentials, and rollback.
Read guideIdempotency in Infrastructure as Code, Explained
Idempotency means the same code applied N times yields the same result. See how codenize tools achieve it by diffing a declarative DSL against live APIs, with Route 53 and MySQL examples and the pitfalls to watch for.
Read guideCodenize Tools vs Terraform vs CloudFormation
Terraform is the industry default; codenize tools take a different bet: no state file, built-in export, one Ruby DSL per service. An honest comparison of philosophy, import stories, dry-runs, and when each approach wins.
Read guidePutting Infrastructure Config in Version Control
Exported DSL files only pay off once they live in git. Repo layouts, commit and PR conventions, branch protection, secrets hygiene, CI-posted dry-run diffs, and rolling back an incident with git revert.
Read guideDry-Run and Drift Detection Best Practices
Dry-run diffs your DSL against the live API and writes nothing, which means drift detection is just a dry run on a timer. Reading diffs, nightly CI checks, alerting, and the accept-or-reject reconciliation decision.
Read guide