A New Zealand startup can spend a morning clicking through cloud consoles, then discover that its staging environment still doesn't match production. That familiar scramble is exactly why infrastructure as code has moved beyond DevOps fashion. OWASP New Zealand's 2022 State of AppSec survey found that 52% of organisations used IaC in deployment practices, while 57% primarily configured cloud infrastructure with IaC rather than manual setup. Only 16% relied mainly on manual configuration (Datacom's 2025 Annual Cloud and Infrastructure Report).
The problem usually starts small. A founder needs a test environment, so someone creates a database by hand. A developer changes a firewall rule in the console. Another engineer adjusts production during a late-night incident and forgets to write down what changed. Each action seems harmless. Together, they create a snowflake environment, a system that works, but only because one or two people remember its odd little habits.
Then the business grows. A new engineer needs access. A customer asks how systems recover after an outage. An investor wants confidence that the platform can support the next stage. Suddenly, “which button did you click?” isn't a useful operating model.
Infrastructure as code turns those decisions into files that teams can review, test, approve, and run. The files can describe networks, compute, databases, permissions, monitoring, and other cloud resources. Instead of rebuilding an environment from memory, a team works from a recorded design.
The simple idea: if infrastructure matters to the business, it should have a versioned source of truth.
That doesn't mean every server action becomes rigid or joyless. It means routine changes stop depending on tribal knowledge. A platform engineer can review a pull request rather than reconstructing a console session. A founder can see how the company's foundation is organised without learning every cloud service.
IaC also connects naturally with resilience work. Teams planning recovery, failover, and failure testing can use RETRO//STRESS stress testing methods to examine how systems behave under pressure, then capture repeatable infrastructure changes in code.
For NZ startups, the signal is clear. IaC is already part of local cloud practice. The useful question isn't whether it sounds modern. It's whether your team can afford to keep provisioning critical systems by hand.
Infrastructure as code means describing the infrastructure you want in code, then using a tool to create or change real resources. The code might define a virtual network, a container cluster, a storage service, or the permissions attached to an application. The exact syntax varies, but the central move stays the same: configuration becomes something a team can store and review.
A useful analogy is cooking. An imperative approach is a spoken list of actions: turn on the oven, chop the vegetables, place the tray on the middle shelf, then lower the heat. The order matters, and the result can change if the kitchen starts in a different state.
A declarative approach describes the meal you want. The tool works out which actions are needed to reach that result. Terraform, CloudFormation, and Kubernetes commonly use this style. You describe the desired state, while the tool compares that intention with what exists.
Idempotence sounds abstract, but the practical meaning is friendly. Run the same configuration again and it should leave the system in the same intended state, rather than creating duplicates or applying an accidental second change. A good IaC workflow can safely check and reconcile resources without treating every run as a brand-new event.
Drift is what happens when reality wanders away from the code. Someone changes a production setting manually, or a cloud service adjusts a resource outside the normal workflow. The code says one thing. The environment says another. Drift detection helps reveal that gap before it becomes an incident.
Immutability takes a stricter view. Rather than repeatedly modifying a live server, a team creates a new image or environment and replaces the old one. This can reduce hidden history, though it may not suit every database or stateful workload. Mutable infrastructure, where existing resources are changed in place, remains useful when replacement is costly or risky.
Keep this mental model: the code describes intent, state records reality, and the IaC tool manages the difference.
Version control adds the missing memory. A change to a network rule can pass through review, carry an author, and retain its history. That makes infrastructure more like a maintained product and less like a collection of personal shortcuts. For another plain-language explanation, the Infrastructure as Code guide from Ryware is a useful companion.
A typical workflow begins with a code change. An engineer updates a module, adds a resource, or changes a variable for an environment. The IaC tool then creates a plan showing what it believes will happen. People review the plan, the pipeline applies the approved change, and the tool records the resulting state.
That state matters because code alone doesn't always tell the full story. A state file maps declared resources to their real counterparts. It helps the tool understand what already exists, what needs updating, and what should be removed. Losing or corrupting state can leave a team unsure whether a resource is managed, unmanaged, or dangerously half-managed.
Modules provide the next layer of order. A team might package a standard network, database, or application foundation into a reusable component. New services then consume that component with carefully chosen inputs instead of copying a large block of configuration and changing it by hand.
Environment promotion should feel like moving the same recipe through different kitchens. Development may use smaller resources and relaxed settings. Staging should resemble production closely enough to reveal important problems. Production receives the reviewed version, with deliberate differences expressed as variables rather than secret console edits.
The main patterns look like this:
Terraform, CloudFormation, Ansible, and Pulumi can all appear in an automation stack, but they don't occupy precisely the same role. Terraform and CloudFormation focus strongly on provisioning resources. Ansible is particularly useful for configuring existing machines and services. Pulumi lets teams define infrastructure with general-purpose languages such as Python or TypeScript.
For founders, the choice isn't about collecting tools. It's about deciding where the boundary sits between cloud provisioning, machine configuration, application delivery, and policy. A managed cloud IT services partner can help draw those boundaries when the internal team is still small.
Tool selection should follow your team's habits and your cloud direction, not a popularity contest. A small AWS-only team may value native coverage. A startup expecting several providers may favour broader support. A team comfortable with Python may find Pulumi easier to reason about than a purpose-built configuration language.
| Tool | Approach | Best For | State Management | NZ/AU Consideration |
|---|---|---|---|---|
| Terraform | Declarative HCL | Multi-cloud provisioning and a large provider ecosystem | Uses state and a backend chosen by the team | A common skill set can help with hiring and external support |
| AWS CloudFormation | AWS-native templates | Teams committed to AWS | AWS-managed stack model | Strong AWS integration, with a closer tie to one provider |
| Ansible | YAML playbooks and task automation | Server configuration and operational tasks | Generally task-oriented, with less emphasis on a central provisioning state model | Useful when a startup has existing machines or mixed environments |
| Pulumi | General-purpose programming languages | Teams wanting familiar application language patterns | Uses stack state with a selected backend | A good fit for engineering teams that prefer normal testing and language tooling |
Treat infrastructure code as production code. Store it in version control. Require review for changes to identity, networking, data stores, and public access. Run formatting, validation, linting, and security checks before an apply step reaches a live environment.
Secrets deserve special care. Don't place passwords, private keys, or long-lived tokens in a repository, even if the repository seems private. Use a secrets manager and give the pipeline only the permissions it needs. Keep humans and automation on separate roles where practical.
Testing should begin with the risk, not with a grand testing programme. A plan preview can catch an unexpected deletion. Static analysis can flag an overly broad permission. A temporary environment can test whether a module behaves as intended. These checks won't guarantee safety, but they make risky changes visible earlier.
People choosing a career path or assessing platform capability may also find expert insights from nexus IT group useful, especially when translating IaC knowledge into practical engineering judgement.
A sensible default: start with the tool your team can maintain at 2 am, not the one with the longest feature list.
Automation increases consistency, but it can also repeat a bad decision with impressive efficiency. A misconfigured permission in one manual environment is a problem. The same permission encoded into a shared module can spread much further.
That's why security belongs inside the IaC workflow, not at the end of it. Datacom's reporting found that only 50% of NZ organisations believed their cloud investments delivered the promised benefits, while 28% said benefits were partially met and 22% said they weren't met (Datacom's cloud transformation report). IaC won't fix weak cloud decisions on its own. It can, however, make those decisions visible and repeatable.
A pull request can trigger formatting, validation, policy checks, and a plan. Reviewers then see the proposed change before anything is provisioned. Tools such as Checkov, TFLint, cloud-native policy systems, or custom policy as code rules can inspect configuration for known risks.
Use approvals for sensitive changes. A database replacement, public network rule, or identity policy shouldn't slip through because an automated job happened to run quickly. Automation should remove toil, not remove judgement.
State needs its own operating discipline. Keep shared state in a protected remote backend with access control, locking, backups, and recovery procedures. Don't let several engineers apply conflicting changes at once. Treat state as sensitive operational material because it can reveal resource relationships and configuration details.
A lean checklist helps:
For startups building a security baseline, practical guidance on cybersecurity for startups can sit alongside these IaC controls. The two disciplines reinforce each other.
IaC fits neatly beside application delivery, but it shouldn't become an invisible side effect of every code build. Infrastructure changes need their own review path because they can affect data, access, cost, and availability even when the application code looks harmless.
A useful lean-team flow starts with a pull request. The pipeline checks the IaC files, creates a plan, and posts the result where reviewers can read it. If the plan changes a security group or replaces a resource, the reviewer can pause the merge and ask for a safer design.
Start with one environment. Choose a non-production service with clear ownership. Import existing resources carefully if the tool supports it, or codify a small new environment first. The aim is to learn how plans, state, reviews, and recovery feel in your own system.
Add repeatable foundations. Move networking, identity boundaries, logging, and shared storage into modules or components. Keep variables explicit. Avoid building a giant abstraction that nobody can explain.
Connect promotion to release work. Let application deployment and infrastructure changes remain related but distinguishable. A pull request can update both, yet the pipeline should show which actions affect infrastructure.
Add drift checks. Run scheduled comparisons and send findings to the team that owns the environment. Drift isn't always malicious. It may reflect an emergency fix, a provider change, or an undocumented decision. The important part is to bring reality back into the review process.
Practise recovery. Recreate a disposable environment from code and verify that required data recovery steps are documented separately. Code can rebuild resources, but it can't magically restore data that was never backed up.
The rhythm is simple: propose, inspect, approve, apply, observe, and correct. Good CI/CD makes that rhythm ordinary.
New Zealand's local conditions make repeatable infrastructure more than a tidy engineering preference. Government cloud policy requires agencies to use public cloud on a case-by-case basis after risk assessment, and the Cloud First policy says agencies must not invest in on-premises ICT infrastructure unless specific criteria are met or approval is granted (New Zealand Government cloud services guidance).
That policy applies to agencies, not every private startup. Still, it signals the direction of the market. Cloud decisions increasingly need evidence, risk controls, and consistent operation. Startups selling into government or regulated buyers should expect questions about repeatability, access, recovery, and audit trails.
The public sector's all-of-government infrastructure services also use standardised cloud and IaaS purchasing paths, covering services such as public cloud compute and storage, backup, replication, and utility compute (New Zealand infrastructure as a service). Standard purchasing and supplier variation make reusable, code-defined configurations especially useful.
Choose a contained starting point. Pick one service and one environment. Write down ownership, inputs, dependencies, and the changes that must stay manual.
Capture the foundation. Codify networking, identity boundaries, storage, monitoring, and tagging. Keep sensitive values in a secrets system.
Create a promotion pattern. Use the same modules across development, staging, and production. Put environment differences in reviewed configuration, not undocumented clicks.
Add resilience as a design input. New Zealand's infrastructure context includes a national pipeline valued at $237.1 billion, with $125.1 billion confirmed funded, as referenced in Te Waihanga's 2025 materials (RLB's New Zealand infrastructure and construction trends report). For digital operators, the lesson is local and practical: recovery plans need versioning, supplier awareness, and room for storms, outages, and policy change.
Test the awkward paths. Ask whether code can recreate an environment in another region or with another supplier. Check which assumptions depend on one provider, one person, or one physical location.
Australian startups face similar cloud and vendor questions, but regional requirements still differ. Don't copy a US architecture diagram and call it a resilience plan. For commercial readiness, a startup due diligence checklist can help founders connect technical controls with the wider business record buyers and investors inspect.
Infrastructure as code gives your team a durable memory. The repository records intent, reviews capture decisions, state connects code to reality, and the pipeline makes change repeatable.
Choose a tool your engineers can understand and maintain. Protect secrets and state. Review plans before applying them. Keep drift visible. For NZ startups, add one more question: can the platform recover when a supplier, region, person, or assumption fails?
Start this week with one non-production service. Write its infrastructure definition, run a plan, review the result, and document what the tool can't manage yet. That small exercise will reveal more than another hour of cloud-console clicking.
NZ Apps helps NZ and Australian founders find practical technology guidance and regional app and software companies, including partners who can support cloud automation and infrastructure work. Visit NZ Apps to explore the directory and connect your infrastructure plans with the right local expertise.
Add your NZ or Australian app or tech company to the NZ Apps directory and get discovered by founders and operators across the region.
Get ListedReach tech decision-makers across New Zealand and Australia. Sponsored and dofollow editorial links, permanent featured listings, and sponsored articles on a DA30+ .co.nz domain.
See Options