Infrastructure as code: work environments we can recreate

Series II: From infrastructure to agentic projects in production. Episode 05 of 20.

In the previous episode, we separated the identities and credentials of the fictional B2B portal for requests and documents. The next step is to turn decisions about networks, services, and access into configurations that can be read, reviewed, and rebuilt. The main decision is that approved changes in code and validated plans should become the standard path to infrastructure, with manual interventions as documented and reconciled exceptions.

What is infrastructure as code

Infrastructure as Code, abbreviated IaC, means describing infrastructure resources in files that can be versioned and processed by a tool. OpenTofu is an open-source example that can manage cloud and on-premises resources through readable configurations. We use it here to explain the method, not as a mandatory choice for every company.

Code can describe networks, virtual machines, rules, storage spaces, DNS, or managed services, within the available providers' limits. It does not automatically include the application, client data, backups, or incident procedures. Nor does it turn a weak architecture into a secure one. IaC makes intentions repeatable and differences visible; the quality of the outcome still depends on decisions, access, and checks.

Minimal structure for the portal

Hypothetical scenario: the portal has development, test, and production environments. In the infrastructure repository, we keep modules for network, compute, storage, and technical identities. Each environment has its own approved values and state. Module reuse reduces accidental differences but doesn’t force environments to be identical. Production may have redundancy and stricter policies, while development may use smaller resources and synthetic data.

A simple structure might include:

• modules, for reusable components like the network and application service;
• environments/dev, test, and prod, for each environment’s composition and values;
• automated checks for format, validation, and policies;
• documentation on owner, order of application, recovery, and exceptions.

Secrets do not go into versioned files. The configuration can refer to the identity or managed location from which an authorized process retrieves them. AI agents developing the portal can propose changes to this structure. The agent built into the portal, which classifies a request, does not need to change infrastructure.

Workflow: write, plan, review, apply

OpenTofu’s documentation describes three basic steps: write, plan and apply. In a team, we turn these into operational controls.

1. Changes are made on a branch and explained in a pull request.
2. A controlled environment validates the configuration and generates the plan, essentially a preview of the proposed actions.
3. A reviewer compares the intent with the plan: what’s added, modified, replaced, or deleted, whether there are any disruptions, and who might be affected.
4. Once approved, a final plan is generated for the same commit, using the current state, and then applied through the target environment’s identity.
5. The team checks the service and records the result. If the application is partial, don’t assume reverting the code undoes all effects.

The plan seen in a pull request can differ from the final one if infrastructure, integration order, or state has changed in the meantime. That’s why an old plan isn’t applied mechanically. We regenerate and review it when the context has changed. Plan files can contain sensitive values, so we don’t publish or attach them without control.

For a small company, approval may belong to a single designated person, but author and approver should be separate for high-risk changes. You don’t need a complex platform from day one. However, a clear application path, a change history, and an emergency rule are necessary.

State is not just any file

State, or the infrastructure state, links real resources to the declared objects in configuration. OpenTofu uses it to decide what must be created, changed, or removed. State can contain identifiers and sensitive attributes, including initial passwords for some resources. Marking a value as "sensitive" can hide its display, but doesn’t guarantee its removal from state.

In a team, we keep state in a controlled backend, with minimal access, encryption, history, and suitable backups. We explicitly check whether the backend supports locking, meaning concurrent write blocking. OpenTofu uses locking automatically when the backend provides it, but not all do. Forcing an unlock without confirming the operation’s owner can allow two writes and corrupt the state.

OpenTofu can encrypt state and plan files, but the encryption key becomes a critical dependency. Losing it can make the state unrecoverable. Encryption doesn’t protect against file loss, using an old plan, or someone running the tool with legitimate access. The recovery procedure must be tested, not just written down.

IaC state is not a backup for the portal’s database and documents. It can help rebuild resources, but persistent content needs separately tested copies, retention, and restore procedures.

Drift: the gap between code and reality

Drift is the deviation between the approved configuration and the existing infrastructure, for example after a manual change in the console. An updated plan can reveal the difference, but remediation shouldn’t be automated blindly. The change may be accidental, an emergency intervention still needed, or an indication that the code model is incomplete.

The portal rule is simple: we identify the owner, reason, and impact, then explicitly choose whether to revert to code or adopt the change in configuration. After an emergency, we update the plan and reconcile the code before the next deployment. This way, the console doesn’t become a secondary source of truth known only to one person.

What we allow development agents

An AI agent can prepare a pull request, explain the plan, and flag unusual resources. It’s not given production credentials by default and can’t approve its own changes. We rerun validation and security checks after every fix, not just at the end. A study published at ESEM 2026 found security regressions in some iterative IaC repair loops with language models; results vary depending on the detection method, so they shouldn’t be generalized to every tool. The practical takeaway is that a functional fix may also alter other properties.

The component added to the project is the minimal repository for environments and the rule: no production deployment without a final plan tied to the commit, review, and authorized identity. The outcome doesn’t guarantee perfectly identical infrastructure, since images, provider APIs, and external services may change. For a realistic rebuild, we pin key versions, keep necessary artifacts, and regularly test a fresh environment. In the next episode, we’ll turn project objectives into verifiable tasks for people and AI agents.

Sources

• OpenTofu, Documentation and Working with OpenTofu, for tool scope and the write, plan, apply flow; documentation reviewed as of October 7, 2026.
• OpenTofu, Sensitive Data in State and State Locking, for state protection and concurrent writes.
• OpenTofu, State and Plan Encryption, for capabilities, limits, and key recovery.
• Agyekum and Santos, Does Fixing Break Security?, ESEM 2026, academic study on security regressions in iterative IaC repair with language models.

Next step

Do you want reproducible environments and verifiable infrastructure changes? Talk to i8 about an Infrastructure as Code workflow tailored for your team.