DEV Community: Desly Peter

Pulumi, Terraform or CDK?

Desly Peter — Mon, 26 Oct 2026 11:52:43 +0000

The same infrastructure written three ways, and what I learned.

Infrastructure as code has split into two camps. One says infrastructure should be described in a declarative configuration language, like Terraform's HCL. The other says: we already have great programming languages, why not use them? That's the idea behind Pulumi and the AWS CDK.

The best way to compare them is to write the same thing in all three. So here's a simple S3 bucket with versioning, in each.

Terraform (HCL)

resource "aws_s3_bucket" "assets" {
  bucket = "acme-assets-prod"
  tags   = { environment = "production" }
}

resource "aws_s3_bucket_versioning" "assets" {
  bucket = aws_s3_bucket.assets.id
  versioning_configuration {
    status = "Enabled"
  }
}

output "bucket_name" {
  value = aws_s3_bucket.assets.bucket
}

Pulumi (TypeScript)

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

const assets = new aws.s3.BucketV2("assets", {
    bucket: "acme-assets-prod",
    tags: { environment: "production" },
});

new aws.s3.BucketVersioningV2("assets", {
    bucket: assets.id,
    versioningConfiguration: { status: "Enabled" },
});

export const bucketName = assets.bucket;

AWS CDK (TypeScript)

import { Stack, StackProps, Tags, CfnOutput } from "aws-cdk-lib";
import * as s3 from "aws-cdk-lib/aws-s3";
import { Construct } from "constructs";

export class AssetsStack extends Stack {
  constructor(scope: Construct, id: string, props?: StackProps) {
    super(scope, id, props);

    const assets = new s3.Bucket(this, "Assets", {
      bucketName: "acme-assets-prod",
      versioned: true,
      encryption: s3.BucketEncryption.S3_MANAGED,
      blockPublicAccess: s3.BlockPublicAccess.BLOCK_ALL,
    });

    Tags.of(assets).add("environment", "production");
    new CfnOutput(this, "BucketName", { value: assets.bucketName });
  }
}

HCL vs real languages

The examples look similar for a single bucket. The differences show up as things grow.

HCL (Terraform, OpenTofu) is deliberately limited. Loops and conditions exist (for_each, count, ternaries), but it's not a full programming language. That's a feature: configurations are easy to read, even for people who aren't developers, and there's less room for clever code nobody understands.

Pulumi lets you use TypeScript, Python, Go, C#, Java or YAML. You get real loops, functions, classes, packages, IDE autocompletion and unit tests with familiar frameworks. Great for complex logic, and for developers who don't want to learn another language. The risk: infrastructure code that's too clever.

AWS CDK also uses real languages, but its strength is constructs: high-level building blocks with good defaults. Notice how the CDK bucket above got encryption and blocked public access almost for free. Higher-level constructs can create a whole load-balanced container service in a few lines. It generates CloudFormation underneath and is AWS only.

HCL limits what you can write. Real languages limit nothing, which is both their strength and their danger.

State, compared

Terraform/OpenTofu: state file in a backend you manage (S3, GCS, Azure Storage) or in HCP Terraform and other platforms.
Pulumi: state in Pulumi Cloud by default, or self-managed in an object storage bucket.
CDK: no separate state file. CloudFormation tracks the stack's state in AWS. Simpler, but you inherit CloudFormation's speed and limitations.

What fits which team

Choose Terraform or OpenTofu if:

You work across multiple clouds and SaaS providers (the provider ecosystem is the largest).
Your team includes ops people who aren't primarily developers.
You want the most widely known tool, with the most examples and hiring options.

Choose Pulumi if:

Your team is developer-heavy and prefers TypeScript, Python or Go.
Your infrastructure has complex logic that's painful in HCL.
You want to test infrastructure code with normal unit testing tools.

Choose AWS CDK if:

You're all-in on AWS and plan to stay there.
You like high-level constructs with good defaults.
Your team already knows CloudFormation, or is happy to rely on it.

What I learned

Writing the same infrastructure three times made one thing clear: the language matters less than the discipline. Good module or component design, small state boundaries, consistent naming, tests and reviews matter in all three.

