DEV Community: Nicolas Balmaceda

I Got Tired of Reading thousands-line Terraform Plans, So I Built an Open-Source CLI to AI-Triage Them.

Nicolas Balmaceda — Fri, 10 Jul 2026 15:12:25 +0000

We’ve all been there. You open a Pull Request, scroll down to the CI/CD pipeline output to verify an infrastructure change, and you're hit with a massive, unreadable wall of red and green JSON text.

Finding the real structural risks or accidental resource destructions feels like searching for a needle in a haystack. Senior engineers spend hours squinting at logs just to make sure nothing breaks production.

I got completely tired of that workflow bottleneck, so I built a fix: tf-triage.

It’s a lightweight Go-based CLI tool designed to completely automate how teams audit infrastructure updates by converting messy raw plans into clean, actionable, markdown summaries directly inside your developer workflow.

The Core Concept

Instead of wasting your context window (and your budget) parsing irrelevant metadata, tf-triage intercepts the standard JSON payload, isolates the critical resource changes, and routes them to an LLM provider to draft a structural impact review.

Automating infrastructure validation at the PR Level

Here is why it's built differently:

🔒 100% Local & Private: Security teams hate sending cloud layouts to third-party endpoints. tf-triage integrates natively with local Ollama instances. You can run llama3.2 completely offline on your laptop for $0.
☁️ Ultra-Low Cost Cloud Routing: If you prefer cloud speeds without high token bills, it supports highly efficient endpoints like DeepSeek (V4) and Google Gemini using lightweight, raw HTTP clients.
🤖 Native CI/CD PR Comments: It doesn't just print output to the screen; it includes an automatic comment sub-command that auto-detects if it's running inside GitHub Actions, GitLab CI, or Bitbucket, posting the summary straight onto the PR.

Quickstart: Try It Locally in 30 Seconds

If you are on macOS or Linux, you can install the CLI tool instantly using Homebrew:

brew tap balmha/tap
brew install tf-triage

Running Natively Offline with Ollama

Make sure you have Ollama running on your machine with your model downloaded (ollama pull llama3.2), then pipe your plan directly into the binary:

terraform plan -json | tf-triage --provider ollama

The tool will parse the changes and automatically generate a beautifully formatted tf-triage-results.md file right inside your working directory.

Automating Your Pull Requests (CI/CD GitOps Flow)

The real magic happens when you drop this into your team's code review workflow. Because the tool natively reads standard runner environment variables, setting up automated PR comments requires exactly zero configuration.

Here is a minimalist GitHub Actions step configuration using DeepSeek to automatically review every infrastructure change:

- name: Triage Terraform Infrastructure Plan
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
    DEEPSEEK_API_KEY: ${{ secrets.DEEPSEEK_API_KEY }}
  run: |
    terraform plan -json > plan.json

    # 1. Analyze the plan and create the markdown report
    tf-triage --file plan.json --provider deepseek

    # 2. Automatically post the report as an interactive PR comment
    tf-triage comment

When the pipeline runs, tf-triage figures out the context, looks at the active pull request number, and drops a cleanly formatted security and resource impact review right into the comment feed. If you push a new commit, it intelligently updates its existing comment rather than spamming the thread.

What Do You Think?

I built this tool to scratch my own itch, keep infrastructure data locked down safely, and make code reviews vastly less tedious for platform teams.

The project is fully open-source and active. If you want to check out the Go source code, submit an issue, or help support the tool with a GitHub star, drop by the repository!

