Infrastructure as Code for Small Teams: Terraform, Pulumi, and SST

Infrastructure as Code (IaC) means defining your servers, databases, storage, and networking in code files that live in your repository. Instead of clicking through a cloud console, you write a description of what you need, and the tool provisions it.

This is not just for large companies with dedicated platform teams. Small teams benefit enormously from reproducible, version-controlled infrastructure.

Why IaC Matters for Small Teams

1. Reproducibility: Spin up identical staging and production environments
2. Documentation: Your infrastructure is documented by the code that creates it
3. Version control: Track every change, roll back mistakes
4. Collaboration: Review infrastructure changes in pull requests
5. Disaster recovery: Recreate your entire environment from code
6. Onboarding: New developers understand the infrastructure by reading code

Tool Comparison

Terraform (HashiCorp)

The standard IaC tool. Uses HCL (HashiCorp Configuration Language).

resource "aws_s3_bucket" "uploads" {
  bucket = "myapp-uploads"
}

resource "aws_dynamodb_table" "users" {
  name         = "users"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "userId"

  attribute {
    name = "userId"
    type = "S"
  }
}

Pros: Massive ecosystem, extensive cloud provider support, well-documented Cons: HCL is a domain-specific language (learning curve), state management can be tricky Best for: Multi-cloud, complex environments

Pulumi

Write infrastructure in your programming language (TypeScript, Python, Go, etc.).

import * as aws from '@pulumi/aws';

const bucket = new aws.s3.Bucket('uploads', {
  bucket: 'myapp-uploads',
});

const table = new aws.dynamodb.Table('users', {
  name: 'users',
  billingMode: 'PAY_PER_REQUEST',
  hashKey: 'userId',
  attributes: [{ name: 'userId', type: 'S' }],
});

Pros: Use TypeScript, IDE support, loops and conditionals are native Cons: Newer ecosystem, fewer examples Best for: Teams that prefer TypeScript over HCL

SST (Serverless Stack)

Opinionated framework for building serverless applications on AWS.

const api = new sst.aws.ApiGatewayV2('Api');
api.route('GET /users', 'src/handlers/list-users.handler');
api.route('POST /users', 'src/handlers/create-user.handler');

const bucket = new sst.aws.Bucket('Uploads');
const table = new sst.aws.Dynamo('Users', {
  fields: { userId: 'string' },
  primaryIndex: { hashKey: 'userId' },
});

Pros: Excellent developer experience, live Lambda development, built for serverless Cons: AWS-only, opinionated Best for: Serverless applications on AWS

CDKTF (CDK for Terraform)

Write Terraform infrastructure in TypeScript using the CDK.

Pros: Terraform's ecosystem + TypeScript's expressiveness Cons: Extra abstraction layer adds complexity Best for: Teams invested in Terraform but wanting TypeScript

Getting Started (Small Team Path)

Step 1: Define Your Scope

Do not try to codify everything at once. Start with:

• Database provisioning
• Storage buckets
• DNS records
• Environment variables and secrets

Step 2: Choose Your Tool

• AWS serverless: SST
• Multi-cloud or complex: Terraform
• TypeScript everything: Pulumi
• Already using Vercel/Railway: You may not need IaC at all

Step 3: Set Up State Management

Terraform and Pulumi need somewhere to store state:

• Terraform: Use Terraform Cloud (free for small teams) or S3 + DynamoDB
• Pulumi: Use Pulumi Cloud (free tier) or self-managed backends
• SST: Manages state through AWS CloudFormation

Step 4: CI/CD Integration

Run infrastructure changes through your CI/CD pipeline:

# GitHub Actions
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npx sst deploy --stage production
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

When You Do Not Need IaC

• Vercel/Netlify deployments: The platform manages infrastructure for you
• Managed databases (PlanetScale, Neon, Supabase): Provisioned through their dashboards
• Single environment: If you only have production and it rarely changes
• Prototype/MVP: Speed matters more than reproducibility at this stage

Common Mistakes

1. Over-engineering early: Do not codify infrastructure for a prototype
2. Ignoring state management: Corrupted state can destroy environments
3. Not using modules: Repeated code across environments is fragile
4. Manual changes: Avoid clicking through the console after adopting IaC
5. Missing locks: Concurrent changes can corrupt state

Our Approach

For most client projects, managed platforms like Vercel handle infrastructure automatically. When clients need custom infrastructure — serverless APIs, databases, storage, queues — we use SST or Pulumi depending on the requirements. Everything is version-controlled, reviewable, and reproducible.