Infrastructure as code with Terraform and Bicep.
Your cloud defined in version controlled code, reviewed in pull requests and applied by a pipeline. Environments stay identical, drift gets caught, and rebuilding from scratch is a command, not a project.
Nobody remembers how production was built.
Console clicks
Resources were created by hand, so nobody can rebuild them or say why a setting is there.
Drifting environments
Staging and production look similar but differ in dozens of small ways that cause surprises.
Risky changes
Infrastructure changes go straight to production with no review and no plan output.
State nobody trusts
Terraform exists but the state is local, stale or edited by hand.
What the engagement covers.
- 01
Import what exists
Bring existing resources under Terraform or Bicep without recreating them or causing downtime.
- 02
Module structure
Reusable modules for networking, clusters, databases and identity with clear inputs and outputs.
- 03
Remote state
Locked, encrypted remote state per environment, with access limited to the pipeline.
- 04
Plan in pull requests
Every change shows its plan in the pull request and applies only after approval.
- 05
Drift detection
Scheduled plans that flag changes made outside of code before they cause an incident.
- 06
Policy checks
Static checks for insecure settings, missing tags and public exposure before anything is applied.
What you get at the end
- Terraform or Bicep code for your environments in your repository
- Reusable modules with documented inputs and outputs
- Remote, locked state per environment
- Pipeline that plans on pull request and applies on approval
- Scheduled drift detection with alerts
- A guide to making infrastructure changes safely
Tools I use
- Terraform
- Bicep
- Terragrunt
- Azure
- AWS
- GitHub Actions
- Azure DevOps
- tfsec
- Checkov
- Azure Storage state
- S3 + DynamoDB state
- Key Vault
Infrastructure as code questions.
- Terraform or Bicep?
- Terraform if you run more than one cloud or want the wider ecosystem. Bicep is a good choice for Azure only teams. Both work well.
- Will importing existing resources cause downtime?
- No. Import maps code onto what already exists. Changes are only applied after we have reviewed a clean plan.
- How is the price decided?
- After a short call I send a written scope and a fixed quote. No hourly surprises, and nothing starts until you have agreed the scope.
- Can developers make infrastructure changes?
- Yes, through pull requests. The pipeline shows the plan and a reviewer approves, so nobody needs cloud admin rights.
Let us put your cloud in code.
Tell me what you run and where it lives. Importing it without downtime is the first step.