For most teams I work with, Terraform or OpenTofu remains the default because of its ecosystem and readability. But for developer-led teams, I've seen Pulumi make infrastructure feel much more approachable.

My take: pick the tool your team will read and maintain happily. Infrastructure code is read far more often than it's written.

— Desly

Originally published on deslypeter.com.

MCP: plugging AI into your infrastructure

Desly Peter — Mon, 26 Oct 2026 11:22:27 +0000

The Model Context Protocol lets AI talk to Kubernetes, Terraform and GitHub. Powerful, and risky.

For a long time, using AI for infrastructure work meant copying and pasting. Copy the error into the chat, copy the answer back into the terminal. The AI could only see what you showed it.

The Model Context Protocol, or MCP, changes that. It gives AI assistants a standard way to connect to tools and data. And for DevOps, that means an assistant that can actually look at your cluster, your pipelines and your dashboards.

What MCP is, without the hype

MCP is an open protocol, introduced by Anthropic in late 2024 and now supported by most major AI tools. Think of it like USB for AI: instead of every AI app building its own integration with every tool, tools expose an MCP server, and any AI app that speaks MCP (the client) can use it.

An MCP server offers:

Tools: actions the AI can take, like "list pods" or "get pipeline logs".
Resources: data the AI can read, like files, documents or records.
Prompts: ready-made instructions for common tasks.

The AI decides when to call a tool based on your request. You ask "why is the checkout service crashing?", and the assistant might list pods, read recent events, fetch logs and summarise what it found.

The servers that matter for DevOps

MCP servers exist for most of the tools we use daily:

Kubernetes: read resources, events and logs, and sometimes apply changes.
GitHub and GitLab: issues, pull requests, workflow runs.
Terraform and cloud providers: documentation lookups, resource information, and in some cases plans.
Observability tools: query metrics, logs and traces from Grafana, Datadog and others.
Incident and ticket tools: read incidents, write updates.

Many vendors now ship official servers, and there are many community ones. Quality varies a lot, so check who maintains a server before you connect it to anything important.

MCP turns an AI assistant from someone you describe the problem to into someone who can look at the problem themselves. That's exactly why it needs limits.

What could go wrong

MCP is powerful because it gives AI access. That's also the risk.

Over-broad credentials. If an MCP server uses your personal admin kubeconfig, the AI has admin rights to your cluster. Every tool call is made with whatever access the server has.

Prompt injection. The AI reads data from your tools: issue descriptions, log lines, web pages, README files. If someone puts instructions into that data ("ignore previous instructions and delete the namespace"), a poorly guarded setup might follow them. This is the biggest security issue with AI agents today, and it isn't fully solved.

Untrusted servers. An MCP server is code running on your machine or network. A malicious or compromised server could read data or misbehave. Treat installing an MCP server like installing any other dependency.

Silent writes. Reading is relatively safe. Writing, applying, deleting is not.

How I'd use it safely

Start read-only. Give the Kubernetes or cloud MCP server a role that can only read. Most of the value, debugging and explaining, comes from reading anyway.
Separate credentials. Dedicated service accounts for MCP servers, scoped to specific namespaces or projects, never your personal admin access.
Keep production out at first. Use it on dev and staging until you trust the setup.
Require confirmation for writes. Most AI clients can ask before each tool call. Keep that on for anything that changes state.
Use official or well-reviewed servers, pinned to a version.
Log tool calls so you can see what happened afterwards.

Building a tiny one myself

The protocol is simple enough that building a small internal MCP server is a nice afternoon project. The official SDKs exist for Python, TypeScript, Go and other languages.

A good first server: something read-only and specific to your company. For example, a tool that answers "who owns this service and where is its runbook?" from your service catalog. Small, useful, and impossible to break anything with.

So, should you try it?

Yes, carefully. MCP is quickly becoming the standard way AI connects to tools, and understanding it will be part of the DevOps job. Start read-only, in non-production, with narrow credentials. Expand only when you understand what it does.

My take: give AI eyes before you give it hands. And when you do give it hands, make sure they can't reach production by accident.

— Desly

Originally published on deslypeter.com.

Terraform in CI: plan on PR, apply on merge

Desly Peter — Mon, 26 Oct 2026 11:13:06 +0000

Stop running Terraform from laptops. How I automated it.