👉 [https://github.com/balmha/tf-triage]

The Self-Healing SDLC: Integrating GitHub Actions with AWS DevOps Agents

Nicolas Balmaceda — Wed, 18 Mar 2026 17:23:01 +0000

Beyond Traditional Automation

For years, we’ve treated the Software Development Life Cycle (SDLC) as a linear path: Code -> Build -> Test -> Deploy. We’ve perfected the art of "reusable workflows" in GitHub Actions to standardize how we build and deploy microservices to ECS.

But as of 2026, "standard" automation isn't enough. When a deployment succeeds but the service fails to communicate with a legacy monolith (like a host-based Kometsales instance), traditional CI/CD is blind.

Enter the AWS DevOps Agent (re:Invent 2025)

Announced at the end of 2025, the AWS DevOps Agent represents a shift toward "Agentic Operations." Unlike a standard monitor, this agent understands the context of your architecture.

The Hybrid Workflow: GitHub + AWS AI

The most robust strategy in 2026 isn't replacing GitHub Actions, but augmenting them.

GitHub Actions (The Orchestrator): Handles the heavy lifting of the build. It manages the multi-arch Docker builds, runs your unit tests, and triggers the deployment to AWS.
DevOps Agent (The Watcher): Once the Action completes, the Agent takes over. It monitors the "Blast Radius" of the change.

Technical Deep Dive: A Sample Reusable Workflow

To make this work at scale, you need a templated approach. Here is a snippet of a high-complexity GitHub Action that prepares an environment for an AI-monitored deployment:

name: "Deploy to ECS with Agentic Monitoring"

on:
  workflow_call:
    inputs:
      service_name:
        required: true
        type: string

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Code
        uses: actions/checkout@v4

      - name: Build and Push Multi-Arch
        run: |
          docker buildx build \
            --platform linux/amd64,linux/arm64 \
            -t ${{ secrets.ECR_REPO }}/${{ inputs.service_name }}:latest --push .

      - name: Update ECS Service
        run: |
          aws ecs update-service --cluster prod-cluster \
            --service ${{ inputs.service_name }} --force-new-deployment

      - name: Register Deployment with DevOps Agent
        run: |
          aws devops-guru start-deployment-analysis \
            --deployment-id ${{ github.sha }} \
            --resource-arn arn:aws:ecs:us-east-1:1234567890:service/${{ inputs.service_name }}

Solving the "Monolith Connection" Problem

A major pain point in microservice migrations is ensuring new containers can reach legacy services running on the host machine.

In this new SDLC model, if your GitHub Action deploys a service that cannot reach the host-based monolith, the AWS DevOps Agent can automatically identify the security group mismatch or the missing VPC route. Instead of a developer spending 4 hours debugging "Connection Refused," the Agent provides a root-cause analysis within seconds of the deployment finishing.

Why Open Source Matters Here

While the DevOps Agent is an AWS tool, the logic driving it relies on open standards. By using OpenTelemetry for your traces and standard GitHub Action triggers, you ensure that your "Agentic SDLC" isn't locked into a single vendor's black box. You retain the flexibility to swap components while reaping the benefits of AI-speed troubleshooting.

Summary

The future of DevOps isn't just about writing YAML; it's about closing the feedback loop between Deployment and Observation. By combining the modular power of GitHub Actions with the contextual intelligence of AWS's new agents, we're finally moving toward truly self-healing infrastructure.

How are you handling post-deployment monitoring in 2026? Are you still manually checking logs, or have you offloaded that to an agent? Let's discuss in the comments!

Why AWS Graviton5 Makes Multi-Arch Docker Builds Mandatory in 2026

Nicolas Balmaceda — Wed, 18 Mar 2026 17:16:02 +0000

The Graviton5 Shift: Beyond the Hype

At re:Invent 2025, AWS didn't just iterate; they flexed. The new Graviton5 processor (powering the M9g instances) brings a massive shift to the EC2 landscape. Built on a 3nm process, it packs 192 cores on a single die, effectively eliminating the NUMA (Non-Uniform Memory Access) latency issues that sometimes plagued earlier multi-socket ARM designs.

Key Benchmarks vs. Graviton4:

25% higher compute performance for general-purpose workloads.
5x larger L3 cache, which significantly reduces stalls for memory-intensive apps like Redis or Java-based microservices.
30% faster database performance (specifically reported by early testers like Atlassian for Jira).

But for us in DevOps, the biggest "hidden" feature is the Nitro Isolation Engine. This uses formal mathematical verification to prove that workloads are isolated at the hardware level—a massive win for security-conscious CI/CD environments.

The Infrastructure Challenge: Bridging the Arch Gap

If your team is still building exclusively for x86_64, you are essentially leaving money on the table. However, migrating isn't as simple as flipping a switch. You need a strategy that handles:

Multi-Arch Image Manifests: Ensuring a single tag works on both developer Macbooks (ARM), legacy CI runners (x86), and Graviton5 production nodes.
Legacy Communication: Handling scenarios where new microservices on ECS need to reach a monolithic service (like a legacy ERP or Kometsales) still running on the host machine.

Optimizing the Local Loop with Tilt

We’ve found that using Tilt for local docker-compose deployments is a game changer. It allows us to simulate the multi-arch environment locally. By adding a platform attribute to our compose files, we can test how our services behave before they hit the real M9g instances.

services:
  api-service:
    build: 
      context: ./api
      platforms:
        - "linux/amd64"
        - "linux/arm64"
    image: my-repo/api:latest
    # Force ARM locally if you're on a Mac/Graviton dev box
    platform: linux/arm64

Mastering the Multi-Arch Build

To support Graviton5, your GitHub Actions or Jenkins pipelines must move to docker buildx. Here is a professional-grade pattern for a multi-arch Dockerfile that handles architecture-specific packages:

# Use a multi-platform base image
FROM --platform=$BUILDPLATFORM node:20-alpine AS builder

ARG TARGETARCH
WORKDIR /app

# Conditional logic for architecture-specific dependencies
RUN if [ "$TARGETARCH" = "arm64" ]; then \
      apk add --no-cache libhook-arm-special; \
    else \
      apk add --no-cache libhook-x86-standard; \
    fi

COPY . .
RUN npm run build

FROM node:20-alpine
COPY --from=builder /app/dist ./dist
CMD ["node", "dist/main.js"]

The CI/CD Command

In your pipeline, you no longer run a simple build. You use the bake or buildx command to push a manifest list to ECR:

docker buildx build \
  --platform linux/amd64,linux/arm64 \
  --tag my-registry/service:v1.0.0 \
  --push .

Final Thoughts: The 2026 DevOps Reality

The era of "architecture-agnostic" engineering is over. With Graviton5 delivering 40% better price-performance than Intel counterparts, the question isn't if you'll migrate, but how fast your CI/CD can adapt.

By automating your image manifests and refining your local dev environment with tools like Tilt, you turn a hardware migration into a competitive advantage.

Have you started testing M9g instances yet? Drop a comment below with your initial performance findings!