Engineering Note

Our Rails deployment worked perfectly. Until we had to recreate it.

The EC2 instance was configured manually.

Security groups were changed from the console.
IAM permissions were added when needed.
Nginx, Ruby, PostgreSQL access and deployment dependencies were configured step by step.

Nothing was technically wrong.

The problem was:
We couldn't reliably reproduce the environment.

So we moved the infrastructure into Terraform.

Instead of documenting what someone needed to configure, we defined it:
* VPC and networking
* EC2 instances
* Security groups
* IAM roles
* Load balancer
* Database and Redis access
* Environment-specific configuration

Now infrastructure changes go through the same process as code:
Change → Review → Plan → Apply

It also made scaling easier.

Need another environment?

We don't start with:
> “What did we configure on the previous server?”

We start with:
> “What does the infrastructure code define?”

Important learning:
Infrastructure-as-code isn't about using Terraform because it's popular.

It's about removing infrastructure knowledge from people's heads and putting it into something the team can review, reproduce and maintain.

Your Rails application may be version-controlled.

Your production infrastructure should be too.