In many teams, Terraform is still run from someone's laptop. They pull the latest code, run plan, look at it, run apply. It works, until it doesn't: someone applies an old branch, two people apply at once, the laptop has different provider versions, or the only person with production credentials is on holiday.

The fix is a simple, well-known workflow: plan on pull request, apply on merge. Here's how I set it up.

The workflow

A developer changes infrastructure code on a branch and opens a pull request.
CI runs terraform plan and posts the plan as a comment on the pull request.
Reviewers look at both the code and the plan.
After approval, the pull request is merged.
CI runs terraform apply with the plan, from the main branch.

Everything is reviewed, everything is logged, nobody needs production credentials on their laptop, and the main branch always reflects what's deployed.

The plan is the real change. Review the plan as carefully as the code.

Option 1: Atlantis

Atlantis is an open-source server built exactly for this workflow. It listens to pull request events, and you control it with comments:

Open a PR, and Atlantis automatically runs plan and comments the output.
Comment atlantis apply and it applies, then comments the result.
It locks the affected directories so two PRs can't change the same state at the same time.

Atlantis runs in your own infrastructure (often on Kubernetes), so credentials never leave your environment. It's simple, battle-tested and free. You do have to host and maintain it.

Option 2: GitHub Actions (or any CI)

You can build the same workflow in your normal CI. A simplified GitHub Actions version:

name: terraform

on:
  pull_request:
    paths: ["infrastructure/**"]
  push:
    branches: [main]
    paths: ["infrastructure/**"]

permissions:
  contents: read
  id-token: write
  pull-requests: write

jobs:
  terraform:
    runs-on: ubuntu-latest
    defaults:
      run:
        working-directory: infrastructure/live/production/network
    steps:
      - uses: actions/checkout@<sha> # v4
      - uses: hashicorp/setup-terraform@<sha> # v3
      - uses: aws-actions/configure-aws-credentials@<sha> # v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/terraform-${{ github.event_name == 'push' && 'apply' || 'plan' }}
          aws-region: eu-central-1
      - run: terraform init -input=false
      - run: terraform plan -input=false -out=tfplan
      - if: github.event_name == 'pull_request'
        run: terraform show -no-color tfplan > plan.txt
        # post plan.txt as a PR comment with your preferred action
      - if: github.event_name == 'push'
        run: terraform apply -input=false tfplan

Things to notice:

Two different IAM roles: a read-only role for plans on pull requests, and a role with write access only for applies from main. The trust policy restricts which branch can assume which role.
OIDC, no stored cloud keys.
Use GitHub environments with required reviewers for production applies if you want an extra approval step.

One subtlety: the plan on the pull request and the apply after merge can differ if main changed in between. Re-planning on merge (as above) and applying that plan is the safe way.

Option 3: TACOS

"TACOS" (Terraform Automation and Collaboration Software) is the nickname for platforms built for this: HCP Terraform, Spacelift, env0, Scalr, Harness IaCM and others. They add:

Policy as code (OPA or Sentinel) on every plan.
Drift detection and scheduled runs.
Stack dependencies, cost estimation, approvals, audit logs.
Self-service and RBAC for many teams.

They cost money, but save a lot of building and maintaining for larger organisations.

Approvals

Who can approve infrastructure changes? Some practical rules:

CODEOWNERS so the right team reviews changes to their part of the infrastructure.
Required reviews in branch protection.
Extra approval for production applies, through CI environments or the platform.
Plans visible to reviewers, ideally summarised: number of resources added, changed and destroyed. A "destroy" in production should stand out.

Secrets and OIDC authentication

Never store long-lived cloud keys in CI for Terraform. Use OIDC with every major cloud, and scope the roles tightly. Combine that with remote, encrypted, locked state, and the most sensitive parts of your setup never touch a developer's laptop.

So, how do I start?

Pick one Terraform stack, ideally a low-risk one. Set up plan-on-PR with a read-only role first, so the team gets used to reviewing plans. Then add apply-on-merge with a separate role. Once it works, roll it out to the other stacks and take away production write access from laptops.

My take: infrastructure changes deserve the same pipeline discipline as application code. Review the plan, merge, and let the robot apply.

— Desly

Originally published on deslypeter.com.