What Is Codenization? Managing Services as Code

Codenization means turning the live setup of a running service into code. A tool reads what already exists and writes it out as a text file. From then on, you manage that config like any other code.

DNS records, IAM users, security group rules, database schemas, monitors: all of these live as changeable state behind an API. A codenize tool exports that state into a Ruby DSL file. A DSL is a small language built for one job. You commit the file to Git, review it, and apply it again and again.

The name comes from the codenize-tools project. It is a family of Ruby gems that all share one contract. Export what exists, edit it as code, show a diff, then apply only the difference.

What Codenization Means

Most service config starts as clicks. Someone adds a DNS record in the AWS console. Someone grants a MySQL privilege from a shell. Someone adds a Datadog monitor in a web form.

The service works. But the config only lives as state inside someone else's database. You cannot diff it. You cannot search it. You cannot review it before it changes.

The source of truth becomes a file

Codenization flips that around. The tool reads live state through the service's API. Then it writes that state out as a Ruby DSL file. Here is a Route 53 zone the way Roadworker exports it:

hosted_zone "example.com." do
  rrset "example.com.", "A" do
    ttl 300
    resource_records(
      "192.0.2.10",
      "192.0.2.11")
  end

  rrset "www.example.com.", "CNAME" do
    ttl 3600
    resource_records "example.com"
  end
end

That file becomes your source of truth. Change the file, run the tool, and the live zone updates to match. Every tool in the family works this way. Each one pairs a single service with a single DSL and the same loop.

Where Codenization Comes From

The codenize-tools family grew out of the Japanese Ruby community in the early 2010s. Most of it was written by one engineer: Genki Sugawara, known online as winebarrel.

Sugawara worked at Cookpad, a recipe platform with a very large Rails deployment. The tools solved real problems at that scale. Ridgepole, for example, replaced piles of Rails migration files with a single Schemafile that describes the schema's end state.

The original codenize.tools site gathered these gems under one name and one idea. It was never a platform or a framework. It was a set of small, sharp tools that shared a workflow.

An honest maintenance note

Read this before you adopt anything. The ecosystem's activity peaked years ago. Ridgepole is still maintained and widely used, especially in Japan. Many sibling gems, like Kelbim and Piculet, are now dormant.

Dormant does not always mean broken. The APIs these gems wrap are stable, so many still work. Check each gem's recent history before you bet production on it. For AWS-facing tools, Terraform is often the mainstream alternative.

Export First: The Brownfield Difference

Terraform, CloudFormation, and Pulumi are provisioning-first. You write code, run it, and resources come into being. That model is great for greenfield work, meaning brand-new setups.

It fits existing infrastructure less well. Adopting a live resource into Terraform used to mean one import per resource, plus hand-written config that matches reality. Newer Terraform eases this, but importing a mature account is still a project.

Codenize tools start at the other end. The first command you run is an export, and it covers the whole scope at once. roadwork -e -o Routefile dumps every hosted zone and record. miam -e -o IAMfile exports every IAM user, group, role, and policy.

These tools assume the infrastructure already exists. Your job is to bring it under management. That is a brownfield-first posture. For a fuller comparison, see Codenize Tools vs Terraform.

No state file to break

Codenize tools keep no state file. Terraform diffs your code against a stored state backend. A codenize tool diffs your DSL straight against the live API on every run.

There is nothing to lock, migrate, or corrupt. The trade-off is simple. The tool treats everything in its scope as managed, and it has no memory of what it did not export.

The Export, Review, Apply Loop

Every tool in the family supports the same four steps, usually behind the same flags:

1. Export. Dump live state to a DSL file. This is your baseline.
2. Review. Commit the file to Git. Now every change is a diff, and diffs get reviewed.
3. Dry-run. Ask the tool what it would change. The output is the exact delta.
4. Apply. Make the API match the file. Nothing else changes.

roadwork -e -o Routefile      # export live Route 53 state
git add Routefile
git commit -m "Route 53: baseline export"
$EDITOR Routefile             # change a record
roadwork -a --dry-run         # preview the exact delta
roadwork -a                   # apply it

The step-by-step version covers repo layout, CI, credentials, and rollback. You can find it in Export, Review, Apply: The Codenize Workflow.

Idempotency: Apply Twice, Change Nothing

The DSL describes a desired end state, not a list of actions. On apply, the tool reads current state, computes a diff, and makes only the calls needed to close the gap.

Apply the same file ten times, and runs two through ten do nothing. No writes. No side effects. That makes these tools safe to re-run after a failure, safe to schedule from cron, and safe to wire into CI.

An apply also doubles as drift repair. If someone edits a record in the console, the next apply quietly puts the file's version back. The mechanics and the traps get a full treatment in Idempotency in Infrastructure as Code, Explained.

Why It Matters: VCS, Review, Grep

The original site justified the whole idea with three plain points. They still hold up:

• You can manage config with a VCS. Git gives you history, blame, and revert for DNS records and IAM policies. "What changed last Tuesday, and who did it?" becomes git log, not a CloudTrail dig.
• You can review changes before they happen. A pull request against a Routefile is a reviewable, blockable artifact. A second reviewer catches mistakes before they cause an outage.
• You can grep it. "Which security groups allow port 22 from anywhere?" becomes a text search across one repo, not a console safari across accounts.

None of these need codenize tools alone. Any infrastructure-as-code gives you the same wins. What the codenize approach adds is speed. You get all three for infrastructure you already have, in an afternoon, without rebuilding anything.

The Tool Family

Here are the core gems, what they manage, and where they stand today:

There is a longer tail of smaller gems for Elastic IPs, CloudWatch, S3 bucket policies, and more. This site's tool index lists each one with its current status.

When to Choose This Approach

Reach for a codenize tool when:

• The config already exists and is unmanaged. Export-first turns a year of console clicks into reviewed code in one command.
• The scope is one service. You want DNS or IAM under version control today, not after a long migration.
• Terraform handles the resource poorly. Database schemas and MySQL grants are the standout cases. Gratan manages grants that Terraform never covered well.

When Terraform is the better fit

Prefer Terraform when you provision new infrastructure. Prefer it when resources reference each other across services. Prefer it when your team already standardized on it, or when you need providers this family never covered.

The two also compose well. Many teams run Terraform for provisioning and Ridgepole for schemas side by side. There is one hard rule to remember.

Never let two tools manage the same resource. Each one will fight to enforce its own file, and they will revert each other forever.