DevOps & Infrastructure

In one line: Docker packages your app; Kubernetes runs it at scale; Terraform defines your cloud infrastructure as code; vaults store your secrets. None of this is required for a small project on Vercel — it's the layer big companies build below their hosting.

In plain English

"DevOps" is a fuzzy term covering everything from packaging your app (Docker) to running it across many machines (Kubernetes) to declaring your cloud setup in code (Terraform). Most of this is optional for small projects — your hosting platform handles it. You start to need these tools when you outgrow the platform tier and have to operate the underlying infrastructure yourself.

Containers

Tool	Notes
Docker	Universal containerization standard.
Podman	Daemonless alternative.

A container is a lightweight package containing your app and all its dependencies, runnable on any machine that has the container runtime installed. The result: "works on my machine" stops being a problem.

# Dockerfile — a recipe for a container
FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
CMD ["npm", "start"]

In English: Start from a lightweight Node 20 base image (a frozen filesystem snapshot from Docker Hub). Set the working directory, copy in just the lockfiles, install dependencies (cached separately so app-code changes don't bust this layer), then copy the rest of the source, build it, and define the start command. The result is a portable image that runs identically on any machine with Docker.

Orchestration

Tool	Notes
Kubernetes (K8s)	Dominant at scale.
Docker Compose	For local multi-container setups.
Nomad	Simpler K8s alternative; declining.

Kubernetes runs many containers across many machines. It handles scheduling, scaling, networking, load balancing, and self-healing. It's also genuinely complex — overkill for most teams under ~50 engineers.

Infrastructure as Code (IaC)

Tool	Notes
Terraform / OpenTofu	Most popular. OpenTofu is the open-source fork after Terraform's license change.
Pulumi	IaC in real programming languages (TS, Python, Go).
AWS CDK	AWS-specific, TS/Python.
SST	Modern serverless IaC built on AWS CDK.

# Terraform — describe infrastructure declaratively
resource "aws_s3_bucket" "uploads" {
  bucket = "my-app-uploads"
}

resource "aws_lambda_function" "api" {
  function_name = "my-api"
  handler       = "index.handler"
  runtime       = "nodejs20.x"
  filename      = "lambda.zip"
}

In English: Two resource blocks declare the desired state of your cloud: one S3 bucket and one Lambda function. Terraform is declarative — you describe what should exist, not the steps to create it. terraform apply reads the file, compares it to what already exists in your AWS account, and makes only the changes needed. Versioned in git, reviewed via PRs, the same way as code.

CI/CD

(Covered in detail in Chapter 3 Phase 9.) GitHub Actions dominates for most teams; CircleCI, GitLab CI, Buildkite are alternatives.

Secret management

Tool	Notes
HashiCorp Vault	Industry standard, self-host.
AWS Secrets Manager / Google Secret Manager / Azure Key Vault	Cloud-native.
Doppler / 1Password Secrets Automation	Modern, developer-friendly.

Highlight: most projects don't need any of this

You'll see senior engineers talk passionately about Kubernetes, Terraform, and service meshes. They're not wrong — at scale, these tools earn their complexity. But the average personal project or startup needs:

• Docker — useful even at small scale.
• Maybe Terraform — if your cloud setup grows complex.

Everything else (K8s, service meshes, custom Helm charts) is a solution looking for a problem at small scale. Resist adopting them prematurely.

Common mistakes

Where people commonly trip up

• Adopting Kubernetes "because we'll need it someday." K8s is a tax you pay every day — manifests, RBAC, ingress controllers, secrets management. Most teams under ~50 engineers should run on a managed platform (Vercel, Fly.io, Railway, Cloud Run) and reach for K8s when scaling pain is concrete.
• Bloated Docker images. FROM node:20 pulls in 1GB of OS you don't need. Use node:20-alpine or distroless, multi-stage builds (compile in one stage, copy artifacts into a slim runtime), and a .dockerignore that excludes node_modules and .git. Slim images deploy faster and have a smaller CVE surface.
• Click-ops in the cloud console, then "documenting" it in a wiki. Six months later, nobody can reproduce the setup and the staging environment drifts from prod. Define every resource in Terraform (or Pulumi/SST) from the start — even if it feels like overkill, future-you will thank present-you.
• Editing infrastructure manually after Terraform applied it. Now terraform plan shows diffs you didn't write, and the next apply may revert your manual change or destroy the resource. Either bring the change into code or import the existing state — never both manage and click.
• Committing secrets to git "just for now." They live in git history forever, get scraped within hours of any public push, and rotating them after a leak is painful. Use the platform's secret store (Vercel/Cloudflare env vars, Doppler, Vault) from line one.
• Skipping the .dockerignore. Without it, your node_modules and .next/ end up in the build context, blowing up image size and build time. Always pair .gitignore with a .dockerignore.

Page checkpoint

Checkpoint Quiz

Did DevOps tooling stick?

Required

What's next

→ Continue to Monitoring & Observability — the tools that tell you what's happening in production.