IaC
Infrastructure as Code (Terraform & Pulumi)
We write your infrastructure as code in Terraform or Pulumi, organise it in modules, and make it normal to provision a new environment in an afternoon — not a week.
Infrastructure as code
What separates a platform from a black box
- Every change reviewable as a pull request
- Git
- Reuse across environments and teams
- Module
- Daily plan catches diff between code and reality
- Drift
- Rules enforced automatically in CI
- Policy
How we think about IaC
Infrastructure as software, not as clicks.
Infrastructure-as-code is the clear dividing line between a platform a team can maintain and a platform only the original consultant understands. When your infrastructure lives as Terraform or Pulumi in Git, changes can be reviewed as code, environments can be reproduced, and a new developer can see why the system looks the way it does — instead of guessing.
We write IaC for new platforms from day one, and we convert existing platforms built in the console to IaC when your team decides to take control. We organise the code into reusable modules, set state management up correctly (remote state, locking, separation per environment), and integrate it into your CI so changes are planned, reviewed and applied systematically — not ad hoc from a developer's machine.
We default to Terraform because the ecosystem is largest and the hiring pool widest, but Pulumi is clearly better when your team already works in TypeScript or Python and wants real language features (loops, abstractions, types) instead of HCL. We choose based on where your team is, not on trends.
What we deliver
A platform your team can maintain.
Modules, state management, CI integration and policy-as-code — set up right from the start.
Module design and structure
We build modules covering the patterns you use again and again (VPC, ECS service, RDS instance, Cloudflare zone setup) with clear inputs, outputs and documentation. A new environment is a composition of modules — not 800 lines of copy-paste.
State management and backends
Remote state in S3 + DynamoDB locking, or Terraform Cloud / Spacelift if you want a UI and policy engine. State is separated per environment so production can never be changed by accident from a developer's machine.
CI integration and automated plans
Every pull request automatically gets a plan in CI as a comment — so reviewers see what actually changes before they approve. Apply runs via CI with audit logs and can require manual approval for production.
Multi-environment setup
Identical environments (production, staging, ephemeral preview) built from the same modules, only parameterised per environment. A new environment can be stood up in an afternoon, torn down again that evening.
Drift detection and policy-as-code
Daily plan in CI catches drift between code and reality. OPA, Sentinel or Checkov set policy-as-code ("no public S3 buckets", "all RDS must have backups") so rules are enforced automatically.
Console-to-IaC conversion
We import existing resources (terraform import, terraformer) and structure them into modules. We do it without downtime and without deleting resources — just taking control.
Before you commit
What you should consider first.
How big should it be?
A small app doesn't need a multi-account, multi-region IaC organisation with 14 modules. We scale complexity with need. For a typical startup, one Terraform stack per environment with a handful of modules is enough — we expand when you have a real problem to solve.
Terraform Cloud vs. self-hosted vs. CI-only
Terraform Cloud (or Spacelift, env0) gives you UI, audit logs and a policy engine out of the box — good for larger teams. Self-hosted in CI is simple and cheap — good for small teams. We choose based on your team size and how much governance you need.
Lock-in between providers
Terraform is multi-cloud in theory, but most modules are provider-specific. We design the core architecture so it's possible to move (no aws_-specific tricks in business modules), but we don't force it where it costs real value.
Who can apply?
Initially, all developers can typically apply to staging, but only one or two can apply to production — via CI with manual approval. As you grow, we formalise it in policy-as-code and just-in-time permissions. We design for both phases.
FAQ
What people usually ask.
Terraform or Pulumi?
Terraform if your team already knows HCL, if you want the largest ecosystem of modules and documentation, and if hiring pool matters. Pulumi if your team is TypeScript or Python folks and wants real language features (types, loops, abstractions) instead of HCL. We've built both and advise pragmatically — not based on trends.
Can you convert our existing AWS setup to Terraform?
Yes. We import the resources (typically via terraformer or terraform import), structure them into modules and clean up drift between console and code. We do it without deleting resources or taking production down. A typical conversion takes 4–10 weeks depending on complexity — afterwards you have a platform your team can maintain.
How long does it take to set up IaC from scratch?
For a new platform, IaC isn't a separate phase — it's how we build from day one. For an existing setup, a thorough conversion with module design, state setup, CI integration and documentation typically takes 4–10 weeks.
Can our team maintain IaC after handover?
Yes, that's one of the main goals. We write modules with clear interfaces and documentation, run workshops with your team, and do a formal handover. If you want us to maintain it continuously, we can do that too — but the code is yours and the structure is understandable.
How do you handle secrets in IaC?
Secrets never live in Terraform state or variables. We use AWS Secrets Manager, HashiCorp Vault or Doppler — Terraform references them, but the values live outside state. If state needs to contain something sensitive, we encrypt the backend state with KMS and limit access to two or three people.
Ready to get started?
Let's have a no-pressure conversation.
We'll get back within one business day with concrete input — not a stock proposal.