Infrastructure as code

Codenize any service, manage it with a DSL

Turn live infrastructure into declarative code. Export what already exists, review every change in version control, and apply it back - Idempotently, with a diff you can trust.

  • Idempotent by design
  • No state file
  • Free & open source
Routefile - Route 53 as code
hosted_zone "example.com." do
  rrset "example.com.", "A" do
    ttl 300
    resource_records(
      "127.0.0.1",
      "127.0.0.2"
    )
  end
end

# $ roadwork -a --dry-run
# Apply `Routefile` to Route53 (dry-run)
Why codenize?

Configuration you can diff, grep, and revert

Codenize.tools is an independent directory of these open-source tools. Read more about the codenize approach and the three ideas below.

Idempotency

The service converges to whatever the code says. Apply once or ten times - The result is the same, so retries and re-runs are always safe.

Easy to grep

Your entire service configuration lives in plain-text DSL files. Finding every reference to an IP, a hostname, or a policy is one grep away.

Managed by VCS

Every change is a commit: reviewed in a pull request, attributed to an author, and revertible in seconds when something goes wrong.

The workflow

Export. Review. Apply.

Every codenize tool follows the same three-step loop - Brownfield-first, so you start from the infrastructure you already have.

1

Export what exists

Point the tool at your live service and export its current configuration to a DSL file.

$ roadwork -e -o Routefile
2

Review the diff

Commit the file, edit it, and dry-run to see exactly what would change - Before it does.

$ roadwork -a --dry-run
3

Apply idempotently

Apply the delta. Nothing else is touched, and re-running produces no further changes.

$ roadwork -a

Read the full workflow guide

The toolbox

One focused tool per service

From Route 53 records to MySQL grants - Each tool codenizes exactly one thing and does it well.

Roadworker

Route 53

Roadworker manages Amazon Route 53 through a Ruby DSL. Export hosted zones to a Routefile, review diffs, dry-run changes, and apply them idempotently from the CLI.

Explore

Ridgepole

DB Schema

Ridgepole manages your database schema declaratively. You define tables in a Rails-style Schemafile, and it diffs against MySQL or PostgreSQL and applies only the changes, idempotently.

Explore

Miam

IAM

Miam manages AWS IAM users, groups, roles, and policies through a Ruby DSL. Export current state to an IAMfile, review diffs, dry-run, and apply idempotently.

Explore

Piculet

Security Groups

Piculet manages EC2 Security Groups through a Ruby DSL. Export existing firewall rules to a Groupfile, review diffs in version control, dry-run, and apply idempotently.

Explore

Barkdog

Datadog

Barkdog exports Datadog monitors into a Ruby DSL Barkfile, then applies edits idempotently with dry-run previews, turning alert definitions into reviewable, version-controlled code.

Explore

Gratan

MySQL

Gratan exports MySQL users and grants into a Ruby DSL Grantfile, then applies edits idempotently with dry-run previews, keeping database privileges reviewable in version control.

Explore

View all 21 tools

Safety first

See every change before it happens

Dry-run mode prints the exact difference between your DSL files and the live service. No surprises in production, no "what did that script just do?" moments.

  • Diff output shows creates, updates, and deletes before they run
  • Run dry-run in CI on every pull request
  • Detect drift by scheduling a nightly dry-run

Wiring up that nightly run yourself? A cron expression generator turns plain English into the exact crontab line.

Dry-run & drift detection guide

Illustration of a diff between configuration code and live infrastructure
Brownfield first

Start from the infrastructure you already have

You don't need to rebuild anything. Codenize tools export your existing configuration into clean, readable Ruby DSL files - Your first commit is your real production state.

  • One-command export of live configuration
  • No state file to bootstrap, back up, or corrupt
  • The live API is always the source of truth

How this compares to Terraform

Illustration of live cloud infrastructure being exported into code files
Learn

Guides to configuration as code

What Is Codenization? Managing Services as Code

8 min read

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 guide

Export, Review, Apply: The Codenize Workflow

8 min read

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 guide

Idempotency in Infrastructure as Code, Explained

7 min read

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 guide

All guides

FAQ

Frequently asked questions

What does "codenize" mean?
Codenizing a service means turning its live configuration - DNS records, IAM policies, security groups, database schemas - Into declarative code. A codenize tool exports the current state to a DSL file, shows a diff when the file changes, and applies only that delta back to the service.
Are these tools free?
Yes. Every tool in the directory is open source. Most are Ruby gems released under the MIT license; you can install them with a single gem install command and read the full source on GitHub.
How is this different from Terraform?
Terraform starts from code and provisions new resources; codenize tools start from your existing infrastructure and export it to code. There is no state file - The live API is always the source of truth, so drift detection is just a dry-run. Many teams use both side by side.
Which tool should I start with?
Pick the service that hurts most. Roadworker (Route 53) and Ridgepole (database schemas) are the most popular entry points because DNS records and schemas change often and benefit immediately from review and versioning.
Do codenize tools change anything without asking?
No. Every tool supports a dry-run mode that prints the diff between your DSL file and the live service without applying anything. You decide when to apply, and applies are idempotent - Running them twice produces no additional changes.
More free tools

Other free, no-signup tools we build

Away from infrastructure, we keep a small set of free image utilities: an AI image generator, a batch image converter, and a HEIC to JPG converter for iPhone photos.

Put your configuration in version control today

Pick a service, export its state, and make your first infrastructure commit in the next ten minutes.

Find your tool