Terraform or Pulumi -- which should we use?

Terraform is the default choice for most infrastructure as code projects -- it has the largest community, the most provider coverage, and the most engineers who know it. HCL (Terraform's configuration language) is readable and purpose-built for declaring infrastructure. Pulumi is the better choice when your team wants to write infrastructure configuration in a general-purpose language (TypeScript, Python, Go) and take advantage of loops, conditionals, and abstractions that HCL handles awkwardly. For most projects, Terraform is the right starting point unless your team has a strong preference for writing infrastructure in their application language.

How do you migrate existing infrastructure into Terraform without rebuilding everything?

Existing resources created via the AWS or GCP console can be imported into Terraform state using terraform import. The process: write Terraform configuration that describes the existing resource, run terraform import to associate the configuration with the running resource, then run terraform plan to verify the configuration matches the actual state with no diff. Resources that show a diff need their configuration adjusted until plan shows no changes. The resource is now managed by Terraform without recreation. Complex existing infrastructure with many resources is imported incrementally, starting with the most critical resources.

What happens when someone makes a manual change to infrastructure after it's been imported to Terraform?

Manual changes (drift) are detected the next time terraform plan runs -- the plan will show the change required to bring the actual state back into alignment with the configured state. The team then decides: update the Terraform configuration to reflect the intended change (making it permanent) or run terraform apply to revert the manual change. Drift alerts can be automated by running terraform plan on a schedule and alerting when the plan is non-empty. Preventing drift entirely requires removing console access for production infrastructure changes.

Terraform or Pulumi -- which should we use?

Terraform is the default choice for most infrastructure as code projects -- it has the largest community, the most provider coverage, and the most engineers who know it. HCL (Terraform's configuration language) is readable and purpose-built for declaring infrastructure. Pulumi is the better choice when your team wants to write infrastructure configuration in a general-purpose language (TypeScript, Python, Go) and take advantage of loops, conditionals, and abstractions that HCL handles awkwardly. For most projects, Terraform is the right starting point unless your team has a strong preference for writing infrastructure in their application language.

How do you migrate existing infrastructure into Terraform without rebuilding everything?

Existing resources created via the AWS or GCP console can be imported into Terraform state using terraform import . The process: write Terraform configuration that describes the existing resource, run terraform import to associate the configuration with the running resource, then run terraform plan to verify the configuration matches the actual state with no diff. Resources that show a diff need their configuration adjusted until plan shows no changes. The resource is now managed by Terraform without recreation. Complex existing infrastructure with many resources is imported incrementally, starting with the most critical resources.

What happens when someone makes a manual change to infrastructure after it's been imported to Terraform?

Manual changes (drift) are detected the next time terraform plan runs -- the plan will show the change required to bring the actual state back into alignment with the configured state. The team then decides: update the Terraform configuration to reflect the intended change (making it permanent) or run terraform apply to revert the manual change. Drift alerts can be automated by running terraform plan on a schedule and alerting when the plan is non-empty. Preventing drift entirely requires removing console access for production infrastructure changes.

If your lead infrastructure engineer left today, could someone else reproduce your production environment from documentation -- or would they have to reverse-engineer it from what's running?
When you need a new environment that matches production, does it take days of manual setup or minutes from a Terraform plan?

Infrastructure that exists only in someone's head or a ClickOps history is infrastructure that cannot be reproduced, audited, or trusted.

Infrastructure as code (IaC) means your cloud resources -- servers, databases, networking, load balancers, DNS, IAM roles -- are defined in version-controlled configuration files rather than created manually through the AWS or GCP console. Every change goes through code review. Every environment is reproducible. Spinning up a new environment takes minutes rather than days of ClickOps.

We write and implement infrastructure as code using Terraform and Pulumi for AWS, GCP, and Azure. Greenfield IaC for new infrastructure, and migration of existing click-ops-created infrastructure into Terraform state without rebuilding resources from scratch.

Terraform modules for your entire infrastructure -- VPCs, EKS clusters, RDS databases, S3 buckets, IAM roles -- version-controlled in git
Identical dev, staging, and production environments created from the same configuration with environment-specific variables
Existing ClickOps infrastructure imported into Terraform state so it is managed going forward without recreation
Pull request workflow for infrastructure changes -- reviewed, planned, and applied through the same process as code

RaftLabs writes and implements infrastructure as code using Terraform and Pulumi on AWS, GCP, and Azure -- greenfield IaC for new infrastructure and migration of existing click-ops infrastructure into Terraform state. Reproducible environments, PR-based change workflow, and the operational practices that make IaC sustainable. Most projects deliver in 6 to 12 weeks at a fixed cost.

The problem with infrastructure created through the AWS or GCP console is that the console leaves no record of intent -- only a record of what currently exists. You can see the resource. You cannot see why it was configured that way, what it was created alongside, or what the safe change procedure is. When something breaks, the investigation starts from scratch. When you need a second environment, someone recreates the first one from memory and judgment calls.

Infrastructure as code makes the configuration the artifact. The git history shows who changed what and why. The pull request shows the proposed change before it's applied, with the Terraform plan output showing exactly which resources will be added, modified, or destroyed. A new environment is created by running the same configuration with different variable values. The infrastructure is no longer someone's undocumented knowledge -- it is a codebase with the same review and version control practices as application code.

What we build

Terraform module development

Reusable Terraform modules for your infrastructure components: VPC and networking, EKS or ECS clusters, RDS and Aurora databases, S3 and CloudFront, Route 53, IAM roles and policies. Modules parameterised for environment-specific differences -- instance sizes, replica counts, retention periods -- so the same module serves dev, staging, and production with different inputs rather than duplicated configuration.

State management and remote backends

Terraform state stored in S3 with DynamoDB locking (AWS) or GCS with locking (GCP) so concurrent applies don't corrupt state. State separated by environment so a staging change cannot accidentally affect production. State encryption at rest. State backup and recovery procedures so a corrupted or lost state file doesn't require rebuilding infrastructure from scratch.

Existing infrastructure import

Import of existing AWS or GCP resources created via the console into Terraform state without destroying and recreating them. Terraform configuration written to match the existing resource exactly, then imported so that terraform plan shows no diff. Drift detection configured to catch manual console changes after import is complete -- so the team knows immediately when someone bypasses the IaC process.

CI/CD integration for infrastructure

Terraform plan run automatically on every infrastructure pull request -- the plan output shows the exact changes that will be applied, posted as a PR comment for reviewer inspection. Terraform apply gated on PR approval so no infrastructure change reaches production without review. Separate pipeline stages for staging and production with explicit promotion gates. Plan and apply logs retained for audit.

Multi-environment configuration

Environment separation using Terraform workspaces or directory-per-environment patterns, depending on the degree of isolation required. Environment-specific variable files for instance sizes, replica counts, and feature flags. Shared module code with environment-specific inputs so drift between environments is explicit and intentional rather than accidental. Environment parity checks that alert when configurations diverge beyond the expected variables.

Secrets and sensitive variable management

Sensitive Terraform variables -- database passwords, API keys -- stored in AWS Secrets Manager, GCP Secret Manager, or HashiCorp Vault and referenced in Terraform rather than hardcoded in configuration files. Rotation procedures for managed secrets. Audit trail of which Terraform runs accessed which secrets and when. Prevention of sensitive values appearing in plan output or state files in plain text.

Have infrastructure that lives in someone's head?

Tell us your current cloud setup, how environments are provisioned today, and what breaks when you need to recreate something. We'll scope the IaC migration and give you a fixed cost.

Talk about your infrastructure project

DevOps as a Service -- full DevOps capability overview
CI/CD Pipeline Setup -- pipelines that apply your Terraform changes through code review
Kubernetes Infrastructure -- Kubernetes clusters provisioned and managed with Terraform
Cloud Monitoring and Observability -- monitoring the infrastructure your Terraform manages

Cloud Migration -- move existing infrastructure to cloud before bringing it under IaC
DevOps as a Service -- full DevOps engagement including IaC
Custom Software Development -- applications built with IaC-managed infrastructure from the start

Frequently asked questions

: Terraform is the default choice for most infrastructure as code projects -- it has the largest community, the most provider coverage, and the most engineers who know it. HCL (Terraform's configuration language) is readable and purpose-built for declaring infrastructure. Pulumi is the better choice when your team wants to write infrastructure configuration in a general-purpose language (TypeScript, Python, Go) and take advantage of loops, conditionals, and abstractions that HCL handles awkwardly. For most projects, Terraform is the right starting point unless your team has a strong preference for writing infrastructure in their application language.
: Existing resources created via the AWS or GCP console can be imported into Terraform state using terraform import. The process: write Terraform configuration that describes the existing resource, run terraform import to associate the configuration with the running resource, then run terraform plan to verify the configuration matches the actual state with no diff. Resources that show a diff need their configuration adjusted until plan shows no changes. The resource is now managed by Terraform without recreation. Complex existing infrastructure with many resources is imported incrementally, starting with the most critical resources.
: Manual changes (drift) are detected the next time terraform plan runs -- the plan will show the change required to bring the actual state back into alignment with the configured state. The team then decides: update the Terraform configuration to reflect the intended change (making it permanent) or run terraform apply to revert the manual change. Drift alerts can be automated by running terraform plan on a schedule and alerting when the plan is non-empty. Preventing drift entirely requires removing console access for production infrastructure changes.
: Writing Terraform for a new greenfield infrastructure typically runs $15,000 to $40,000 depending on the number of components and environments. Migrating existing click-ops infrastructure into Terraform state typically runs $20,000 to $60,000 depending on the complexity and size of the existing infrastructure. Fixed cost agreed before development starts.