Skip to main content
Cloud & Delivery

Infrastructure as Code (IaC)

Term 30 of 68 in the ERPStack technical glossary

What is Infrastructure as Code (IaC)?

Infrastructure as Code (IaC) is the practice of managing and provisioning computer cloud infrastructure—such as virtual servers, networks, and databases—using machine-readable definition files.

Infrastructure as Code (IaC) at a glance

Principle
The repository is the source of truth; a console change is drift to be corrected, not a fix
Tooling
Terraform definitions reviewed in pull requests and applied by GitHub Actions
Payoff
3 environments reproduced from 1 definition, differing only by variables
Disaster recovery
Rebuilding a region becomes an apply, not an archaeology exercise across 40 console screens
Built with
Terraform definitions reviewed in pull requests and applied by GitHub Actions against AWS or Microsoft Azure, provisioning a Virtual Private Cloud, Kubernetes clusters, PostgreSQL 18 and a Bastion Host
Numbers that matter
3 environments from 1 definition; 0 undocumented console changes; rebuilding a region becomes 1 apply instead of 40 screens
Compare with
Console clicks on AWS or Microsoft Azure, Docker Compose files describing 1 machine and no network, or a Vercel project configured entirely in a dashboard
Commonly paired with
Docker and Kubernetes workloads, GitHub Actions applying plans, a Bastion Host and Virtual Private Cloud on AWS or Microsoft Azure, PostgreSQL 18 provisioning, RBAC and SSO, and SOC 2 or ISO 27001 change evidence
Drift control
1 source of truth; an emergency console change is reconciled within 1 working day, not left for 6 months
State discipline
1 remote state per environment with locking, so a second concurrent apply is refused rather than merged; Postgres rules are never edited outside the plan.
Who reads the plan
government, finance and energy estates on AWS or Microsoft Azure, where Terraform plans, Kubernetes manifests and Docker images are the only description of production SOC 2 and ISO 27001 assessors accept.

How Infrastructure as Code (IaC) works in production

Instead of manually configuring servers and subnets in cloud console dashboards, IaC tools (such as Terraform or AWS CloudFormation) define resources as version-controlled code. This guarantees consistent environments, prevents configuration drift, and allows quick disaster recovery.

The ERPStack approach to Infrastructure as Code (IaC)

We define all database instances, network firewalls, and server groups in Terraform scripts, ensuring your infrastructure is fully documented, tested, and reproducible.

Frequently asked questions about Infrastructure as Code (IaC)

What does Infrastructure as Code change day to day?

It makes infrastructure reviewable. With Infrastructure Code, a new subnet or a changed security group arrives as a pull request with a diff, a reviewer and a history, exactly like application changes. That removes the category of incident where nobody can explain when a rule changed or why, and it makes environments reproducible instead of being artefacts of whoever configured them first.

Why is configuration drift such a problem?

Because it invalidates your model of the system. Once someone fixes an incident by editing the console, the Infrastructure Code definition no longer describes reality, and the next apply will either revert the fix or fail. The discipline that prevents this is treating emergency console changes as temporary by definition, with the code updated immediately afterwards so the 2 converge again.

How does IaC help with compliance evidence?

It turns configuration into an auditable record. Reviewers under frameworks like FISMA or SOC 2 ask how changes are authorised and how environments stay consistent, and Infrastructure Code answers both with commit history and pull request approvals. Encryption settings, network rules and logging configuration become assertions in a repository rather than claims about what someone believes is currently set.

Should application and infrastructure code share a repository?

Usually yes for a single product. Keeping Infrastructure Code alongside the application means a change requiring both — a new queue and the code that reads it — arrives as 1 reviewable unit. Separate repositories make sense when infrastructure is shared across several products with a different release cadence, but for 1 system the coordination cost of splitting them outweighs the tidiness.

Related reading

Explore Custom ERP Solutions by Location, Industry, and Alternatives

Global Architectures