Infrastructure as Code for Small Businesses: Terraform, Pulumi and the Native Options

If you are a team of two to twenty people running workloads on one cloud, start with OpenTofu, keep the state in an encrypted bucket and run it from your existing CI. That combination costs nothing in licence fees, is governed by a foundation rather than a vendor, and will carry you well past the point where you can afford a platform engineer. If you are entirely inside one provider and expect to stay there, the native tool (CloudFormation on AWS, Bicep on Azure) is a perfectly honest answer too. Everything else in this article is the reasoning behind that sentence.

What infrastructure as code actually buys a small team

The pitch for infrastructure as code is usually automation. That is not the part that saves a small team. The part that saves you is the diff.

When your network, databases and permissions live in a Git repository, a change arrives as a pull request that says exactly what will happen: this security group opens to the internet, this database grows two sizes, this bucket loses its public block. Somebody who did not write it can read it in four minutes. Six months later, when the person who built it has moved on, the repository is still there explaining itself. Console clicks leave no such trail, and a screenshot in a wiki is not a trail either.

The second benefit is rebuild speed. Not disaster recovery theatre, just the ordinary ability to stand up a staging environment that genuinely resembles production, run something destructive against it, and throw it away on Friday. Teams without code either skip that step or keep a permanent second environment they pay for every hour of every month.

Be honest about the cost side, though. Flexera’s 2026 State of the Cloud Report, which surveyed 753 cloud decision-makers, found wasted spend on infrastructure and platform services rose to 29% after five years of decline, with AI workloads named as the driver. Writing your estate down as code does not reclaim that money. It does mean that when you go looking for the three idle environments, you can find them by reading a directory listing rather than clicking through a billing console.

The licence change that reshuffled the field

You cannot compare these tools sensibly without the licence history, because it is the reason there are now two near-identical products.

In August 2023 HashiCorp moved Terraform off the Mozilla Public Licence and onto the Business Source Licence 1.1. Source-available, not open source: you may still run it internally, but you may not build a competing hosted service on it without an agreement. The response was quick. On 20 September 2023 the Linux Foundation announced OpenTofu, a fork of the last MPL-licensed Terraform, describing it as an open source alternative to the widely used provisioning tool.

Two things since then turned that fork from a protest into infrastructure. IBM completed its acquisition of HashiCorp on 27 February 2025, buying all outstanding shares at USD 35 each for an enterprise value of USD 6.4 billion, so Terraform’s roadmap now sits inside IBM’s automation portfolio. And OpenTofu was accepted into the Cloud Native Computing Foundation on 23 April 2025 at Sandbox maturity, which gives it the thing a single vendor cannot: a governance model that does not answer to one company’s revenue.

Practically speaking, configurations written for Terraform 1.5 run on either. Providers come from registries both tools can read. If you have an existing Terraform estate, the migration is mostly a binary swap and a careful look at any feature added after the fork. If you are starting fresh in 2026, the licence question answers itself.

The five realistic options, side by side

Two entries deserve a note. Pulumi’s engine is Apache 2.0, but the thing most teams actually adopt is Pulumi Cloud, the hosted state and policy service, and that is commercial. And the CDK on AWS is not a separate engine: it synthesises CloudFormation templates, so you inherit CloudFormation’s behaviour along with a nicer authoring experience.

What the control planes cost per resource

Here is where small teams get surprised. The tool is usually free. The place that stores your state, runs your plans and enforces your policies usually is not, and it tends to bill per managed resource — every object under management, every month, whether or not anything changed.

Work it through for a realistic estate. A small production environment with a load balancer, two services, a managed database, a cache, a bucket, DNS records, certificates, roles and policies lands somewhere between 150 and 400 resources once you count every subnet and IAM attachment. At 400 resources, Pulumi’s Essentials plan at USD 40 per month includes 40 credits and covers up to 500 managed resources, so you are in the bundled tier rather than paying per unit. Pulumi’s Pro plan is USD 400 per month and covers up to 2,000 managed resources; Enterprise is USD 2,000 per month up to 4,750.

HCP Terraform’s free organisation is limited to 500 managed resources, which is a reasonable fit for one small environment and a tight fit for three. Beyond it you are in paid tiers that also bill per resource under management, so the bill grows with your inventory even in a quiet month. That is the structural thing to notice: per-resource pricing is not usage pricing. A dormant staging environment costs the same as a busy one.

Against that, CloudFormation and Bicep are genuinely free as services. AWS charges nothing for CloudFormation itself when you are managing AWS resource types, and Bicep is part of Azure Resource Manager at no additional cost. If you are single-cloud, that is a real saving and one fewer vendor relationship.

Which one fits your situation

One combination to avoid: adopting two engines because different people preferred different ones. Split estates mean split state, two sets of modules and an argument every time something spans both. Pick one, write it down, and make the exceptions explicit.

The parts small teams underestimate

State is the real artefact. The file that maps your code to live resources is more valuable than the code. Put it in an encrypted, versioned bucket with locking enabled, restrict who can read it, and test that you can restore a previous version. Treat it as a secret, because it frequently contains them.

Drift happens, and usually for a good reason. Somebody resized a database at 02:00 during an incident. If your next plan quietly reverts that, you will have a second incident. Run a scheduled plan that only reports, read it weekly, and decide deliberately whether the code or the console is right.

Blast radius beats elegance. One repository holding networking, databases and DNS for every environment means every change risks everything. Split by lifecycle instead: slow-moving foundations in one place, per-environment application stacks in another. Smaller plans are easier to review and far less frightening to apply.

Secrets do not belong in variables files. Use the provider’s secret manager and reference it, so the value never lands in a plan output, a CI log or a state file you later share with a contractor.

A first fortnight that does not end in tears

1. Pick one environment. Staging, not production. Resist the urge to codify the whole estate in week one.
2. Create the state backend first: a versioned, encrypted bucket with locking, in the same account you are managing.
3. Import what exists rather than rebuilding it. Both OpenTofu and Terraform can adopt live resources into state; do it in small groups and run a plan after each until it comes back clean.
4. Wire plan into your pull requests and apply into your main branch. Give CI a role scoped to what it actually manages.
5. Add a weekly scheduled plan that reports drift to a channel somebody reads.
6. Only then copy the pattern to production, and only after you have destroyed and rebuilt staging once from scratch.

Expect the first week to feel slower than clicking. It is. The payback arrives the first time somebody asks why a bill went up and you answer from a commit history instead of a guess. If you want help choosing between these and wiring it into a pipeline, our cloud solutions work is delivered remotely, and it is usually a two-week engagement rather than a project. For the wider context, our introduction to cloud technology covers the vocabulary, cloud service models explains where responsibility sits, and our comparison of the leading cloud providers is the companion piece on choosing where to run.

Want a second opinion on your infrastructure as code setup before it hardens into something nobody wants to touch? Get in touch with Eudora Technology to talk about your project.