Midnight, three days before Eid. The IT team of an online store in Lampung is setting up an additional server for the traffic surge. They follow a setup document written two years ago — but it's outdated: service names have changed, menus in the cloud panel have moved, and one security configuration step no longer matches what's written. Two hours later, the new server finally comes alive — but missing one important firewall setting. Fortunately, no traffic has hit it yet. "Next time we'll document this better," says one team member, as everyone said last year too.
This scenario illustrates the most common problem in the infrastructure world: everything is done manually, remembered by heart, and documented half-heartedly. Servers are set up through clicks in a panel, configuration lives in a particular person's head, and no two servers are truly identical even though they should be. When the person who knows leaves or forgets, the knowledge leaves with them.
Infrastructure as Code (IaC) is the answer to this problem. It turns infrastructure — servers, databases, networks, configuration — into code that can be written, stored, reviewed, tested, and re-run. This article explains IaC from a practical perspective for Indonesian businesses: what it is, why it matters, how to get started with Terraform, and the mistakes to avoid.
What Is Infrastructure as Code?
Infrastructure as Code is the practice of managing infrastructure through code and definition files, rather than through manual processes in admin panels or setup documents. Instead of creating a server by clicking through a cloud dashboard, you write a text file describing that server — its specifications, the network it lives in, its security, and all its configuration — then run a tool that turns that description into real infrastructure.
There are two main styles of IaC:
Declarative configuration. You state the desired end state, and the tool figures out how to achieve it. Example: "I want one server with these specifications, on this network, with this application installed." A tool like Terraform reads that statement, compares it to reality, and does whatever is needed to make reality match the desired state. If no server exists, it creates one. If a server exists but its specs differ, it changes it.
Imperative configuration. You write the steps to be executed in sequence: "create a server, then install the application, then configure the firewall." Tools like Ansible and Chef work this way. It gives step-by-step control, but you're responsible for getting the order right.
Most teams use a combination: Terraform for infrastructure (servers, networks, databases), and Ansible or similar for in-server configuration (applications, system settings). Terraform is the most popular IaC tool — it supports nearly all major cloud providers and many other services, so one description language can manage your entire infrastructure.
Why Your Business Should Care About IaC
IaC sounds like a topic for "DevOps kids," but its benefits are deeply business-oriented. Here's why.
Reproducibility: no more "why is it different?"
With IaC, two environments — say, the production server and the test server — are built from the same definition files. The results should be identical. This eliminates the most annoying class of problems in development: an application works on the test server but breaks in production, and nobody can explain why. Invisible differences between two servers that "should be the same" are the slipperiest source of bugs.
Speed: from weeks to minutes
Building a new server manually can take hours to days, especially when undocumented steps are involved. With IaC, a new server complete with configuration can be created in minutes — just run existing code. Sudden needs (a test server for a new project, extra capacity for a campaign) stop being two-day projects.
Consistency and security
Configuration written as code can be reviewed like regular code: checked by others, tested, and verified. Security settings (firewalls, access rights, encryption) no longer depend on memory — they're part of an auditable definition. Teams can answer the question "do all our servers have the right firewall settings?" by reading code, not by checking each one individually.
History and accountability
Because IaC lives in a version control system (like Git), every infrastructure change is recorded: who changed what, when, and why. If a change causes a problem, you can see the history and revert to a previous version. It's like having CCTV footage for your infrastructure — something impossible with manual panel clicks.
Better disaster recovery
Remember the server that had to be rebuilt after a disaster? With IaC, "rebuilding" means running existing code. A complete infrastructure can be recreated in a new location within hours, not weeks. IaC and disaster recovery are a natural pair: infrastructure code becomes part of your recovery plan.
Understanding Terraform: The Most Widely Used Tool
Terraform is an open-source tool from HashiCorp that has become the de facto standard for IaC. Its concept is simple:
- Write definitions. You write configuration files (in a language called HCL, which resembles JSON but is more human-readable) describing the infrastructure you want: cloud provider, servers, networks, databases, and their settings.
- Plan. Terraform compares your definitions with the current infrastructure state, then shows what it will do: what will be created, changed, or deleted. It's like a preview before execution — you can review the impact before approving.
- Apply. Once you approve the plan, Terraform executes it and builds the infrastructure as defined.
Two important Terraform concepts:
State. Terraform stores a record of the infrastructure it manages in a file called state. This file is Terraform's "memory" — without it, it can't know what's been created. State must be stored securely (usually in cloud storage) and protected, because it contains sensitive information about your infrastructure.
Modules. Modules are reusable collections of definitions. Instead of writing server configuration from scratch every time, you can use ready-made modules — from the community or your own team. Modules make IaC scalable: teams don't repeat the same work for every new project.
Terraform isn't the only IaC tool — there are AWS CloudFormation, Google Deployment Manager, Pulumi, and others — but its ecosystem is the broadest and most vendor-neutral. One set of Terraform files can manage resources across multiple clouds at once, which is useful for businesses that don't want to be tied to a single vendor.
Real Benefits for Mid-Sized Businesses
Cost savings through automation
IaC lets infrastructure be managed with less manual effort. Test environments can be created when needed and destroyed when done — without IaC, this process is often considered "too much hassle," so test environments are left running for months, inflating cloud bills. With IaC, environment lifecycles are controlled by code, and costs follow need, not forgetfulness.
Faster team onboarding
New employees who need working environments (development servers, test databases) no longer wait for the one person who "knows how to set things up." They run the code, and the environment is ready within an hour. Knowledge no longer lives in one person's head — it lives in a repository everyone can access.
Safe migration and scaling
Want to try moving part of your workload to the cloud? IaC lets you build a new environment identical to the old one, test it safely, then switch traffic — without disrupting running systems. Our cloud migration guide covers this process; IaC is the tool that makes it far safer.
Easier audits and compliance
When someone asks "how is our infrastructure configured?" or "are security settings aligned with policy?", the answer is in the code — readable, auditable, verifiable. This is invaluable in the era of Indonesia's Personal Data Protection Law, where data controllers must be able to demonstrate they manage data properly. Our website security guide explores this context further.
Getting Started: Practical Steps for Your Business
Starting with IaC doesn't have to be a big bang. Follow this gradual approach.
1. Start with one environment, not everything
Don't try to rewrite your entire infrastructure in a week. Pick the most painful piece — say, the application server that's constantly recreated, or the test environment that always misbehaves — and write its definition with Terraform. Learn the process small before expanding.
2. Use version control from day one
Store all IaC files in a Git repository. This isn't optional: change history, peer review, and the ability to revert are the core reasons IaC is valuable. A private repository (GitHub, GitLab, Bitbucket) is enough; what matters is that every change is recorded.
3. Secure your credentials
IaC files contain sensitive information: cloud access keys, database passwords, server addresses. Never store them directly in code. Use features like Terraform Cloud, a vault, or environment variables to store secrets separately, and restrict who can access them. Credentials leaked in a repository are one of the most expensive mistakes in IaC.
4. Write clear, modular definitions
Name resources meaningfully, separate configuration per environment (production, test, development), and use modules for reused pieces. Infrastructure as code is only valuable if the code is readable by others — including yourself six months from now.
5. Review changes like code
Before applying infrastructure changes, have a colleague review them. The same review process used for application code applies to infrastructure code. This catches mistakes before they become production problems.
6. Apply to the test environment first
Run changes in the test environment, verify, then apply to production. Terraform makes this easy because environments are built from the same definitions. The habit of "changing directly in production" is one to eliminate.
The DevOps Workflow Around IaC
IaC usually arrives alongside broader DevOps practices. You don't have to adopt everything at once, but understanding the context helps.
Continuous Integration (CI) means every code change — including infrastructure code — is automatically tested. For IaC, this means validating definition files: is the syntax correct, does the plan make sense, are there conflicts? CI tools like GitHub Actions or GitLab CI can run these checks on every change.
Continuous Deployment (CD) means changes that pass automated testing are applied to infrastructure without manual intervention. For small teams, this can start simply: changes on the main branch that pass automated validation are applied to the test environment, while production deployment still requires human approval.
Monitoring and observability are IaC's inseparable partners. Infrastructure code determines what gets built; monitoring determines whether what's built stays healthy. Once infrastructure is managed as code, you can monitor its changes automatically — for example, being notified every time configuration changes.
For teams just starting, the recommended order: IaC first (with Terraform), then simple CI for automated validation, then gradual CD. Each stage delivers value on its own; there's no need to wait for everything to be perfect.
Common Mistakes to Avoid
Treating IaC as click automation
IaC isn't just "speeding up manual setup." Its value lies in definitions that are documented, reviewable, and repeatable. A team that writes IaC code but keeps changing configuration manually in panels creates two conflicting sources of truth — and Terraform state will always lag behind reality.
Storing secrets in code
Access keys and passwords in configuration files are time bombs. Once code enters a repository, those secrets can leak to anyone with access — and they're often already scattered before anyone notices. Use a secret manager from day one.
Not maintaining state
The Terraform state file is the source of truth for your infrastructure. Lost or corrupted state makes Terraform lose its memory — and can lead to duplicated resources or wrong deletions. Store state in a safe centralized location (not on one person's laptop) and enable locking so two people can't apply changes simultaneously.
Too much scope too early
Rewriting your entire company infrastructure in one sprint is a recipe for chaos. Start small, learn, then expand. IaC is a journey, not a one-time project.
Forgetting that infrastructure code needs maintenance
IaC files are real code: they can become outdated, wrong, and in need of review. Infrastructure defined two years ago and never touched may no longer reflect current needs — or may no longer be valid with the latest Terraform and provider versions. Schedule regular maintenance like any other code.
Cost Estimates and Time Investment
The fair question: how much does it cost and how long does it take to start with IaC?
Tool costs: Terraform is free and open-source. The main cost is team time. For an unfamiliar team, allocate 1–2 weeks to learn the basics (writing definitions, understanding state, core workflow) and 2–4 weeks to build the foundation for one real environment. If your infrastructure is complex, budget more.
Service costs: if no internal team can learn it, DevOps consultants can help — from mentoring sessions (Rp 5–15 million) to full implementation projects (Rp 25–75 million depending on complexity). Compare that with the cost of a single incident caused by wrong manual configuration — often far larger.
Payback time: businesses that build test environments repeatedly, create new servers often, or frequently face "production differs from test" usually see returns within months.
When IaC Isn't Needed Yet
Honestly: IaC isn't for everyone. If your business has one simple server, one website, and no plans to grow soon — IaC may be overkill. Good documentation and tidy backups might be enough.
But watch for these signs: servers numbering more than one, test and production environments starting to diverge, manual setup eating hours, or only one person truly understanding the infrastructure. Once any of these signs appears, IaC stops being a luxury — it becomes a necessity to prevent compounding error costs.
Repeatable Infrastructure, a Calmer Business
Back to the IT team setting up a server the night before Eid. With IaC, the story is different: they run one command, a battle-tested definition file creates the server complete with all security settings, and within minutes the server is ready for traffic. No forgotten steps, no configuration differing from other environments, and every change recorded in the repository. They can go back to sleep in peace.
That's the real value of Infrastructure as Code: not just technology, but peace of mind. The peace that your infrastructure can be explained, repeated, and restored. The peace that knowledge doesn't vanish when someone leaves. The peace that a new server won't differ from an old one because of "one forgotten step."
For businesses that want to build this practice, the team at Kartech. in Bandar Lampung can help — from mapping your existing infrastructure, designing an IaC foundation with Terraform, to building DevOps workflows and sustainable review habits. Start by reaching out through our contact page or explore our services page.
And if you're just considering infrastructure as a whole, useful reading: our cloud vs on-premise comparison for choosing the foundation, the cloud migration guide for the transition process, and the disaster recovery guide to ensure everything can be recovered. Infrastructure managed as code is one of the calmest investments a digital business can make.
