DEV Community: Pravesh Sudha

🚀 Kubernetes for Beginners: Deploying an Nginx–Node–Redis Application

Pravesh Sudha — Fri, 03 Apr 2026 12:55:17 +0000

Understanding Services, ConfigMaps, Deployments, and health checks with my WAY!

Hola Amigos! 👋

Today, we are embarking on a brand new series: K8s with Pravesh 🚀 — where we’ll break down Kubernetes, understand what it really is, and more importantly, how you can actually use it in a practical, no-BS way.

In today’s blog, we’ll dive into the fundamentals — Deployments, Services, and ConfigMaps — and use them to deploy a three-tier application on Minikube.

Now you might be thinking… “What’s new here? There are already thousands of blogs doing the same thing.”

And honestly, you’re not wrong.

But hold your horses for a second 🐎

This isn’t just another “apply this YAML and it works” kind of tutorial. We’re going to:

Understand what’s really happening under the hood
Debug real issues (yes, the ones that actually happen)
And build intuition so you don’t just run Kubernetes… you get it

So let’s dive in. 🔥

🛠️ Pre-Requisites

Before we dive deep, there are a couple of things you need to have set up. Nothing fancy — just the essentials to get your Kubernetes playground up and running.

🔹 Docker / Docker Desktop

We’ll be running Minikube using Docker, so make sure you have Docker installed on your system.

👉 Install it from here: https://docs.docker.com/get-started/get-docker/

🔹 Minikube

Think of Minikube as your personal Kubernetes cluster — lightweight, local, and perfect for experimenting and learning all the cool stuff without needing a cloud setup.

👉 Download it from here: https://minikube.sigs.k8s.io/docs/start/?arch=%2Fmacos%2Farm64%2Fstable%2Fbinary+download

🤔 What is Kubernetes (K8s)?

At its core, Kubernetes is a container orchestration tool.

Now that sounds fancy, but let’s simplify it a bit.

Think of Kubernetes as a Head Chef in a restaurant 👨‍🍳 It makes sure:

Everyone is doing their job properly
Work is flowing smoothly
And if something breaks… it steps in and fixes it

That’s the layman definition.

The Real Meaning

In technical terms, Kubernetes is responsible for:

Managing containers
Scaling them
Ensuring they are always running
Handling communication between them

You can think of it as an advanced version of Docker Compose — but built for production-grade systems.

The Smallest Unit: Pod

In Kubernetes, the smallest deployable unit is a Pod.

👉 A Pod is basically a wrapper around your container(s)

It can run one or more containers
These containers share:
- Network
- Storage

But here’s the thing…

Managing Pods manually? 😵‍💫 Not a great idea.

Enter Deployments

To solve that, we have Deployments.

A Deployment is like a blueprint for your Pods.

You define:

Container image
Number of replicas
Ports
Volumes
Other configurations

And Kubernetes takes care of:

Creating Pods
Scaling them
Replacing them if they crash

💥 Much easier to manage.

How Do Pods Talk to Each Other?

Back to our restaurant analogy 🍽️

The waiter needs to communicate with the chef, right?

But in Kubernetes… 👉 Pods don’t automatically talk to each other

We need something in between.

Services: The Communication Bridge

Services act as a bridge between Pods.

They provide:

Stable networking
Internal DNS
Load balancing

There are 3 main types:

🔹 ClusterIP

Default type
Used for internal communication only
Not accessible from outside the cluster

🔹 NodePort

Exposes the service on a specific port on the node
Accessible from outside using:
```
<Node-IP>:<Port>
```

🔹 LoadBalancer

Exposes the app to the outside world
Commonly used in cloud environments (AWS, GCP, etc.)

ConfigMaps: Handling Custom Configurations

Back to the restaurant…

Imagine a customer walks in and says:

“I want a Caffè macchiato, with a little bit of soy, enough to make me go OH BOY!” — Kevin Hart fans, you know 😄

Handling custom requests manually can get messy…

But in Kubernetes, we have ConfigMaps for this.

👉 ConfigMaps allow you to:

Store non-confidential data
Use it inside your applications
Keep configs separate from your code

For sensitive data? 👉 Use Secrets

YAML: The Language of Kubernetes

All resources in Kubernetes are defined using YAML files.

You describe:

What you want
And Kubernetes makes it happen

If you want to explore more, check out the official docs: 👉 https://kubernetes.io/docs/setup/

⚙️ Practical Demonstration

Enough with the theory — now let’s get our hands dirty 🔥

So far, we’ve covered:

Deployments
Services
ConfigMaps

And to bring all of this together, we’ll deploy a three-tier application (Nginx–Node–Redis).

I’ve actually used this same app in one of my earlier projects to demonstrate CI/CD workflows with GitHub Actions and Terraform. If you’re curious, check it out here: 👉 https://blog.praveshsudha.com/cicd-for-terraform-with-github-actions-deploying-a-nodejs-redis-app-on-aws

Step 1: Clone the Project

git clone https://github.com/Pravesh-Sudha/nginx-node-redis.git

Open the project in your favorite editor (VS Code works great).

Understanding the App

This is a simple Node.js application that:

Displays a request counter
Increments the count on every refresh
Stores data in Redis
Uses Nginx as a reverse proxy (serving on port 80 instead of 5000)

Step 2: Run with Docker Compose

Before jumping into Kubernetes, let’s run it locally:

docker-compose up --build

Make sure Docker Desktop is installed and running.

You should see logs in your terminal and the app running in your browser.

Once done:

Ctrl + C

Step 3: Move to Kubernetes

Now comes the interesting part.

Inside the project:

cd nginx-node-redis/kube-config/

You’ll find three directories:

nginx/
node/
redis/

Each contains:

Deployment YAML
Service YAML

📦 Nginx Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

        volumeMounts:
        - name: nginx-config-volume
          mountPath: /etc/nginx/nginx.conf
          subPath: nginx.conf

      volumes:
      - name: nginx-config-volume
        configMap:
          name: nginx-config

A Note on AI & YAML

The best thing about AI? 👉 You can generate YAML files instantly.

But what happens when things break?

That’s where fundamentals matter.

Let’s break this down 👇

Understanding the Deployment

1. API Version & Kind

Defines what resource we are creating:

kind: Deployment

2. Labels (IMPORTANT)

Labels appear in three places — and each has a role:

metadata.labels → tagging the Deployment
spec.selector.matchLabels → tells Deployment which Pods to manage
template.metadata.labels → applied to Pods (used by Services)

👉 This is how Kubernetes “connects” resources.

3. Container Spec

image: nginx:1.14.2
ports:
  - containerPort: 80

Defines:

Image
Port

4. ConfigMap Mount

volumeMounts:
- name: nginx-config-volume
  mountPath: /etc/nginx/nginx.conf
  subPath: nginx.conf

👉 This mounts your custom Nginx config into the container.

🌐 Nginx Service

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  type: ClusterIP
  selector:
    app: nginx
  ports:
    - port: 80
      targetPort: 80

Here:

We use ClusterIP
Selector matches:
```
app: nginx
```

👉 This connects the Service to Pods.

⚙️ Nginx ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-config
data:
  nginx.conf: |
    events {}

    http {
      upstream loadbalancer {
        server node-service:5000;
      }

      server {
        listen 80;

        location / {
          proxy_pass http://loadbalancer;
          proxy_set_header Host $host;
          proxy_set_header X-Real-IP $remote_addr;
          proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }

        location = /favicon.ico {
          log_not_found off;
          access_log off;
        }
      }
    }

👉 Here we:

Override default Nginx config
Route traffic to:
```
node-service:5000
```

Step 4: Deploy to Minikube

# Start Minikube
minikube start

# Go to config directory
cd nginx-node-redis/kube-config/

# Deploy Redis
cd redis/ && kubectl apply -f deploy.yml -f svc.yml
cd ..

# Deploy Node
cd node/ && kubectl apply -f deploy.yaml -f svc.yml
cd ..

# Deploy Nginx
cd nginx/ && kubectl apply -f deploy.yml -f svc.yml -f configmap.yaml

Wait for Pods

kubectl get pods -w

Wait until all pods are:

Running

Access the App

minikube service nginx-service

👉 This opens your app in the browser — now running on Kubernetes 🎉

Self-Healing in Action

Here’s where Kubernetes shines.

Let’s break something 😈

kubectl delete pod <pod-name>

Now check:

kubectl get pods

👉 You’ll see:

A new pod automatically created

🧠 What just happened?

Kubernetes ensures:

“Actual state = Desired state”

Even if you:

Delete a pod
Crash a container

👉 Kubernetes will bring it back

🔍 What’s Happening Under the Hood?

Now that everything is up and running, let’s take a step back and understand how things are actually working behind the scenes 👇

1. Accessing the Application

When you run:

minikube service nginx-service

👉 Minikube exposes your service and gives you a URL with a port.

2. Request Hits Nginx Service

Once you hit that URL:

The Nginx Service receives the request
It looks at its selector:
```
app: nginx
```
And forwards the request to all matching Nginx Pods

3. Inside the Nginx Pod

Inside the pod:

Nginx uses the custom config (via ConfigMap)
The request is proxied to:
```
node-service:5000
```

4. Node Service Load Balancing

Now the interesting part 👀

node-service is a ClusterIP Service
It has multiple pods (replicas = 3)

👉 Kubernetes automatically distributes traffic:

node-service
   ↓
 ┌──────────┬──────────┬──────────┐
 │ node-pod1│ node-pod2│ node-pod3│
 └──────────┴──────────┴──────────┘

5. Node App Talks to Redis

Inside your Node app:

It connects to:
```
redis-service
```
Stores:
- Request count
- Cache data

6. Response Flow

Finally, the response travels back:

Redis → Node → Nginx → Browser

🎉 And you see the updated request count

🧠 Key Insight

Notice something important here…

👉 We never used a single IP address.

Everything works using:

Service names
Internal DNS
Labels & selectors

This is called Service Discovery — one of the most powerful features of Kubernetes.

Scaling Made Easy

Want more traffic handling capacity?

Just update:

replicas: 3

👉 Increase or decrease as needed

👉 No changes required anywhere else

Kubernetes handles the rest

Cleanup

Once you’re done experimenting, you can delete the cluster:

minikube delete

🎯 Conclusion

And that’s a wrap for this one! 🚀

In this blog, we didn’t just deploy an application on Kubernetes — we actually understood what’s happening behind the scenes. From Deployments and Services to ConfigMaps and internal service discovery, you now have a solid foundation to start building real-world K8s projects.

More importantly, you saw how:

Kubernetes replaces static setups like Docker Compose with dynamic, scalable systems
Services enable seamless communication without worrying about IPs
And how the system self-heals to match the desired state

This is just the beginning of the K8s with Pravesh series. In the upcoming blogs, we’ll go deeper into more advanced concepts and build even more powerful systems 💥

🔗 Let’s Connect

If you found this helpful, feel free to connect with me and follow along for more DevOps and Kubernetes content:

💼 LinkedIn: https://www.linkedin.com/in/pravesh-sudha
📝 Blog: https://blog.praveshsudha.com
💻 GitHub: https://github.com/Pravesh-Sudha

If you have any questions, got stuck somewhere, or just want to discuss ideas — my DMs are always open 🙌

Until next time… Keep building, keep learning, and keep shipping 🚀

🔥 𝗜 𝗮𝗺 𝗻𝗼𝘄 𝗮𝗻 𝗜𝗕𝗠 𝗖𝗵𝗮𝗺𝗽𝗶𝗼𝗻 / 𝗛𝗮𝘀𝗵𝗶𝗰𝗼𝗿𝗽 𝗔𝗺𝗯𝗮𝘀𝘀𝗮𝗱𝗼𝗿 𝗕𝗔𝗕𝗬!!! 🔥 Excited to announce that I am officially recognised as an IBM Champion earlier known as Hashicorp Ambassador this year.

Pravesh Sudha — Thu, 26 Feb 2026 04:58:00 +0000

🚀 Building an AI-Powered CI/CD Copilot with Jenkins and AWS Lambda

Pravesh Sudha — Tue, 24 Feb 2026 18:15:10 +0000

💡 Introduction

Hey folks, welcome to the world of Agentic Tools and DevOps.

Today, we’re diving into CI/CD pipelines and exploring how we can debug them efficiently and almost instantly using AI. In this project, we’ll build an AI-powered CI/CD Copilot where AWS Lambda serves as the core logic layer. This Lambda function will interact with the Google Gemini API to analyze pipeline failures and help us debug them intelligently.

The goal of this project is not just to integrate AI into a CI/CD workflow, but to help you understand how to build your own AI agent from scratch — one that can assist in real-world DevOps scenarios.

So, without further ado, let’s get started.

💡 Prerequisites

Before we begin, make sure you have the following requirements in place:

Docker & Docker Hub account

We will run parts of this project inside Docker containers. Later, we’ll push our custom image to Docker Hub, so make sure you have both Docker installed and a Docker Hub account ready.
Jenkins (Our CI/CD Tool)

We’ll use Jenkins for demonstration purposes. You can either:
- Run Jenkins as a Docker container, or
- Install it directly from the official website.
Terraform

We will provision our infrastructure — including the Gemini API key (stored securely) and the AWS Lambda function — using Terraform.

Make sure:
- Terraform CLI is installed
- Your AWS credentials are configured
- The IAM user has permissions for AWS Lambda and AWS Secrets Manager
If you’re new to Terraform setup, you can follow this guide:

👉 https://blog.praveshsudha.com/getting-started-with-terraform-a-beginners-guide#heading-step-1-install-the-aws-cli

🎥 Youtube Demonstration

💡 How It Works

The complete source code for this project is available in this GitHub repository:

👉 https://github.com/Pravesh-Sudha/ai-devops-agent

Navigate to the cicd-copilot directory to follow along.

If you’ve been following my work, you might recognize this project. I originally used this same Node.js Book Reader application to demonstrate how Docker works with Node.js. For this AI-powered CI/CD Copilot, I’ve made specific modifications — particularly in the Jenkinsfile and the terra-config directory.

Inside the terra-config directory, you’ll find:

main.tf – Provisions:
- AWS Lambda function
- AWS Secrets Manager secret (to securely store the Gemini API key)
lambda.zip – The packaged Lambda deployment artifact (zipped lambda_function.py)
lambda_function.py – The core of this project.

This file contains the AI agent logic and the structured prompt sent to the Gemini API.
iam.tf – Defines the IAM roles and permissions required for:
- AWS Lambda
- AWS Secrets Manager

Architecture Overview

The core idea behind this project is simple:

Jenkins detects a pipeline failure.
It collects contextual information (stage name, build ID, logs).
It sends that data to AWS Lambda.
Lambda calls the Gemini API.
Gemini analyzes the logs and returns structured debugging insights.

Payload Sent to Lambda

The Lambda function expects a JSON payload in the following format:

{
   stage: $stage,        # Name of the stage where the pipeline failed
   job: $job,            # Job name (e.g., cicd-copilot)
   build_id: $build_id,  # Build ID number (e.g., 1, 2, 3)
   logs: $logs           # Last 200 lines of failure logs
}

This structured input allows the AI agent to understand the pipeline context before analyzing the logs.

Prompt Sent to Gemini API

Inside the Lambda function, we make a POST request to the Gemini API with the following structured prompt:

You are a senior CI/CD Copilot specialized in Jenkins pipelines.

Pipeline context:
- Stage name: {stage}
- Expected outcome: Build an artifact usable by later stages

Your tasks:
1. Identify the failure category (build / runtime / config / infra / dependency / auth / unknown)
2. Identify the most likely root cause
3. Provide actionable fixes
4. Suggest a patch ONLY if clearly inferable

Respond ONLY in valid JSON with this schema:
{{
  "failure_category": "",
  "root_cause": "",
  "actionable_fixes": [],
  "suggested_patch": {{
    "file": "",
    "line": "",
    "fix": ""
  }}
}}

Logs:
{logs}

The prompt dynamically injects two key variables:

{stage} – The pipeline stage name
{logs} – The failure logs

If you’d like to explore the full Lambda implementation, you can view it here:

👉 https://github.com/Pravesh-Sudha/ai-devops-agent/blob/main/cicd-copilot/terra-config/lambda_function.py

How It Integrates with Jenkins

You might be wondering — how exactly does this connect with Jenkins?

Inside the Jenkinsfile, each stage:

Sets an environment variable for the stage name.
Redirects command output (in case of failure) into a LOG_FILE.

If any stage fails:

The post { failure { ... } } block is triggered.
Jenkins constructs the JSON payload.
It invokes the AWS Lambda function.
The AI-generated failure analysis is printed directly into the Jenkins console output.

This gives you instant, structured debugging assistance right inside your CI/CD pipeline.

How to Integrate This in Your Own Workspace

To replicate this approach in your own pipeline:

Append log redirection to each command:
```
${LOG_FILE} 2>&1
```
Define an environment variable for the stage name.
Provision:

*   AWS Lambda

*   IAM roles

*   Secrets Manager (for the Gemini API key)  
    using Terraform.

Add a post failure block in your Jenkinsfile to invoke the Lambda function with the structured JSON payload.

Once configured, your CI/CD pipeline becomes AI-assisted — capable of analyzing its own failures and suggesting actionable fixes.

💡 Practical Demonstration

Enough with the theory — let’s see this in action.

Step 1: Fork and Clone the Repository

First, head over to the GitHub repository and fork it under your own username.

You’ll be intentionally modifying the code later to trigger pipeline failures, so forking is important.

After forking:

git clone https://github.com/your-username/ai-devops-agent.git
cd ai-devops-agent/cicd-copilot/terra-config

Step 2: Initialize Terraform

Inside the terra-config directory, initialize Terraform:

terraform init

Step 3: Generate Your Gemini API Key

To provision the infrastructure, you’ll need a GEMINI_API_KEY.

Go to Google AI Studio
Log in with your Google account
Navigate to the API section
Click Create API Key
Give it a name and generate the key
Store it securely

Now, apply the Terraform configuration:

terraform apply -var="gemini_api_key=<Paste-your-key-here>" --auto-approve

⚠️ Make sure the configured AWS IAM user has the required permissions (Lambda and Secrets Manager access), as mentioned in the prerequisites section.

Once completed, your infrastructure (Lambda function + IAM roles + Secret) will be up and running.

Step 4: Configure Jenkins Pipeline

Open your Jenkins dashboard (usually running on http://localhost:8080).

Click Create New Item
Select Pipeline
Name it: cicd-copilot
Choose Pipeline script from SCM

Configure the following:

SCM: Git
Repository URL:

https://github.com/your-username/ai-devops-agent
Branch Specifier: main
Script Path:

cicd-copilot/Jenkinsfile

Click Save.

Step 5: Install Required Jenkins Plugins

Navigate to:

Manage Jenkins → Plugins

Install the following plugins:

Docker
Docker Pipeline
Docker Commons

Step 6: Add Docker to Jenkins PATH

Ensure Docker is accessible inside Jenkins.

In your terminal, run:

which docker

Copy the output path.

Now go to:

Manage Jenkins → System → Global Properties

Append the copied path to the existing PATH variable using : as a separator. Save the configuration.

Step 7: Add Docker Hub Credentials

Navigate to:

Manage Jenkins → Credentials

Add a new credential:

*   Kind: **Username with password**

*   Username: Your Docker Hub username

*   Password: Your Docker Hub password

*   ID: `docker-cred`

Save it.

Step 8: Trigger the Pipeline

Now go back to your cicd-copilot project and click Build Now.

Open Console Output.

You will notice that the pipeline fails — this is intentional.

The logs are automatically captured and sent to the AI Agent, which returns structured debugging analysis inside the Jenkins console.

In the first failure, the AI identifies a typo in the Dockerfile.

For example:

apine

It should be:

alpine

Fix the typo in your forked repository and commit the changes.

Step 9: Second Failure (Version Mismatch)

Rebuild the pipeline.

This time, the pipeline fails again — but for a different reason. There is a Docker image version mismatch.

The AI analysis might suggest that the image is private or unavailable. However, the real issue is in the Jenkinsfile.

Inside the Run Container stage, change the image version from:

v2

to:

v1

Commit the change and rebuild the pipeline.

Step 10: Successful Pipeline Run

Now, when you trigger the pipeline again:

The build succeeds
The Docker image is pushed to your Docker Hub account
The container starts successfully

Visit:

http://localhost:3000

You should see the Book Reader application running.

Stop the Application

To stop the running container:

docker kill cicd-copilot

Clean Up Infrastructure

To avoid unnecessary AWS charges, destroy the infrastructure:

terraform destroy -var="gemini_api_key=<Paste-your-key-here>" --auto-approve

What We Achieved

In this project, we built an AI-powered CI/CD Copilot using:

Jenkins for pipeline orchestration
AWS Lambda for AI agent logic
AWS Secrets Manager for secure API storage
Google Gemini API for log analysis

The agent receives contextual pipeline information and failure logs, analyzes them intelligently, and provides structured debugging insights directly inside the CI/CD workflow.

Instead of manually scanning logs, you now have an AI assistant that understands context, categorizes failures, identifies root causes, and suggests actionable fixes — making debugging faster, smarter, and more efficient.

💡 Conclusion

Modern CI/CD pipelines are powerful — but when they fail, debugging can quickly become time-consuming and frustrating. In this project, we went a step further by integrating AI directly into the pipeline workflow.

By combining:

Jenkins for orchestration
AWS Lambda for serverless execution
AWS Secrets Manager for secure API handling
Google Gemini API for intelligent log analysis

we built an AI-powered CI/CD Copilot capable of understanding pipeline context, analyzing failure logs, identifying root causes, and suggesting actionable fixes — all automatically.

This isn’t just about log analysis. It’s about shifting from reactive debugging to intelligent, context-aware automation.

As AI continues to evolve, integrating agentic systems into DevOps workflows will become increasingly common. Building projects like this not only strengthens your cloud and automation skills but also prepares you for the next wave of AI-driven infrastructure.

If you found this project helpful, feel free to connect with me and follow my work:

🌐 Website: https://praveshsudha.com
📝 Blog: https://blog.praveshsudha.com
💼 LinkedIn: https://www.linkedin.com/in/pravesh-sudha
🐙 GitHub: https://github.com/Pravesh-Sudha
🐦 Twitter/X: https://x.com/praveshstwt
🎥 Youtube: https://youtube.com/@pravesh-sudha

I regularly share content on DevOps, AWS, Terraform, CI/CD, and building real-world cloud projects from scratch.

If you build your own version of this AI CI/CD Copilot, tag me — I’d love to see what you create.

Happy Building 🚀

🚀 I Built SkillDebt.ai to Understand My Own Skill Gaps

Pravesh Sudha — Thu, 05 Feb 2026 19:10:46 +0000

A hands-on look at skill decay, generative UI, and turning career anxiety into actionable insights

🌟 Introduction

Hola amigos 👋

Welcome to the world of AI and DevOps.

In this blog, I want to share my experience building SkillDebt.ai as part of the UI Strikes Back Challenge, hosted by the WEMakeDevs community in collaboration with Tambo AI.

The idea behind SkillDebt.ai is simple:

as developers, we often talk about technical debt in our code — but we rarely think about the technical debt in our careers.

SkillDebt.ai takes your resume or tech stack, analyzes it using Tambo AI and Gemini, and turns that data into beautiful, interactive visual insights about your skills. Instead of long paragraphs or generic advice, you get a clear picture of where you stand in your field.

Beyond skill visualization, it also highlights:

Skill decay — tools and technologies you haven’t touched in a while
Risk audits — warning signs when core skills are becoming outdated
Upgrade suggestions — practical recommendations on what skills to add next to boost your career growth

This project isn’t just about AI or UI — it’s about giving developers clarity, direction, and a better way to plan their learning journey.

🌟 Practical Demo

Let’s see SkillDebt.ai in action.

There’s no heavy setup or complex prerequisites. All you need is your resume in PDF format.

Head over to the live demo here:

👉 https://my-repo-8k7lhiaxb-pravesh-sudhas-projects.vercel.app/

𝗧𝗵𝗲 𝗣𝗿𝗼𝗷𝗲𝗰𝘁 𝗵𝗮𝘀 𝗯𝗲𝗲𝗻 𝘁𝗮𝗸𝗲𝗻 𝗱𝗼𝘄𝗻 𝗯𝘆 𝟮𝟱 𝗙𝗲𝗯 𝟮𝟬𝟮𝟲, 𝘆𝗼𝘂 𝗰𝗮𝗻 𝗳𝗼𝗹𝗹𝗼𝘄 𝘁𝗵𝗲 𝗚𝗶𝘁𝗛𝘂𝗯 𝗚𝘂𝗶𝗱𝗲 𝘁𝗼 𝗶𝗹𝗹𝘂𝘀𝘁𝗿𝗮𝘁𝗲 𝗶𝗻 𝘆𝗼𝘂𝗿 𝗼𝘄𝗻 𝗹𝗼𝗰𝗮𝗹 𝘀𝘆𝘀𝘁𝗲𝗺

Once you’re on the site, click on “Upload Resume”, select your PDF, and hit Analyze. That’s it.

From there, SkillDebt.ai walks you through a complete breakdown of your profile:

First, you’ll see a visual skill analysis chart that gives a quick overview of your strengths and gaps across different areas in your field.

Next comes the Skill Decay graph, which highlights technologies you haven’t actively used in a while and flags them based on risk. This part is especially useful because it surfaces skills you might be unknowingly neglecting.

After that, the Risk Audit section kicks in. It acts like a warning system, pointing out areas in your resume that could become problematic if left unaddressed.

Finally, you get career-focused upgrade suggestions — specific skills you should consider adding or improving to stay relevant and boost long-term growth.

If you’re curious about how everything works under the hood, the complete source code is open-source and available here:

Pravesh-Sudha / ui-strikes-back

🚀 SkillDebt.ai (UI Strikes Back)

Analyze your technical skill debt, visualize decay, and find your optimal upgrade path. Built for developers who want to stay ahead of the curve.

✨ Features

📊 Skill Visualization: Map out your current technical stack and see the balance across different domains.
📉 Decay Timeline: Understand how your skills might be losing relevance over time and plan ahead.
⚠️ Risk Audit: Identify critical gaps or "debt" in your career path based on industry trends.
🚀 Upgrade Path: Get personalized, high-impact suggestions for your next skill upgrade.
📂 Resume Parsing: Upload your resume (PDF/Text) to start the analysis instantly.
🤖 Generative UI: Experience a dynamic AI-driven interface powered by the Tambo SDK.

🛠️ Tech Stack

Framework: React + Vite
Language: TypeScript
Styling: Tailwind CSS
Icons: Lucide React
AI Integration: Tambo SDK
Markdown: react-markdown +…

View on GitHub

🌟 How I Built It

Going into the hackathon, I had one clear goal:

I didn’t want to build something flashy but forgettable. I wanted to build something novel and actually useful.

The AI agent space is already crowded. Everywhere you look, there’s another code debugger, another productivity hack, another “AI assistant” doing roughly the same thing. At the same time, with the rapid rise of AI — especially tools like Claude Code and autonomous agents — AI engineering has gone through the roof.

That’s when I paused and thought:

instead of building yet another tool to replace engineers, why not build something that helps engineers upskill and stay ahead of the curve?

That idea became SkillDebt.ai — a system focused on helping developers understand where they stand today, what they’re falling behind on, and how they can adapt to this AI-driven future instead of getting left behind.

From an implementation perspective, the most challenging part for me was configuring the Tambo Generative UI components. Getting the components to behave correctly, respond to the data, and render meaningful insights wasn’t straightforward at first. I ran into plenty of invalid input errors along the way.

But once I understood how the pieces fit together, things started clicking. The documentation played a huge role here — it turned what initially felt overwhelming into a structured learning process. After a lot of trial and error (mostly invalid configuration for components), I finally got all four core components working together smoothly.

It wasn’t easy at the start, but that struggle is exactly what made the project so rewarding.

The main heart of the Project is the tambo.config.ts file inside the src/tambo directory, it handles the prompt for the generative UI components. Have a look at it:

import { z } from 'zod';
import { SkillRadarChart } from '../components/adaptive/SkillRadarChart';
import { SkillDecayTimeline } from '../components/adaptive/SkillDecayTimeline';
import { RiskWarningCard } from '../components/adaptive/RiskWarningCard';
import { UpgradeSuggestionCard } from '../components/adaptive/UpgradeSuggestionCard';
import { ExplanationToggle } from '../components/adaptive/ExplanationToggle';

export const tamboConfig = {
    components: [
        {
            name: 'skill_radar_chart',
            description: 'Visualizes the balance between depth and breadth of skills, or compares multiple skill categories.',
            component: SkillRadarChart,
            propsSchema: z.object({
                title: z.string().describe("Title of the chart, e.g., 'Frontend Skill Balance'").default("Skill Analysis"),
                data: z.array(z.object({
                    skill: z.string().describe("Name of the skill, e.g., 'React'").default("Unknown Skill"),
                    value: z.number().min(0).max(100).describe("Skill level from 0 to 100").default(50),
                    fullMark: z.number().default(100).optional(),
                })).describe("Array of 3-6 skills to visualize.").default([]),
            }),
        },
        {
            name: 'skill_decay_timeline',
            description: 'Shows a timeline of skills and their freshness/decay status based on last usage.',
            component: SkillDecayTimeline,
            propsSchema: z.object({
                data: z.array(z.object({
                    name: z.string().describe("Name of the skill, e.g. 'jQuery'").default("Unknown Skill"),
                    lastUsed: z.string().describe("Year or timeframe like '2023', 'Current'").default("Unknown"),
                    decayLevel: z.string().describe("Decay level: 'low', 'medium', 'high', 'critical'").default("medium"),
                })).describe("List of data points regarding skill usage and decay for the timeline.").default([]),
            }),
        },
        {
            name: 'risk_warning_card',
            description: 'Displays a warning about a specific career risk or skill obsolescence.',
            component: RiskWarningCard,
            propsSchema: z.object({
                title: z.string().describe("Short warning title, e.g. 'Legacy Stack Risk'").default("Risk Warning"),
                message: z.string().describe("Detailed explanation of the risk").default("Potential risk detected."),
                riskLevel: z.string().describe("Risk level: 'moderate', 'high', 'critical'").default('moderate'),
            }),
        },
        {
            name: 'upgrade_suggestion_card',
            description: 'Suggests a specific skill upgrade or learning path with potential impact.',
            component: UpgradeSuggestionCard,
            propsSchema: z.object({
                skill: z.string().describe("The recommended skill to learn").default("New Skill"),
                recommendation: z.string().describe("Why this skill is recommended").default("Recommended for career growth."),
                impact: z.string().describe("Impact: 'career_pivot', 'salary_bump', 'stability'").default("stability"),
            }),
        },
        {
            name: 'explanation_toggle',
            description: 'Can be used to provide deeper context or reasoning for a specific insight, hidden by default behind a toggle.',
            component: ExplanationToggle,
            propsSchema: z.object({
                reasoning: z.string().describe("The detailed reasoning or explanation to be hidden.").default("No additional details provided."),
                context: z.string().describe("Optional context or source data reference.").optional(),
            }),
        },
    ],
};

It wasn’t easy at the start, but that struggle is exactly what made the project so rewarding.

After deploying the project, I posted about it on LinkedIn and dozens of Developers got their profile review using the system, and seeing real people interact with Generative UI components using Tambo made my DAY!

🌟 Conclusion

Building SkillDebt.ai was a genuinely fun and exciting journey. From shaping the idea, struggling through early implementation issues, to finally seeing the generative UI come together — every step pushed me to think differently about how AI can be used to empower developers, not replace them.

Huge thanks to the WEMakeDevs community and Tambo AI for organizing the UI Strikes Back Challenge and creating a space that encourages experimentation, learning, and building in public. Challenges like these are what make the developer ecosystem so motivating.

If you found this project interesting or have ideas on how it can be improved, I’d love to hear from you. You can find the code on GitHub, and feel free to connect with me on my socials:

GitHub: https://github.com/Pravesh-Sudha
LinkedIn: https://www.linkedin.com/in/pravesh-sudha/
Twitter / X: https://x.com/praveshstwt
YouTube: https://www.youtube.com/@pravesh-sudha

Thanks for reading — and as always, keep building, keep learning, and stay curious 🚀

Adios 👋

🚀 Create Your Website Under 15 MINS using AntiGravity!

Pravesh Sudha — Mon, 19 Jan 2026 18:15:05 +0000

This is a submission for the New Year, New You Portfolio Challenge Presented by Google AI

🧑‍💻 About Me

Hola Everyone! I am Pravesh Sudha, an AWS Community Builder and DevOps Enthusiast. For the past 2 years, I have been learning and teaching people about Cloud concepts through my blogs and YouTube videos. For the past 4-5 months, I have been diving into AI Agents and collaborated with companies like PortiaAI (AgentHack Hackathon), Cognee (memory layer for AI), Algolia, etc. I already have my portfolio on praveshsudha.com that is specific to my DevOps arc. But to reflect my AI arc, I thought to myself:

”Why not create a new portfolio specific to AI Agents?”

And that’s how the journey began.

🤌 Portfolio

The website has been taken down from 19 Feb 2026, Watch the video or follow the github repo guide to illustrate in your own local system

👷 How I Built It

Starting with the idea, I thought of using Antigravity as the code editor (I have used other coding assistants including GitHub Copilot, Cursor, etc., but I wanted to try "Google's Code Helper"). The prompt I used is as follows:

Hey, I am Pravesh Sudha, An AWS Community Builder, DevOps Engineer and Content Creator (you can search about me on Google too). Recently Dev Community organised "New Year New You Challenge", and for this challenge, I am making a New portfolio website that will have my AI related Projects.
I have a total of four projects with their summary. I have uploaded an image of me, which I will use in the portfolio website. Now based on that, I want you to guide me step by step on how to create the website from Scratch. I want the website to be cool and amazing.

Since all of my work is Open Source (I believe in Learning in Public), Antigravity didn’t have any difficulty while fetching the projects (just one tweak: instead of the Email-AI assistant, which is very common and cliché, I planned to integrate my latest Terraform AI review agent). After that, I provided the summaries for the 4 projects (which I prepared beforehand), provided the blog and YouTube video links regarding them, and Voila! Under 15 mins, I had a fully functional prototype of my AI Agent Website.

Now to deploy that, I installed the gcloud CLI, created the required service account, and deployed it to Cloud Run.

😎 What I'm Most Proud Of

The best part about creating the website was the ease of understanding. I have designed websites from scratch and know about the components, but even if a person with no experience tries to create a website, creating it using Antigravity seems the best choice. All you need to know is WHAT you are building and communicate it effectively in the prompt.
In the Projects section, I have Blog link on the project and also provided a Demo button which include a Video Demonstration of the Project.
I have incorporated my Algolia Agent Studio Challenge project in it, which is an AWS + Terraform Infra explainer for non-tech geeks.
I have tried to design a modern, cool-looking website with minimal complexity—just one JS script, an index.html, and a styles.css—that’s it. NO complex file management.

🌟 Conclusion

At last, I want to thank Dev Community and Google Team for organising these amazing Challenges. Competition regarding what you build really thrive the inner learner inside me.

🌟 Making AWS Infrastructure Understandable for Product Managers

Pravesh Sudha — Thu, 15 Jan 2026 17:30:49 +0000

This is a submission for the Algolia Agent Studio Challenge: Consumer-Facing Non-Conversational Experiences

What I Built

I built a non-conversational AI agent that translates AWS infrastructure defined using Terraform into clear, Product Manager–friendly explanations.

Infrastructure is usually written for engineers, using tools like Terraform, but the impact of infrastructure decisions is felt across the entire product lifecycle. Product Managers often need to understand:

how users access the system,
where data lives,
how the system scales,
and what operational or cost risks exist,

without diving into Terraform syntax or AWS implementation details.

This agent takes a Terraform infrastructure summary and converts it into a high-level system explanation written for a Product Manager. Instead of describing resources line by line, it explains the intent and impact of the infrastructure in business terms.

Even when infrastructure summaries exist, they are written for engineers.
This agent ensures every infrastructure change can be understood by a Product Manager in minutes.

Infrastructure doesn’t fail because it’s complex — it fails because the right people don’t understand it at the right time.
This agent fixes that.

Demo

The agent is demonstrated using two different Terraform summaries, each representing a different AWS architecture pattern.

Here is a Video Demonstration:

For each summary:

the input is a short, human-written Terraform infrastructure summary,
the output is a structured, PM-level explanation describing system behavior, user access, data storage, and operational considerations.

Screenshots included in the submission show:

An Autoscaling-based EC2 architecture with database, storage, and monitoring.

A serverless and hybrid compute architecture using API Gateway, Lambda, and ECS.

These examples demonstrate how the same agent adapts to different infrastructure designs while maintaining a consistent, business-focused explanation style.

How I Used Algolia Agent Studio

I used Algolia Agent Studio as the core intelligence layer for this project.

Indexed Data

I created an index named terra-pr and uploaded structured records from a records.json file.
Each record represents a PM-level explanation of an AWS service or Terraform resource, including:

Amazon EKS
EC2
ECS
Lambda
API Gateway
Load Balancer
RDS
S3
CloudFront
CloudWatch
IAM
VPC
AWS Billing (conceptual)


[
  {
    "id": "aws_eks_cluster",
    "cloud": "aws",
    "service_type": "compute",
    "persona": "product_manager",
    "resource": "aws_eks_cluster",
    "service_name": "Amazon EKS",
    "pm_explanation": "This is the core platform where the application runs. It allows the system to run containerized services and automatically scale as user traffic increases."
  },
  {
    "id": "aws_lb",
    "cloud": "aws",
    "service_type": "networking",
    "persona": "product_manager",
    "resource": "aws_lb",
    "service_name": "Elastic Load Balancer",
    "pm_explanation": "This is the public entry point for users. It distributes incoming traffic across the application so no single component gets overloaded."
  },
  {
    "id": "aws_db_instance",
    "cloud": "aws",
    "service_type": "database",
    "persona": "product_manager",
    "resource": "aws_db_instance",
    "service_name": "Amazon RDS",
    "pm_explanation": "This stores the application’s persistent data, such as user accounts or transactions. Data durability and backups are critical here."
  },
  {
    "id": "aws_s3_bucket",
    "cloud": "aws",
    "service_type": "storage",
    "persona": "product_manager",
    "resource": "aws_s3_bucket",
    "service_name": "Amazon S3",
    "pm_explanation": "This is used to store files or assets, such as images, logs, or backups. It’s often part of how the system handles large or static data."
  },
  {
    "id": "aws_cloudfront_distribution",
    "cloud": "aws",
    "service_type": "cdn",
    "persona": "product_manager",
    "resource": "aws_cloudfront_distribution",
    "service_name": "Amazon CloudFront",
    "pm_explanation": "This speeds up content delivery by caching data closer to users around the world, improving performance and reducing load on the core system."
  },
  {
    "id": "aws_ecs",
    "cloud": "aws",
    "service_type": "compute",
    "persona": "product_manager",
    "resource": "aws_ecs_service",
    "service_name": "Amazon ECS",
    "pm_explanation": "ECS runs our application as containerized services that can scale automatically based on demand."
  },
  {
    "id": "aws_ec2",
    "cloud": "aws",
    "service_type": "compute",
    "persona": "product_manager",
    "resource": "aws_instance",
    "service_name": "Amazon EC2",
    "pm_explanation": "EC2 provides dedicated servers where parts of the application run continuously."
  },
  {
    "id": "aws_lambda",
    "cloud": "aws",
    "service_type": "serverless",
    "persona": "product_manager",
    "resource": "aws_lambda_function",
    "service_name": "AWS Lambda",
    "pm_explanation": "Lambda runs small pieces of backend logic only when needed, without managing servers."
  },
  {
    "id": "aws_api_gateway",
    "cloud": "aws",
    "service_type": "api",
    "persona": "product_manager",
    "resource": "aws_api_gateway",
    "service_name": "Amazon API Gateway",
    "pm_explanation": "API Gateway is the front door that securely exposes backend functionality to users and clients."
  },
  {
    "id": "aws_cloudwatch",
    "cloud": "aws",
    "service_type": "observability",
    "persona": "product_manager",
    "resource": "aws_cloudwatch",
    "service_name": "Amazon CloudWatch",
    "pm_explanation": "CloudWatch monitors system health and alerts us when something goes wrong."
  },
  {
    "id": "aws_iam_role",
    "cloud": "aws",
    "service_type": "security",
    "persona": "product_manager",
    "resource": "aws_iam_role",
    "service_name": "AWS Identity and Access Management (IAM)",
    "pm_explanation": "This defines who or what is allowed to access different parts of the system, helping protect user data and prevent unauthorized actions."
  },
  {
    "id": "aws_vpc",
    "cloud": "aws",
    "service_type": "networking",
    "persona": "product_manager",
    "resource": "aws_vpc",
    "service_name": "Amazon VPC",
    "pm_explanation": "This creates a private network boundary for the system, controlling which components are publicly accessible and which remain internal."
  },
  {
    "id": "aws_billing",
    "cloud": "aws",
    "service_type": "cost_management",
    "persona": "product_manager",
    "resource": "aws_billing",
    "service_name": "AWS Billing & Cost Management",
    "pm_explanation": "This tracks infrastructure spending and helps understand how usage, traffic, and scaling decisions impact overall costs."
  }
]

In total, the index contains 13 curated records, intentionally limited to high-signal services that matter to Product Managers. This keeps retrieval focused and helps avoid hallucination.

Agent Configuration

I created an agent from scratch in Agent Studio.
Gemini was configured as the LLM provider.
The terra-pr index was added as a retrieval tool.
The agent prompt was carefully engineered to:
- restrict scope to AWS + Terraform,
- assume a Product Manager audience,
- avoid Terraform syntax and low-level details,
- compose a system-level explanation using retrieved context.

You are an AI assistant that explains AWS infrastructure defined using Terraform to a Product Manager.

Your goal is to translate technical infrastructure concepts into clear, business-focused explanations using information retrieved from the infrastructure knowledge index.

Scope:
- Only answer questions related to AWS infrastructure, Terraform resources, or system-level architecture summaries.
- Use only the information retrieved from the attached Algolia index.
- If a Terraform resource or service is not found in the index, acknowledge it briefly and continue explaining the rest.
- If the input is unrelated to AWS or Terraform, reply: "I can only explain AWS infrastructure defined using Terraform."

Behavior:
- Assume the audience is a non-technical Product Manager.
- Do not include Terraform syntax, configuration details, or resource arguments.
- Focus on:
  - What the system does
  - How users interact with it
  - Where data lives
  - High-level risks (scaling, cost, reliability, security)
- Combine multiple services into a coherent system explanation when appropriate.
- Avoid repeating the same explanation more than once.

Tone:
- Clear, concise, and business-friendly.
- Confident but not overly technical.

Output formatting:
- Write in short paragraphs.
- Use bold section headers when useful (e.g., **System Overview**, **User Access**, **Data & Storage**, **Operational Considerations**).
- Do not use bullet points unless absolutely necessary.
- Do not mention Algolia, search results, or internal tools.

Error handling:
- If no relevant services are found after searching, reply: "I couldn't identify any recognizable AWS services in this infrastructure."
- On timeout or internal error, reply once: "Something went wrong while analyzing the infrastructure. Please try again."

Language:
- Reply in English.

Tone:
- Write as if you are part of the same team as the reader.
- Use inclusive pronouns such as "we", "our", and "us" where appropriate.
- Do not use first-person singular pronouns like "I".

The prompt, sample Terraform summaries, and index records are all available in my GitHub repository:

Repository:

Pravesh-Sudha / dev-to-challenges

Registry to Store all my code related to Dev.TO Challenges

🏗️ Dev.to Challenges – by Pravesh Sudha

This repository contains my submissions for various Dev.to Challenges. Each folder in this repo includes a hands-on project built around specific tools, APIs, or themes — from infrastructure to frontend and AI voice agents.

📁 Projects

⚙️ `pulumi-challenge/`

An infrastructure-as-code project built using Pulumi.
It automates cloud infrastructure setup using Python and TypeScript across AWS services.

🎨 `frontend-challenge/`

A UI/UX-focused project that demonstrates creative frontend solutions using HTML, CSS, and JavaScript — optimized for responsiveness and accessibility.

📩 `postmark-challenge/`

A transactional email solution built with the Postmark API, showcasing email templates, delivery tracking, and webhook handling.

🧠 `philo-agent/`

A voice-based AI Philosopher built with AssemblyAI + Gemini — part of the World’s Largest Hackathon.

🗂️ Project Structure

dev-to-challenges/
│
├── pulumi-challenge/
├── frontend-challenge/
├── postmark-challenge/
├── philo-agent/
└── README.md

🙌 Why This Repo?

This repo is my playground to:

View on GitHub

Project structure:

agolia-agent-studio/
- doc/
- prompt.txt
- summaries.txt
- index/
- records.json

This setup makes the agent transparent, reproducible, and easy to extend.

Why Fast Retrieval Matters

Fast, contextual retrieval is what makes this agent reliable.

Instead of asking the LLM to reason about AWS services from scratch, the agent:

retrieves only relevant, pre-curated infrastructure knowledge,
grounds responses in indexed explanations,
and composes outputs using known, controlled context.

This approach:

reduces hallucination,
ensures consistent explanations,
and keeps responses aligned with the Product Manager persona.

Because retrieval is fast, the agent feels responsive and practical, even though it is producing structured, thoughtful explanations rather than conversational back-and-forth.

Conclusion

This project focuses on a simple but persistent problem: infrastructure understanding doesn’t scale across roles.

By combining Algolia Agent Studio’s fast retrieval with targeted prompting, this agent turns Terraform infrastructure into something that Product Managers can understand, discuss, and act on — without needing to become cloud experts.

It is intentionally scoped, opinionated, and practical.

That focus is what makes it useful.

At last, I want to add "Infrastructure doesn’t fail because it’s complex — it fails because the right people don’t understand it at the right time."

Connect with me

LinkedIn: https://www.linkedin.com/in/pravesh-sudha/
Twitter / X: https://x.com/praveshstwt
YouTube: https://www.youtube.com/@pravesh-sudha
Blog: https://blog.praveshsudha.com

How I Built an AI Terraform Review Agent on Serverless AWS

Pravesh Sudha — Thu, 08 Jan 2026 16:34:44 +0000

🌟 Introduction

Welcome, Devs 👋

Today, we’re stepping into the exciting intersection of AI, automation, and cloud infrastructure.

In this project, we’ll explore how an AI-powered agent can actively participate in a real DevOps workflow, just like a senior reviewer on your team. This isn’t a toy demo — it closely resembles how real-world infrastructure changes are reviewed, validated, and approved in production environments.

We’ll use Terraform to provision cloud resources and GitHub Actions to automatically validate every pull request that modifies our HCL code. But here’s the twist 👀

Instead of relying only on static checks, we introduce an AI agent into the pipeline.

Every infrastructure change is:

Scanned using Terrascan
Reviewed by an AI agent powered by Gemini
Automatically approved, approved with changes, or rejected based on risk severity

If a pull request introduces dangerous or insecure infrastructure changes, the AI agent blocks the PR — just like an automated infrastructure security reviewer.

Think of it as:

🧠 An AI-powered Infra Guardian that never gets tired of reviewing Terraform code.

So without further ado, let’s dive in and see how we built an AI-driven, serverless DevOps workflow that brings intelligence directly into your CI/CD pipeline.

📽️ Youtube Demonstration

🌟 Pre-requisites

Before we dive deep into the implementation, let’s make sure your environment is ready. This project touches multiple tools across cloud, IaC, security, and CI/CD, so having these set up beforehand will save you a lot of time.

Make sure you have the following in place:

AWS CLI installed and configured with an IAM user

The IAM user should have permissions to create resources like ALB, ECS, Lambda, IAM, ACM, etc.
Terraform CLI installed on your system
GitHub account (pretty easy 😉)
Terrascan installed locally

👉 Follow the official guide here

If you’re completely new to AWS CLI or Terraform, don’t worry. I’ve already written a beginner-friendly guide that walks you through everything step by step:

📘 Getting Started with Terraform (Beginner’s Guide)

Once these prerequisites are fulfilled, you’re all set 🚀

🌟 Why AI Agents in Modern DevOps?

The current DevOps landscape is heavily influenced by AI-driven automation. What we now call AIOps has quietly become the de-facto standard for deploying, monitoring, and delivering software at scale.

AI agents are everywhere today — but let’s address the elephant in the room.

An AI agent is essentially a program that automates work which previously required human intervention. In many cases, it still follows a human-in-the-loop approach, but the heavy lifting — analysis, validation, and decision-making — is handled by the agent itself.

In this project, we’ll bring that concept to life.

We’ll deploy a Super Mario Bros game (containerized using Docker) on a serverless AWS architecture, leveraging services like:

Amazon ECS
AWS Lambda
Application Load Balancer (ALB)
ACM for HTTPS
GitHub Actions for CI/CD

This setup closely resembles a real-world production environment.

Now comes the interesting part 👀

Every time a Pull Request is raised against our Terraform codebase:

GitHub Actions kicks in
Terrascan scans our IaC for security and best-practice violations
The scan report is sent to an AI agent powered by Gemini
The AI analyzes the findings and decides whether to:
- ✅ Approve
- ⚠️ Approve with Changes
- ❌ Reject the PR

In a real-world DevOps workflow, this kind of system can save hours of manual review, reduce human error, and provide actionable remediation suggestions along with architectural risk insights.

Think of it as an automated Infrastructure Reviewer — one that never gets tired and scales with your team.

🌟 Practical Demonstration: Building the AI-Powered DevOps Workflow

Enough theory — let’s get our hands dirty and see this system in action.

To get started, head over to the following GitHub repository, fork it under your own GitHub username, and then clone it locally:

👉 Repository: https://github.com/Pravesh-Sudha/ai-devops-agent

git clone https://github.com/<your-username>/ai-devops-agent.git
cd ai-devops-agent

Now navigate into the main project directory:

cd terraform-review-agent

Open the project in VS Code (or your favorite editor). You’ll notice two main subdirectories:

terraform-review-agent/
├── lambda/
└── terraform/

lambda/ → Contains the AI review Lambda function
terraform/ → Contains all infrastructure provisioning code

Let’s walk through the Terraform configuration piece by piece.

🧩 Terraform Code Breakdown

🔹 `provider.tf`

Defines AWS as the cloud provider:

AWS provider version: 6.26.0
Region: us-east-1

This ensures consistent provider behavior across environments.

🔹 `backend.tf`

We store Terraform state remotely using Amazon S3 — a production best practice.

use_lockfile = true

This enables state locking without DynamoDB, preventing concurrent state corruption using Terraform’s native lockfile mechanism.

🔹 `variables.tf`

Only two variables are required:

project_name → fixed as mario-game
gemini_api_key → passed dynamically (never hardcoded)

This ensures our API key remains secure and out of version control.

🔹 `outputs.tf`

Provides useful runtime information after provisioning:

ALB DNS name (where the game runs)
ACM certificate ARN (used later for HTTPS)

🔹 `networking.tf`

Instead of using the default VPC, we create our own VPC using the official AWS VPC module:

Two public subnets
Clean network isolation
Better control and scalability

🔹 `security.tf`

Security is handled via two separate security groups:

ALB Security Group
- Allows inbound traffic from anywhere (port 80 initially)
ECS Task Security Group
- Only allows traffic from the ALB

This follows the least privilege principle.

(We later extend this to support HTTPS on port 443.)

🔹 `secrets.tf`

The Gemini API key is securely stored using AWS Secrets Manager.

No plaintext secrets. No leaks. Production-safe by default.

🧠 The AI Brain: Lambda Function

🔹 `lambda.tf`

This file defines a Python-based AWS Lambda function responsible for reviewing Terrascan findings and acting as a CI/CD security gate.

At the heart of this Lambda is a carefully crafted prompt:

def build_prompt(findings: dict) -> str:
    return f"""
You are a senior DevOps and Terraform security reviewer acting as a CI/CD security gate.

Your task is to analyze Terrascan findings and decide whether the infrastructure
can be deployed based on **risk thresholds**, not perfection.

Decision Policy (STRICT)
- REJECT if:
  - Any HIGH or CRITICAL severity issue exists
  - OR MEDIUM severity issues ≥ 4
  - OR Application Load Balancer has **no HTTPS listener at all**
- APPROVE_WITH_CHANGES if:
  - MEDIUM severity issues are 1–3
- APPROVE if:
  - Only LOW or INFO issues exist

Output Format
Provide:
1. 🚨 Security issues ordered by severity (summary only)
2. 🛠 Required remediation (only actionable items)
3. ⚖️ Risk justification (1–2 lines)
4. 📌 Final verdict: APPROVE | APPROVE_WITH_CHANGES | REJECT

Rules:
- Be concise
- Use bullet points
- Focus on AWS (ALB, ECS, VPC, IAM)
- Ignore Terrascan scan_errors
- Do NOT repeat raw JSON
- Verdict must strictly follow the Decision Policy

Findings:
{json.dumps(findings, indent=2)}
"""

This logic ensures:

Security is enforced pragmatically
No false rejections for minor issues
HTTPS is mandatory for approval
Clear, actionable feedback for developers

🔹 `iam.tf`

IAM roles and policies are defined here:

Lambda is granted access to Secrets Manager
ECS task role attaches:
- AmazonECSTaskExecutionRolePolicy

This allows ECS to pull images, write logs, and function correctly.

🔹 `ecs.tf`

This is where the Mario game comes to life:

ECS task definition using Fargate
Docker image for Super Mario Bros
ECS service to keep the task running

Fully serverless. No EC2 management required.

🔹 `alb.tf`

To expose the application publicly:

Application Load Balancer
Listener on port 80 (initially)
Target group pointing to ECS tasks

Later, we enhance this with HTTPS + ACM, making the setup production-ready.

🚀 Provisioning the Infrastructure

Before running Terraform, we need to create the S3 bucket for state storage:

aws s3 mb s3://pravesh-terraform-mario-state

⚠️ If you see BucketAlreadyExists, simply:

Update the bucket name in backend.tf
Re-run the command with a unique name

Now initialize Terraform:

cd terraform
terraform init

Gemini API Key Setup

Head over to Google AI Studio and generate a free Gemini API key.

Once you have it, keep it safe — we’ll pass it dynamically to Terraform.

Plan & Apply

Preview the infrastructure:

terraform plan -var="gemini_api_key=<YOUR_GEMINI_API_KEY>"

Review the plan and then deploy:

terraform apply -var="gemini_api_key=<YOUR_GEMINI_API_KEY>" -auto-approve

⏱️ Provisioning takes around 5–7 minutes, mainly due to ALB setup.

🎮 Final Result

Once Terraform finishes:

Copy the ALB DNS name from the outputs
Open it in your browser

🎉 You should now see the Super Mario Bros game running on ECS, backed by a serverless AWS architecture and guarded by an AI-powered DevOps review system.

🌟 Terraform AI Review Agent in Action

Now comes the most exciting part — seeing the Terraform AI review agent in action.

Before that, you need to add your AWS Access key and Secret Access key in your secrets of the repo. If you don’t know how to do that, follow this guide and do the step 1 only, make sure you select the ai-devops-projects repo, not the nginx-redis-node.

Let’s simulate a real-world scenario by making a small change to our infrastructure code and opening a Pull Request. As soon as we do this, our GitHub Actions workflow will automatically kick in and run the AI-based review.

Triggering the AI Review

Make a minor change in the Terraform code and raise a Pull Request. Once the pipeline runs, you’ll notice that the workflow fails ❌.

Why did this happen?

If you check the Violation report, you’ll see that the AI agent rejected the changes. The reason is simple and important:

Three MEDIUM-severity issues are related to the Application Load Balancer
Our application is currently running only on HTTP
Running production workloads over HTTP is not secure

Because our AI agent follows a strict policy (defined in the Lambda prompt), the absence of an HTTPS listener on the ALB results in a PR rejection.

This is exactly how a real-world AI-powered infrastructure gate should behave.

Fixing the Issue: Enabling HTTPS 🔒

To resolve this, we’ll enable HTTPS by creating an ACM certificate and updating our ALB configuration.

Step 1: Update Security Group Rules

Inside security.tf, uncomment the ingress rule for port 443 so that HTTPS traffic is allowed.

Step 2: Enable HTTPS Listener on ALB

Open alb.tf and do the following:

Uncomment the aws_lb_listener "https" block
Uncomment the ACM certificate resource
Remove the existing app_listener (HTTP listener)

This ensures HTTP is no longer used for forwarding traffic directly.

Step 3: Update Domain Name in ACM Certificate

Inside the ACM certificate resource:

Replace praveshsudha.com with your own domain name
This is required because you’ll be adding CAA and CNAME records for certificate validation

Step 4: Add CAA Record (IMPORTANT ⚠️)

Before creating the ACM certificate, make sure to add the following CAA record in your DNS provider:

Type: CAA
Name: @
Flag: 0
Tag: issue
CA Domain: amazonaws.com
TTL: Default

⚠️ Important: Add this CAA record before applying Terraform, otherwise ACM certificate creation may fail.

Step 5: Enable ACM Output

In outputs.tf, uncomment the output block for acm_certificate_arn.

This will help us fetch validation details later.

Step 6: Apply the Changes

Run the following command:

terraform apply --var="gemini_api_key=<YOUR_GEMINI_KEY>" --auto-approve

This will:

Create the ACM certificate
Add an HTTPS listener to the ALB

Once completed, Terraform will output the ACM certificate ARN.

Step 7: Validate the ACM Certificate

Use the ARN and run:

aws acm describe-certificate \
  --certificate-arn arn:aws:acm:us-east-1:<ACCOUNT_ID>:certificate/<CERT_ID>

From the output:

Copy the CNAME name (only up to mario, not the full domain)
Copy the CNAME value

Add this CNAME record to your DNS provider.

Within a few minutes, the certificate status will change to ISSUED ✅.

Step 8: Point Your Domain to the ALB

Now create a DNS record:

Type: CNAME
Name: mario
Target: <YOUR_ALB_DNS_NAME>
TTL: Default

After a few minutes, your application will be live at:

👉 https://mario.your-domain.com

Re-running the AI Review ✅

Now that HTTPS is enabled, let’s test the AI agent again.

Run the following commands:

git checkout -b test
git add outputs.tf security.tf alb.tf
git commit -m "testing ai-agent-workflow"
git push origin test

Go to your GitHub repository and open a Pull Request.

This time:

GitHub Actions runs successfully
Terrascan reports are generated
Gemini analyzes the findings
✅ AI agent APPROVES the PR

🌟 Cleaning Up Resources

Once you’re done experimenting with the project, it’s very important to clean up all the resources to avoid any unnecessary AWS charges.

Follow the steps below in order to safely delete everything we created.

Step 1: Destroy Terraform Resources

First, navigate to the terraform directory and run:

terraform destroy --auto-approve --var="gemini_api_key=<YOUR_GEMINI_KEY>"

This command will:

Terminate ECS services and tasks
Delete the Application Load Balancer
Remove Lambda functions and IAM roles
Clean up networking components like VPCs, subnets, and security groups

Step 2: Delete the Terraform State Files from S3

Once Terraform has destroyed all the resources, delete the remote state files stored in S3.

aws s3 rm s3://pravesh-terraform-mario-state --recursive

This removes all objects inside the bucket, including the Terraform state file.

Step 3: Remove the S3 Bucket

Finally, delete the empty S3 bucket:

aws s3 rb s3://pravesh-terraform-mario-state

🌟 Conclusion

This project goes far beyond deploying a Super Mario game on AWS — it represents how modern DevOps is evolving with AI and serverless architectures.

By integrating Terraform, GitHub Actions, Terrascan, and Gemini, we built an AI-powered Terraform review agent that acts as a real CI/CD security gate. Every infrastructure change is evaluated based on risk, not guesswork. The AI summarizes security findings, suggests concrete remediations, and makes approval decisions that closely resemble how a senior DevOps engineer would review production infrastructure.

On the infrastructure side, we embraced a serverless-first approach using AWS ECS Fargate, Lambda, ALB, and managed cloud services. This setup reflects real-world architectures used in production today — scalable, cost-efficient, and operationally simple, without managing servers manually.

The key takeaway from this project is clear:

AI in DevOps is not about replacing engineers — it’s about empowering them.

By automating repetitive infrastructure reviews, we save valuable engineering hours, reduce human errors, and ship changes with higher confidence and security.

I highly encourage you to fork the repository, experiment with breaking changes, tune the AI decision thresholds, and extend this project further. This is just the beginning of what AI-assisted DevOps can achieve.

Happy building 🚀

🔗 Connect with me

LinkedIn: https://www.linkedin.com/in/pravesh-sudha/
Twitter / X: https://x.com/praveshstwt
YouTube: https://www.youtube.com/@pravesh-sudha
Blog: https://blog.praveshsudha.com

If this project helped you learn something new, feel free to share it with your network — it truly helps a lot ❤️

🚀 How I Created an AI-Powered Secret Santa Using Cognee as the Memory Layer

Pravesh Sudha — Thu, 11 Dec 2025 12:30:00 +0000

Welcome Devs 👋 — Another Fun Build with Cognee + AI

Welcome Devs to another interesting blog from my side!

It’s been a while since I first connected with Cognee, and exactly a month ago I actually built a Cognee Starter application from scratch using Flask and deployed it on AWS ECS using Terraform. If you haven’t checked it out yet, here’s the link to that build — you’ll enjoy it:

Since then, the Cognee team has been on fire. Their GitHub repo recently crossed 10K+ stars (absolutely deserved 🎉). And staying true to the momentum, they came up with a fun little community event — the Secret Santa Mini Challenge.

So… for this challenge, I decided to build something a bit unique —

✨ An Emotion-Aware Secret Santa powered by Gemini 2.5 Flash, with Cognee acting as the memory layer holding everything together.

How the Idea Hit Me 🤯 — And Why Emotions Matter in Secret Santa

After going through the rules and criteria of the challenge, I started brainstorming ideas… and suddenly something clicked on a very personal level.

In my friend group, I’m the delightful one —

Happy for no absolute reason, just vibing, giggling, randomly remembering something from Kevin Hart Special 😂

But my friends?

Total opposite personalities:

One is stressed 24/7 because of career pressure
Another is moody, unpredictable like Mumbai weather
And the last one is the chill guy, relaxed in literally every situation

Reflecting on that, I thought:

Why not create a Secret Santa that understands emotions the same way we understand each other?

A Secret Santa that:

Reads how each friend is feeling
Understands their energy, mood, and stress
Pairs them up based on emotional compatibility
And even helps choose a meaningful gift

That’s how Emotion-Aware Secret Santa was born.

How It Works 🧠🎁 — Turning Feelings Into Smart Gift Matches

Each friend gives:

Their name, and
A short description of their mood, week, stress level, or personality

For example:

“Alice is overwhelmed with work and feeling stressed.”
“Bob had a great week and is feeling positive and energetic.”

These tiny descriptions become the foundation for the AI’s reasoning.

🧩 Step 1 — Storing the emotional descriptions with Cognee

Each user description is added into Cognee’s memory layer using:

cognify.add(...)

Then using:

cognify()

Cognee processes all the data with Gemini, building:

Semantic links
Entities
Relationships
A mini knowledge graph
Embeddings

(I’ve shown this visually in my previous video — it’s super cool to watch.)

🧠 Step 2 — Cognee asks the right question

Cognee then asks:

“What is the emotional state or mood of Alice?”

Using RAG_COMPLETION, Gemini returns refined emotional states like:

stressed
excited
lonely
happy
tired

🎅 Step 3 — AI-Powered Secret Santa Pairing

Now the fun logic:

Cognee assigns Secret Santa pairs
Makes sure no one gets themselves
And suggests a gift based on emotion

Gift suggestions are generated using a local gift dictionary (0 extra AI cost… because while testing I hit the Gemini daily quota twice 💀😂).

🎉 Step 4 — The Big Reveal

Finally, the program prints a beautiful Secret Santa reveal:

Who is gifting whom
Why they were paired
And what gift matches their emotional state

Simple, wholesome, and powered by Cognee’s memory + Gemini’s reasoning.

Try It Yourself 🎄 — Run the Emotion-Aware Secret Santa on Your Machine

I’ve open-sourced the entire project so you can explore, modify, and have fun with it.

The code is available here:

👉 GitHub Repo: https://github.com/Pravesh-Sudha/secret-santa-cognee

Clone it to your system and you’re ready to get started.

🔑 Step 1 — Get Your Gemini API Key

To run this project, you’ll need a Gemini API key.

The good news? Google AI Studio gives you one for free.

Once you have your key:

Inside the project directory, create a .env file
Copy everything from .env.example
Replace the values of:

* `LLM_API_KEY`

* `EMBEDDING_API_KEY`  
    with your Gemini key

And boom — the setup is done.

🔧 Step 2 — Install Dependencies

Inside your project directory, run:

uv sync

This will install all required dependencies cleanly.

📝 Step 3 — Customise Your Friends & Gifts

You can now explore the code and make the project your own:

👥 Add your own friends

Open:

data/friends.json

Add your friends and their mood descriptions.

(Tip: try to keep it max 4 friends, otherwise you may hit the Gemini daily quota like I did 😭😂)

🎁 Customise the gifts

Inside:

gift_gen.py

You can update gifts for each emotion to make them more fun, personal, or chaotic — your call.

▶️ Step 4 — Run the Project

Once everything is set up, run:

uv run main.py

The program takes around 2–3 minutes, and then…

🎉 You get a full Secret Santa reveal right in your terminal!

Who got whom
Their emotional reasoning
And the perfect gift suggestion

All powered by Cognee + Gemini.

NOTE: Initially, I planned to generate gifts using Gemini too… but Gemini’s “Requests per Minute” limit looked at me and said:
“Not today, brother.”
So I switched to a local gift list — zero extra AI cost, much more reliable.

📽️ Video Demonstration

🎄 Conclusion — Building with Cognee Is Just Too Much Fun

This Secret Santa Mini Challenge by Cognee was the perfect excuse to experiment, break things, fix things, hit API limits twice 😭, and eventually build something that felt genuinely personal.

Using Cognee as the memory layer + Gemini 2.5 Flash for reasoning turned a simple holiday tradition into a small emotionally aware AI system — and honestly, that’s the kind of playful innovation that makes me love building these projects.

If you try it out, tweak it, or turn it into something wild and creative, I’d genuinely love to see it.

And big shoutout to the Cognee team for organizing such a wholesome challenge and continuing to ship amazing updates to the ecosystem.

More AI projects, more experiments, and more community fun coming soon.

Till then — keep building, keep learning, and keep vibing. ✨

🌐 Connect With Me

If you enjoyed this project or want to follow my DevOps + AI journey, find me here:

LinkedIn: https://www.linkedin.com/in/pravesh-sudha/
Twitter/X: https://x.com/praveshstwt
YouTube: https://www.youtube.com/@pravesh-sudha

See you in the next build! 🚀

How I Built My Terraform Portfolio: Projects, Repos, and Lessons Learned

Pravesh Sudha — Sun, 07 Dec 2025 17:24:20 +0000

Welcome Devs,

Today, we’re not spinning up infrastructure, writing HCL, or fixing a broken state file (for once 😅).

Instead, we’re looking back at the last 8 months—a journey filled with learning, building, breaking things, fixing them again, and slowly becoming “that Terraform guy” in my circle.

It all started in April 2025, when one of my LinkedIn buddies shared that he got selected as a HashiCorp Ambassador.

That was the first time I genuinely thought:

“Damn, this looks exciting. Why don’t I aim for it too?”

Just a month before that—in March 2025—I had been selected as an AWS Community Builder, and around the same time, I launched my YouTube channel to share DevOps and Infra-as-Code tutorials with the world.

Slowly, people started watching, sharing, and sending messages saying they actually deployed things using my guides.

So officially, in May 2025, I decided:

🔥 I’m going to prepare for HashiCorp Ambassador 2026. Let’s do this seriously.

Fast-forward 8 months—

I’ve built multiple Terraform projects, contributed to open-source repos, and crossed:

20,000+ views on my blogs
16,000+ views on YouTube
400+ awesome subscribers

More importantly, I went from “Terraform looks complicated” to “Terraform is my comfort zone.”

And today, I’m sharing the exact resources, projects, repos, and lessons that helped me go from Zero → Hero in Terraform — and will help you too.

1. Building a Strong Terraform Foundation

Even though I already had some familiarity with Terraform (thanks to scattered YouTube videos and random experiments), I decided to start from absolute zero—because if I’m going to teach something, I need to understand it deeply myself.

So the first thing I created was a “Getting Started with Terraform” guide.

This wasn’t just another intro blog. My goal was to help beginners understand:

What Terraform really is
Why DevOps engineers rely on IaC
How providers work
Structuring a project with main.tf, variables.tf, outputs.tf
What “configuration” means in practice

Basically, the fundamentals you must know before touching any cloud resource.

If you are new, you can read the same guide here:

👉 Getting Started with Terraform – A Beginner’s Guide

Once the basics were sorted, I went deeper into the most important part of Terraform—

the thing that causes 90% of people stress when it breaks:

The Terraform State File

Where to store it?

How to keep it safe?

How to ensure teams don’t overwrite each other’s state?

I wrote a complete blog explaining how to use AWS S3 + DynamoDB as a rock-solid remote backend for production-grade Terraform.

I even created a YouTube demo for those who prefer watching over reading.

📘 Blog: Where Should You Store Terraform State Files for Maximum Efficiency?

🎥 Video: Terraform Remote Backend on AWS (S3 + DynamoDB)

These two resources became the backbone of my Terraform foundation—not just for me, but for everyone following along.

Before I moved to advanced projects, pipelines, and multi-environment infra… this foundation is what made everything else 10× easier.

2. Core Concepts & Best Practices (The Part Everyone Skips But Shouldn’t)

Once the foundations were clear, I moved into the phase where most beginners either get overwhelmed… or fall in love with Terraform.

For me, this was the moment things clicked.

Because understanding Terraform is not just learning commands — it’s learning structure, security, and scalability.

a) Terraform Modules – The Secret Sauce

One of the first “Aha!” moments for me was understanding modules.

If there’s one thing that separates beginners from pros, it’s this.

Modules teach you:

How to avoid repetitive code
How to scale infra easily
How to structure projects cleanly
How teams collaborate efficiently

I wrote an in-depth blog breaking this down and also created a complete YouTube walkthrough.

📘 Blog: Terraform Modules – The Secret Sauce to Scalable Infrastructure

🎥 Video: Terraform Module Explained with Demo

Learning modules improved how I thought about every project afterward.

b) Terraform Security Practices (Because IaC Without Security is Just a Script)

Infrastructure automation is amazing—but it also means if you make a mistake, you can take down everythinginstantly.

So I created a dedicated guide covering the Top 5 DevSecOps-focused Terraform security practices, including:

Provider credential validation
Role-based access
Scanning Terraform code for vulnerabilities
Remote backend security
Avoiding manual state file edits (my favourite rule 😅)

📘 Blog: Terraform Meets DevSecOps – 5 Security Practices You Can’t Ignore

🎥 Video: Terraform Security Best Practices

This was the point where both my blog and channel started gaining real traction—people were searching for practical, real-world Terraform security advice.

c) Terraform Workspaces – The Most Underrated Feature Ever

Workspaces are like that quiet student in class who actually knows everything.

Nobody talks about them…

until they see how powerful multi-environment deployment becomes with a single command:

terraform workspace select dev
terraform workspace select prod

Workspaces changed how I approached multi-environment infra forever.

📘 Blog: Terraform Workspaces & Multi-Environment Deployments

🎥 Video: Complete Workspace Tutorial on AWS

d) Terraform Meets Ansible (IaC + Configuration Management = 🔥)

The next logical step was learning how Terraform works with configuration management tools.

Terraform builds the infra.

Ansible configures what lives inside the infra.

I created a hands-on guide where I showed exactly how Terraform provisions servers and Ansible configures them — a production-ready combo.

📘 Blog: Terraform Meets Ansible – Automating Multi-Environment Infra on AWS

🎥 Video: Terraform + Ansible Full Demo

This section was a turning point in my portfolio because it bridged two worlds—Infra-as-Code and Configuration Management.

3. CI/CD, Automation & Modern DevOps (Where Everything Comes Together)

After covering modules, security, workspaces, and multi-environment provisioning, it was time to bring Terraform into the real world —

the world of automation, pipelines, and DevOps workflows.

I had already used Terraform with Jenkins and even GitLab CI/CD in my previous projects (outside this series), so this time I wanted to do something fresh.

And what’s more “modern DevOps” than using GitHub Actions?

So I decided to build a real project that connects:

Terraform
GitHub Actions
AWS
And a production-style multi-component application (Node.js + Redis + Nginx)

The Project: Request Counter App Deployment on AWS

This wasn’t just a “hello world” project.

It involved:

A Node.js API handling increment-count logic
Redis to store the counter
Nginx as a reverse proxy
Terraform to provision AWS infra
GitHub Actions to automatically deploy everything on push

In short, a full Infrastructure + Application + CI/CD pipeline — the kind of thing you actually do in real companies.

I documented the entire workflow so anyone can recreate it step-by-step.

📘 Blog: CI/CD for Terraform with GitHub Actions – Deploying a Node.js + Redis App on AWS

🎥 Video: GitHub Actions + Terraform Full Pipeline Demo

This project helped me understand how Terraform behaves inside a pipeline: the checks, the backend locks, the state consistency, the secret management — all of it.

And more importantly, it leveled up my DevOps portfolio significantly.

Real-world + automated + cloud-native = a perfect trifecta.

4. Cloud-Native & Multi-Tier Application Deployments (Intermediate Projects)

Once I became comfortable with Terraform fundamentals, DevSecOps practices, and CI/CD automation, it was time to step into the cloud-native world — where real production systems live and breathe.

This phase of my journey pushed me out of my comfort zone, because now I wasn’t just creating small demos.

I was building multi-tier, scalable, mission-critical infrastructures — the kind you’d actually find in modern companies.

a) Deploying a Three-Tier Application on AWS EKS (with Best Practices)

Kubernetes + Terraform is a whole universe on its own.

So to challenge myself, I decided to deploy a complete three-tier application on AWS EKS, fully automated using Terraform — following all real-world best practices.

This included:

VPC with subnets
Managed node groups
Ingress controllers
Load balancers
Namespace separation
Secrets + configs
And a proper service-to-service communication workflow

It was one of the most complex setups I’d built at that point — and the most rewarding.

📘 Blog: Deploy a Three-Tier Application on AWS EKS using Terraform (Best Practices)

🎥 Video: EKS + Terraform Deployment Tutorial

(This video crossed 1,000+ views—first big milestone!)

b) Deploying a Highly Scalable & Available Django Application (AWS + Terraform)

After EKS, I wanted to explore another real-world architecture — something more traditional, but equally production-grade.

So I built a highly scalable Django application hosted on AWS using Terraform.

This project included all the standard AWS building blocks you’d expect in a real enterprise setup:

RDS for relational database
Secrets Manager for secure credentials
Application Load Balancer
Auto Scaling Group
EC2 instances for compute
Private/public subnets
Proper network isolation and high availability

This architecture reflected how an actual company would deploy a Python backend in production.

📘 Blog: Deploying a Highly Scalable Django Application on AWS with Terraform

🎥 Video: Django + AWS + Terraform Full Architecture Demo

This stage of my Terraform portfolio strengthened my confidence in handling full-stack cloud-native deployments — not just isolated resources.

5. Game Deployments & Creative Infra Projects (The Standout Pieces)

Now, let’s talk about the most fun part of my Terraform journey — the projects that truly made my portfolio stand out.

I’ve been a gamer since childhood, and fun fact:

I actually bought my PS5 using the prize money I won as the Dev.to Runner-H Challenge Winner (Scolded by my Dad for this unjust purchase, but HELL YEAH!!, it was worth it.)

So, naturally, I decided to merge my love for gaming with my DevOps career.

The result?

Some of the most unique, creative, and highly engaging Terraform projects I’ve ever built.

a) Deploying Super Mario Bros on AWS EKS (Award-Winning Project)

This one will always be special.

I deployed the classic Super Mario Bros game on AWS EKS using Terraform — complete with pods, services, ingress, and Kubernetes best practices.

This project wasn’t just a hit among developers —

it actually helped me win the AWS Containers 4x4 Challenge, and I received some amazing premium swags from the community.

📘 Blog: Deploy Super Mario on AWS EKS using Terraform (Step-by-Step)

🎥 Video: Super Mario on Kubernetes Demo

b) Deploying Tetris on AWS ECS with Terraform

After nailing Mario, I didn’t want to stop.

Next, I deployed Tetris — this time using Amazon ECS with Terraform.

This project explores how containerized applications run on ECS Fargate, how services scale, and how ALBs route traffic.

📘 Blog: How to Deploy a Tetris Game on AWS ECS with Terraform

🎥 Video: Tetris on ECS – Full Walkthrough

c) Deploying Cognee AI Starter App on ECS (Collaboration Project)

One of the most exciting collaborations of my journey was with Cognee AI — the memory layer of AI Agents.

I built a Flask-based Cognee Starter Application from scratch, containerized it, and deployed it on AWS ECS using Terraform as the IaC backbone.

This project taught me a lot about real product deployment workflows, container orchestration, and DevOps collaboration.

📘 Blog: Deploying Cognee AI Starter App on ECS with Terraform

🎥 Video: Cognee AI Deployment Demo

d) Deploying an Amazon Clone on AWS (Amazon on AWS — Meta Enough?)

To wrap up this creative phase, I decided to do something hilarious and ambitious:

Deploying an Amazon Clone on… AWS itself.

Yes — Amazon on AWS. A true full-circle moment. 😂

This project used:

Jenkins for CI/CD
Terraform for infra
AWS services like EC2, ALB, ASG, RDS, VPC
And a full clone app architecture setup

📘 Blog: Deploy an Amazon Clone on AWS (Complete Guide with Jenkins + Terraform)

🎥 Video: Amazon Clone Deployment Tutorial

These projects became the highlights of my Terraform portfolio — the kind that make recruiters pause, smile, and think:

“Okay, this person actually enjoys building stuff.”

6. Reflection & Growth (The End of This Portfolio — But Not the Journey)

And now… here we are.

Eight months later.

Countless blogs, videos, deployments, wins, failures, swags, and late-night debugging sessions later — I finally paused and asked myself a very simple question:

“If a complete beginner asked me for guidance today… what would I say?”

Because when you’re learning something as powerful as Terraform, the hardest part isn’t understanding .tf files —

it’s navigating the early confusion, the overwhelming docs, the trial-and-error, and the mistakes we all make.

So to answer that question, I created a dedicated piece:

the top 5 mistakes beginners make while learning Terraform — and how to avoid them.

📘 Blog: Don’t Touch Terraform Before Avoiding These 5 Rookie Mistakes

🎥 Video: Top 5 Beginner Mistakes in Terraform

This video and blog were my way of giving back to anyone starting the same journey I took in April 2025.

If I could go back in time, this is exactly what I would hand to myself.

The Terraform Guide (Everything in One Place)

To make things easier for learners, I bundled every single blog — foundations, modules, state files, workspaces, EKS, ECS, CI/CD, everything — into a clean, structured series:

📚 Terraform Guide Series: All blogs in one place

This series now stands as a complete Zero-to-Hero path for anyone wanting to master Terraform using real projects.

Terraform Playlist (All Video Demonstrations)

And for visual learners, I created a dedicated playlist on YouTube containing every demo, from foundational projects to Kubernetes deployments and game infra:

🎥 Terraform Project Playlist

Conclusion

As I wrap up this 8-month Terraform journey, one thing is clear: this portfolio isn’t just a collection of .tf files — it’s a reflection of growth, discipline, creativity, and identity.

When I started back in April 2025, I didn’t know Terraform beyond the basics. I simply made a decision in May 2025:

“I will learn this tool properly and build something meaningful.”

Eight months later, here’s what that decision turned into:

I learned Terraform from scratch
Built real-world, production-style cloud infrastructures
Won community challenges, including AWS Containers 4x4
Collaborated on AI projects, like the Cognee AI deployment
Published blogs that crossed 20,000+ views
Grew my YouTube channel to 16,000+ views and 400+ subscribers
And most importantly, built projects that genuinely reflect who I am as a DevOps engineer

This journey taught me that you don’t need a perfect starting point — you just need a consistent one.

It showed me that sharing your learning publicly builds connection, credibility, and confidence.

And it proved that passion projects (like deploying Super Mario and Tetris using Terraform) can teach you more than any textbook ever will.

If you’re just beginning your Terraform journey, I’ll leave you with this:

Start small. Stay consistent. Build publicly.

Because the internet remembers builders — not perfectionists.

Thank you for reading my story.

I hope this motivates you to start building your own.

📌 Connect With Me

🔗 LinkedIn: https://www.linkedin.com/in/pravesh-sudha/

🐦 Twitter/X: https://x.com/praveshstwt

📺 YouTube: https://www.youtube.com/@pravesh-sudha

🌐 Website/Blogs: https://blog.praveshsudha.com

Let’s keep learning and building — together.

Don’t Touch Terraform Before Avoiding These 5 Rookie Mistakes

Pravesh Sudha — Sat, 06 Dec 2025 15:48:29 +0000

The 5 mistakes that quietly destroy your workflow — and how to fix them.

🌟 Introduction

Welcome back, Devs!

A few weeks ago, I shared 5 Best Security Practices for Terraform. That guide was more for folks who already work with Terraform day in and day out — the ones managing infra at scale, reviewing modules, and pushing changes through CI/CD pipelines.

But what about the beginners?

The ones who just wrapped up the basics of DevOps — Linux, Networking, Docker, Git — and are now stepping into the cloud world. For them, Infrastructure as Code can feel… well, intimidating at first. Terraform looks simple from the outside, but when you actually start writing configurations, the learning curve hits hard. And it’s totally normal — IaC is a tough nut to crack initially.

So to make your journey smoother and confusion-free, I’m back with today’s blog, where we’ll break down the Top 5 Mistakes Beginners Make While Learning Terraform — and how you can avoid them.

Without further ado… let’s get started!

🌟 Before We Dive In… Do This First

Before we dive deep into the mistakes, let’s get one thing out of the way — make sure you’ve got Terraform ready on your system. No matter how good the guide is, nothing makes sense unless you’ve actually installed the CLI and can run those sweet terraform init and terraform apply commands.

Since I’m an AWS Community Builder, I usually stick to AWS as my cloud provider for demos and explanations. If you’re following along, you’ll need to connect Terraform to your AWS account. You can do that in two ways:

Export AWS credentials directly in your terminal

(AWS_ACCESS_KEY_ID + AWS_SECRET_ACCESS_KEY)

Works fine, but not the best option for long-term use.
Install the AWS CLI (recommended)

This is cleaner, more secure, and helps you manage multiple profiles easily.

Just create an IAM user with the right permissions and run aws configure.

If you don’t know how to set that up — don’t worry. I’ve already covered the entire process in my Beginner’s Guide to Terraform. You can check it out here:

👉 https://blog.praveshsudha.com/getting-started-with-terraform-a-beginners-guide#heading-step-1-install-the-aws-cli

Once your CLI and AWS credentials are set, you’re all ready to explore the mistakes beginners make and how you can avoid them.

❌ Mistake 1: Treating Terraform Like a Scripting Tool

This is hands-down the most common beginner mistake.

Most folks who get introduced to Terraform have already touched at least one programming language — Python, Go, Rust, maybe even Bash scripting. And because of that prior experience, they naturally assume Terraform will behave the same way:

“I wrote line 1 first, so Terraform will execute that first… right?”

Nope. Not at all.

Terraform is not a scripting tool.

It doesn’t run your code line-by-line.

It doesn’t care about the order in which you wrote your resources.

Terraform is declarative, not imperative.

Instead of following your code from top to bottom, Terraform reads all the resources in your configuration and builds something called a dependency graph. This graph tells Terraform which resources depend on which other resources — and that determines the execution order.

So beginners often get confused:

“Why is Terraform not creating things in the order I wrote them?”

Because Terraform is smarter than that. It looks at dependencies, not line numbers.

Moral of the story:

With Terraform, you don’t explain how to create each step. You only declare what you want — like an EC2 instance, security groups, and a VPC — and Terraform figures out the “how” automatically.

Once you understand this mindset shift, Terraform becomes much easier (and honestly, more fun) to work with.

❌ Mistake 2: Hardcoding Everything Instead of Using Variables

If you’re anything like me, you love going through official docs whenever you start learning a new tech. And if you visit the Terraform documentation, you’ll notice something instantly:

Most of their example configurations hardcode values.

Region? Hardcoded.

AMI ID? (Got from data type).

App name, DB name, instance type? All hardcoded.

And honestly — that's fine when you're just starting out. Hardcoding helps beginners understand the structure of a resource without worrying about variables, files, or module structures.

But once you get a basic understanding of how Terraform works…

hardcoding becomes your worst enemy.

Let me explain with a simple example.

Say you’ve deployed a two-tier application on AWS — your VPC, ALB, EC2, RDS, security groups, everything. Now there’s a new feature request, and you don’t want to deploy the changes in the same environment.

So you decide to replicate the environment.

If everything is hardcoded, you’re now stuck manually changing names and identifiers for every single resource.

Painful.

Time-consuming.

Highly prone to breaking things.

The Fix: Use Variables Like a Pro

Store all your important attributes inside a variables.tf file.

This gives you a clean, centralized location for every configuration value your entire project depends on.

In the above scenario, if your resources use variables, all you need to do is change a value in one place — and Terraform will automatically reflect it everywhere.

Here’s how you define a variable in Terraform:

variable "instance_type" {
  default = "t2.micro"  # EC2 Instance Type
}

Clean, reusable, scalable — and exactly how real-world Terraform is written.

❌ Mistake 3: Mixing Manual Changes Through the AWS Console

This one is a classic beginner trap.

When you provision infrastructure using Terraform, it stores a full blueprint of your resources inside the terraform.tfstate file. This file represents the current state of your infrastructure — basically Terraform’s memory of what exists.

Now imagine you want to update something small, like renaming an EC2 instance.

You open the AWS Console, click on the instance, change the name, hit save, and boom — done.

Simple, right?

Yes. But also… very wrong.

Making manual console changes creates something called drift — a mismatch between:

what actually exists in AWS
what Terraform thinks exists (according to the state file)

This drift becomes a huge headache because Terraform will now get confused about what's changed, what needs to be replaced, or what should not exist at all. For beginners, handling drift is even more overwhelming because it's not always obvious where things went wrong.

Here’s the golden rule:

If you provision resources using Terraform,

update or delete them using Terraform only.

Avoid the temptation of "quick fixes" in the AWS Console. A few clicks today can cause hours of debugging tomorrow.

Moral of the story:

Treat Terraform as your single source of truth.

No ClickOps. No shortcuts.

❌ Mistake 4: Ignoring Terraform Resource Dependencies

Terraform is pretty smart when it comes to understanding relationships between resources. It automatically builds a dependency graph to figure out what needs to be created first and what depends on what.

Most of the time, this works beautifully.

But sometimes… Terraform needs a little help.

There are scenarios where Terraform cannot infer dependencies on its own — especially when two resources don’t have an obvious reference to each other. That’s where beginners get stuck.

For example:

Applying an S3 Bucket Policy before the bucket is actually created
Applying IAM role attachments before the IAM role itself exists
Creating a Lambda permission before the Lambda function is ready

In such cases, Terraform might try to create things in the wrong order, leading to errors.

The Fix: Use `depends_on` Smartly

Terraform gives us an escape hatch — the depends_on meta-argument.

With depends_on, you can explicitly tell Terraform:

“Hey, this resource should only be created after this other resource is fully ready.”

It ensures the correct and predictable order of execution.

Example use case:

resource "aws_s3_bucket_policy" "bucket_policy" {
  bucket = aws_s3_bucket.my_bucket.id

  policy = data.aws_iam_policy_document.example.json

  depends_on = [
    aws_s3_bucket.my_bucket
  ]
}

Now Terraform knows for sure: Bucket first → Policy second.

Moral of the story:

Understand how Terraform creates its dependency graph, and use depends_on wisely when Terraform can’t figure things out on its own.

❌ Mistake 5: Thinking Terraform Is Only About `init`, `plan`, and `apply`

I still remember when I started learning Terraform.

I watched a bunch of YouTube tutorials, and almost every single one followed the exact same pattern:

Write config in main.tf, provider in provider.tf, vars in variables.tf, outputs in outputs.tf
Run terraform init
Run terraform plan (and let’s be honest, most beginners skip this 😅)
Run terraform apply --auto-approve
And at the end, terraform destroy

And that’s it.

End of tutorial.

Done.

“You now know Terraform.” 🙃

Except… that’s not the full story.

Terraform is not just about those three commands. There are many other commands that help you:

write cleaner, more readable code
avoid silly mistakes
prevent accidental deployments
stick to best practices from day one

But beginners (including me back in the day) completely ignore them.

Here are a few essential ones:

🔹 `terraform plan` (Seriously, use it)

Before applying, always check the plan.

It shows you what Terraform will create, modify, or delete.

Skipping this step is how disasters happen — and trust me, I’ve been guilty of this too. 😅

🔹 `terraform fmt` (Fix your code automatically)

Your code may work, but if it looks like a messy bowl of noodles, nobody wants to maintain it.

terraform fmt formats your HCL beautifully and keeps your files consistent.

🔹 `terraform validate` (Catch misconfigurations early)

Sometimes your code “looks” right but contains subtle mistakes — wrong types, bad arguments, misplaced blocks, etc.

terraform validate helps detect these before you even think about applying them.

Moral of the story:

Make fmt, validate, and plan a daily habit.

They will save you from so many unnecessary headaches.

🌟 Hands-On: Deploying a Static Portfolio Website on an S3 Bucket

Alright, that’s enough theory — now let’s actually get our hands dirty.

To make everything we discussed more practical, we’ll deploy a static portfolio website on an S3 bucket using Terraform.

The complete code is available here:

👉 https://github.com/Pravesh-Sudha/terra-projects

Once you open the repo, navigate to the terra-mistakes directory. Inside it, you’ll find multiple Terraform files and a static/ folder. The static directory contains two HTML files:

index.html — your main portfolio page
error.html — fallback page for unexpected errors

Inside the main.tf, we’re:

creating an S3 bucket
enabling static website hosting
uploading both HTML files
attaching a bucket policy to allow public access

You’ll also notice something important:

We didn’t hardcode values; even in this small project, the bucket name is stored in variables.tf
We used depends_on so Terraform knows to create the Public Access Block before applying the bucket policy

These are the exact practices that prevent the mistakes we discussed earlier.

Run These Commands to See Everything in Action

Open your terminal inside the terra-mistakes directory and run:

terraform init          # Initialize provider plugins
terraform fmt           # Fix indentation, syntax, and formatting
terraform validate      # Detect any surface-level misconfigurations
terraform plan          # Preview what Terraform will provision
terraform apply --auto-approve   # Deploy the S3 website

Once the resources are created, Terraform will output the Website URL from the output.tf file.

Note:

This project is deployed in us-east-1, and the S3 website endpoint URL is hardcoded for that region.

If you want to deploy in another region, update both the provider and output.tf accordingly.

Now, open the URL in your browser — and boom! 🎉

Your portfolio website is live on S3.

Updating the Policy the Right Way

Let’s say you want to add delete object permission to the bucket policy.

The beginner instinct?

Head straight to the AWS Console → IAM → update the policy manually.

But we don’t do ClickOps here.

Remember: Terraform is your single source of truth.

So instead, update your HCL code inside the bucket policy:

Statement = [
  {
    Sid       = "PublicReadGetObject"
    Effect    = "Allow"
    Principal = "*"
    Action    = ["s3:GetObject", "s3:DeleteObject"]  # Added delete permission
    Resource  = "${aws_s3_bucket.site_bucket.arn}/*"
  }
]

Then apply the changes:

terraform apply --auto-approve

Terraform will detect the change, update only the policy, and keep everything consistent — no drift, no confusion.

To cross check the changes, go to S3 Console → Navigate to the bucket and click on Permissions tab and See the Bucket Policy.

Cleaning Up

When you're done experimenting, don’t forget to delete everything:

terraform destroy --auto-approve

This removes all AWS resources cleanly so you don’t get billed unnecessarily.

🌟 Conclusion

Learning Terraform as a beginner can feel overwhelming — not because the tool is hard, but because Infrastructure as Code requires a different mindset. The mistakes we covered today are extremely common, and almost every Terraform practitioner (including me 😅) has made them at some point.

But the good news?

Once you start writing declarative code, using variables wisely, avoiding ClickOps, understanding dependencies, and making fmt, validate, and plan part of your workflow — Terraform becomes a powerful, predictable, and enjoyable tool to work with.

Take your time, practice often, and break things safely.

Every small experiment makes you a better DevOps engineer.

If you followed along with the hands-on demo, you now have a static website deployed on AWS using clean, beginner-friendly Terraform. That’s a solid milestone — great job, Dev! 🚀

Feel free to explore more projects, improve your configurations, or even contribute to the repo. And if you ever get stuck, you know where to find me.

Connect With Me

If you enjoyed this blog or learned something new, let’s connect:

🌐 Website: https://praveshsudha.com
🐦 Twitter/X: https://x.com/praveshstwt
💼 LinkedIn: https://www.linkedin.com/in/pravesh-sudha
📺 YouTube: https://www.youtube.com/@pravesh-sudha

Let’s keep building, learning, and automating together! 🚀

🚀 5 Terraform Hacks to Cut Your Deployment Time by 90%

Pravesh Sudha — Fri, 28 Nov 2025 16:43:07 +0000

🌟 Introduction

Welcome, Devs, to the exciting world of Infrastructure and Cloud computing!

If you have been navigating the cloud landscape recently, you have undoubtedly encountered the industry buzzword: Infrastructure as Code (IaC). Simply put, IaC is the practice of specifying your infrastructure requirements in a code format rather than manually configuring servers and networks. This approach is the bedrock of modern DevOps, ensuring reliability and consistency across all your environments.

While there is a robust ecosystem of tools offering IaC capabilities—including Pulumi, Chef, Puppet, and AWS CloudFormation—today we are zeroing in on the undisputed heavyweight of this segment: Terraform.

If you are just starting out or want to dive deeper into the core concepts, I have covered a lot of ground regarding Terraform in my previous posts. I highly recommend checking out the full series here to get up to speed:

👉 Terraform Series

In today's guide, we are shifting our focus to Optimisation. As your infrastructure grows, so does the complexity and the time required for deployments. We will dive into the best practices to improve the performance of your Terraform configurations, ensuring your infrastructure remains efficient, fast, and secure.

So, without further ado, let’s get started!

📽️ Youtube Demonstration

🌟 Pre-Requisites

Before we jump into the optimisation techniques, let's ensure you have the necessary tools ready to roll.

As usual, for this guide, you will need the following set up on your machine:

AWS CLI (Configured with an appropriate IAM user)
Terraform CLI
Docker and Docker-compose

If you don't have these installed yet or aren't sure how to configure them, don’t worry! I have walked through the entire process step-by-step in my previous guide. Just follow the instructions there, and you will be good to go:

👉 How to Install AWS CLI and Terraform

Once you are all set up, proceed to the next section where we start optimizing!

🌟 How to Optimise Terraform

Now that we are set up, let's get into the meat of the matter. Here are 5 Best Practices to turbocharge your Terraform performance.

1. Use Remote Backends for State Management

By default, Terraform stores its "state" (the file that maps your code to real-world resources) locally on your machine (terraform.tfstate). While this works for solo side projects, it kills performance and collaboration in real teams.

The Fix: Store your Terraform State file in a remote location, preferably AWS S3.

Why? It prevents conflicts when multiple team members (Dev, Stage, Prod) try to apply changes at the same time.
The Performance Boost: Moving to a remote backend can improve I/O performance by 10-30% for large state files.
State Locking: When configured correctly with State Lock enabled, you ensure that no two people can write to the state simultaneously. (Note: While traditionally done with DynamoDB, ensuring your backend supports locking is key to preventing corruption).

How to do it:

You simply need to create an S3 bucket and reference it in your configuration:

terraform {
  backend "s3" {
    bucket       = "my-terraform-state-bucket"
    key          = "prod/terraform.tfstate"
    region       = "us-east-1"
    use_lockfile = true
  }
}

It’s that simple!

2. Modularise Your Code

Writing one giant main.tf file is a common rookie mistake. If you are defining a secure EC2 instance, you likely also need a VPC, Security Groups, Subnets, etc. Lumping this all together makes Terraform work harder to calculate dependencies.

The Fix: Break your code down into Modules.

Instead of rewriting the same sub-components for every service, use the DRY (Don't Repeat Yourself) principle. Create a module for your network stack, a module for your compute stack, etc.

Benefit: This reduces complex dependency graphs.
Speed: It enables better parallel execution because Terraform can process distinct modules concurrently.

3. Unlock True Parallelism

Terraform is capable of walking through the dependency graph and creating non-dependent resources at the same time. However, the default setting is often too conservative.

The Fix: Adjust the -parallelism flag.

By default, Terraform limits concurrent operations to 10. For modern systems, this is quite low.

Guideline: You can safely increase this to 30-100 for normal development changes.
Constraint: Don't go too high, or you might hit AWS API rate limits (throttling). Aim for roughly 512MB of system memory per 1,000 resources.

The Result:

Using this flag can cut down plan and apply times significantly—potentially dropping a 3-5 minute operation down to just 30-60 seconds.

terraform apply -parallelism=30

4. Optimise Provider Configuration

Sometimes, Terraform performs checks that aren't strictly necessary for every single run, especially in non-production environments.

The Fix: Tune your AWS Provider.

In your Testing, Staging, or Dev environments, you can tell the provider to skip certain validations to save time on API calls. You can also configure retry behaviors to handle network blips gracefully without failing the whole run.

Example Configuration:

provider "aws" {
  region                      = "us-east-1"
  skip_credentials_validation = true
  skip_metadata_api_check     = true
  max_retries                 = 5
}

Note: While this is a great time-saver for Dev/Test environments, check your organization's policy before using strict validation skipping in Production.

5. Use Resource Targeting

When managing large infrastructure, Terraform's default behavior is to analyze the entire configuration graph. For routine, independent updates (e.g., adding a new, isolated logging bucket), you might want to limit the scope of the operation to save time.

The Use Case: Use the -target flag when dealing with literally independent resources that are not connected to other resources that are changing. This allows you to apply changes only to specific resources, acting like a surgical strike rather than a full deployment.

# Only apply changes to the specific bucket, ignoring the rest
terraform apply -target=aws_s3_bucket.my_website_bucket

🌟 Practical Demonstration

Enough with the theory! Let's get our hands dirty with some real Terraform code and the AWS Console.

To demonstrate these optimizations, we are going to deploy a Request Counter Application on AWS Elastic Beanstalk. This isn't just a "Hello World"; it is a multi-container setup running on an ECS Cluster involving:

Nginx: As a reverse proxy and load balancer.
Node.js: The application server (running two instances).
Redis: To store the request count data persistently.

Step 1: Create Your ECR Repositories

First, we need a place to store our Docker images. We will create two Public Repositories in AWS Elastic Container Registry (ECR)—one for our web app and one for our custom Nginx image.

Run the following commands in your terminal:

aws ecr-public create-repository --repository-name nginx-node-redis-web
aws ecr-public create-repository --repository-name nginx-node-redis-nginx

Step 2: Get the Code

The complete source code for this project is available on my GitHub.

Fork the repo.
Clone it to your local system.
Open it in your code editor (like VS Code).

👉 GitHub Repo: Nginx-Node-Redis Project

Step 3: Test Locally (Get the Vibe)

Before we deploy to the cloud, let’s make sure it works on your machine. Inside the project directory, run:

docker-compose up --build

This will spin up the Nginx, Redis, and two Web containers. Open your browser and go to http://localhost:8080.

You should see a nice Request Counter app. Every time you refresh, the counter increments, and you will see the server ID toggle between web1 and web2 as Nginx load-balances the traffic.

Once you are satisfied, press CTRL+C in your terminal to stop the application.

Step 4: Build and Push to Cloud

Now, let's move these images to AWS.

Navigate to the web directory in your terminal.
Go to AWS Console → ECR → Public Repositories.
Select nginx-node-redis-web and click the "View Push Commands" button.
Execute those commands one by one to build and push your web image.

Repeat for Nginx:

Navigate to the nginx directory.
In the AWS Console, select nginx-node-redis-nginx.
Click "View Push Commands" and execute them to push your Nginx image.

Step 5: The Terraform Configuration

Navigate to the terra-performance-config directory. This is where we have applied all the optimizations we discussed earlier:

provider.tf: We are skipping unnecessary validation checks (skip_metadata_api_check, etc.) to speed up the provider.
backend.tf: We are using an S3 bucket to host our state file remotely and enabling lock_file to prevent write conflicts.
main.tf: We are using a Terraform Module for Elastic Beanstalk. It utilizes a Dockerrun.aws.json file (similar to docker-compose but for ECS) which is uploaded to S3 and referenced in the module.
dockerrun.aws.json: Skelton of your Docker containers, make sure to replace the image URI of web1, web2 and Nginx, you can find it in your ECR public Repo.
variables.tf: Contains our standard configuration using the default VPC and subnets in us-east-1.

⚠️ CRITICAL: Architecture Check (ARM vs AMD)

I built the default Docker images on a MacBook Air M3 (ARM64 architecture).

If you are using Windows or Linux (Intel/AMD), your architecture is likely AMD64. You must make these two small changes in the code before proceeding, or the deployment will fail:

In variables.tf: Change the instance type from t4g.micro (ARM-based) to t3.micro or t3.small.

In Dockerrun.aws.json: Locate the Redis container definition. Change the image from the specific ARM tag to generic: "image": "redis:alpine".

Step 6: Testing Parallelism

Now for the moment of truth. Let's see how fast we can provision this stack using the Parallelism optimization.

Run the following commands:

cd terra-performance-config

# Create the S3 bucket for our artifacts
aws s3 mb s3://pravesh-ebs-terra-performance-bucket

# Initialize Terraform
terraform init

# Apply with high parallelism
time terraform apply --auto-approve -parallelism=30

The Result: Usually, a multi-container Elastic Beanstalk environment takes 10-30 minutes to provision. With -parallelism=30, you will likely see this drop to 3-8 minutes.

Once finished, Terraform will output the Elastic Beanstalk URL. Click it to see your live app!

Step 7: Testing Resource Targeting

Finally, let's look at the power of Resource Targeting.

We have made a small change to the Dockerrun.aws.json file (e.g., adding an Environment Variable).

If we ran a normal apply, Terraform might check every single resource. Instead, we will target only the specific components we are updating:

time terraform apply -parallelism=30 \
  -target=aws_s3_object.dockerrun \
  -target=aws_elastic_beanstalk_application_version.v1 \
  -target=module.elastic-beanstalk-environment \
  -auto-approve

The Result: Without targeting, Terraform might attempt to refresh the state of the entire VPC and Security Group structure. With targeting, this update happens in under a minute.

Cleanup

Don't forget to tear down your infrastructure to avoid unexpected AWS bills!

# Destroy Terraform resources
terraform destroy --auto-approve

# Clean up S3
aws s3 rm s3://pravesh-ebs-terra-performance-bucket --recursive
aws s3 rb s3://pravesh-ebs-terra-performance-bucket

# Delete ECR Repositories
aws ecr-public delete-repository --repository-name nginx-node-redis-web --force
aws ecr-public delete-repository --repository-name nginx-node-redis-nginx --force

🌟 Conclusion

And that’s a wrap, folks!

We have successfully journeyed through the landscape of Terraform Optimization. We didn't just learn how to write Infrastructure as Code; we learned how to make it efficient, scalable, and blazing fast.

From moving our state to a Remote Backend to unlocking the speed of Parallelism, and from Modularising our logic to performing surgical strikes with Resource Targeting—you now possess the toolkit to take your DevOps game to the next level.

Remember, optimization isn't just about saving a few minutes here and there. It's about creating a developer experience where feedback loops are short, deployments are reliable, and your infrastructure can scale without becoming a bottleneck.

I hope you enjoyed this deep dive and the hands-on project. Go ahead and apply these techniques to your own infrastructure, and let me know how much time you saved on your next deployment!

If you found this guide helpful or have any questions, feel free to connect with me. I talk about Cloud, DevOps, and everything in between.

🚀 Let's Connect:

💼 LinkedIn: linkedin.com/in/pravesh-sudha

🐦 Twitter/X: x.com/praveshstwt

📹 YouTube: youtube.com/@pravesh-sudha

🌐 Website: blog.praveshsudha.com

Happy Coding and Happy Clouding! ☁️🚀

🚀 Terraform Workspaces and Multi-Environment Deployments

Pravesh Sudha — Thu, 06 Nov 2025 07:58:51 +0000

Learn How to manage Terraform Workspace and configure Multi-Environment Deployment.

💡 Introduction

Welcome to the world of Cloud and Automation, Devs!

Today, we’re going to explore one of the most powerful and widely used Infrastructure-as-Code (IaC) tools — Terraform. In this guide, we’ll learn how to use Terraform workspaces to manage multiple environments seamlessly — from Development to Staging and finally Production.

By the end of this blog, you’ll not only understand how Terraform organizes infrastructure across environments but also see it in action through a hands-on demonstration — deploying a static website on Amazon S3 with three isolated environments.

So, without further ado, let’s dive in and uncover how Terraform simplifies multi-environment deployments in the cloud.

📽️ Youtube Demonstration

💡 Prerequisites

Before we jump into the implementation, let’s make sure your setup is ready. You’ll need the following tools installed and configured on your system:

AWS CLI – Installed and configured with an IAM user that has full access to Amazon S3. If you don’t know how to do that, Follow these steps 1-3 from my Terraform Starter blog. (Just change the Permissions from EC2 to S3FullAccess)
Terraform CLI – Installed and ready to execute Terraform commands.

Once these are in place, you’ll have everything you need to follow along with the tutorial and deploy your multi-environment infrastructure.

💡 What is Terraform Workspace?

When managing infrastructure with Terraform, it’s common to work with multiple environments such as Development, Staging, and Production. Each of these environments often requires its own set of resources and configurations. To keep things organized and maintain a clean infrastructure codebase, Terraform provides a powerful feature called Workspaces.

A Terraform Workspace allows you to create and manage separate environments within a single Terraform configuration. Each workspace is associated with its own state file, which means the resources for one environment are isolated from another, even though they share the same configuration files. This makes it much easier to manage multiple deployments — all from a single codebase.

When you initialize Terraform for the first time, a default workspace named “default” is automatically created. Any infrastructure you create without explicitly switching workspaces will live in this default environment. You can then create new workspaces for different environments as needed.

Here are the available Terraform workspace commands:

terraform workspace --help

Usage: terraform [global options] workspace
  new, list, show, select and delete Terraform workspaces.

Subcommands:
    delete    Delete a workspace
    list      List workspaces
    new       Create a new workspace
    select    Select a workspace
    show      Show the name of the current workspace

Each workspace must have a unique name. When you switch between them, Terraform automatically updates the state file to match the selected workspace — ensuring your deployments remain consistent and isolated per environment.

💡 Pros and Cons of Using Terraform Workspaces

Before deciding to use Terraform Workspaces for managing your environments, it’s important to understand both their advantages and limitations. While they provide a convenient way to organize infrastructure, they may not always be the best fit for every use case — especially in large-scale or complex deployments.

✅ Pros

Single Configuration for Multiple Environments

You can manage multiple environments — like Dev, Stage, and Prod — using a single Terraform configuration. This reduces code duplication and keeps your setup clean and maintainable.
Easy Environment Switching

Workspaces come with a simple built-in command to switch between environments:
```
terraform workspace select <name>
```
This makes moving between environments effortless and consistent.
Simplifies Non-Production Environment Creation

You can easily spin up non-production environments such as Development, QA, Beta, or UAT that mirror your production setup — often as smaller, scaled-down versions.
Resource and Variable Isolation

Each workspace maintains its own state file and can have environment-specific variables, reducing the chance of misconfigurations or accidental resource overlap.
Ideal for Small to Medium Projects

For small teams or projects where environments share similar configurations, workspaces provide just the right balance of simplicity and control.

⚠️ Cons

Added Complexity for Large-Scale Infrastructure

As projects grow, managing multiple environments and configurations through workspaces can become cumbersome and harder to maintain.
Not Fully Isolated

While each workspace has its own state file, they still share the same backend configuration. Without proper management, this can lead to state conflicts or accidental cross-environment changes.
Limited for Advanced Use Cases

Workspaces aren’t ideal for multi-provider setups or situations where resources need to be shared across environments. In those cases, using separate directories or repositories for each environment is often a better approach.

💡 Practical Demonstration

Now that we’ve covered the theory, it’s time to get our hands dirty with a real-world example.

The project we’ll be working on demonstrates how to use Terraform Workspaces to deploy a static website on AWS S3for multiple environments — Dev, Stage, and Prod.

You can find the complete code for this project on my GitHub repository:

👉 GitHub – terraform-workspace-s3

Navigate to the terraform-workspace-s3 directory, and you’ll see the following files and folders:

provider.tf – Defines AWS as the cloud provider and specifies the region (us-east-1).
output.tf – Prints the website URL once deployment is complete. The output changes based on the environment.
main.tf – The core of the project. It:
- Creates an S3 bucket named pravesh-{env}-terraform-workspace-site.
- Configures it as a static website.
- Uploads two HTML objects: index.html and error.html.
- Includes configurations for ownership controls, public access, and bucket policies.
index/ – Contains three subdirectories: dev, stage, and prod.

Each folder has its own index.html file with environment-specific content.
create.sh – A shell script that automates workspace creation and resource deployment.
delete.sh – A cleanup script that destroys all created resources to prevent unnecessary AWS charges.

Inside the main.tf, we’ve set locals.env equal to the current workspace name. This dynamic link ensures Terraform automatically detects the environment (Dev, Stage, or Prod) and applies the corresponding configuration.

Once you’ve cloned the repository locally, open your terminal and run the following commands:

cd terra-projects/terraform-workspace-s3
chmod u+x create.sh
./create.sh

This script will:

Create all the required Terraform workspaces.
Apply the configuration and deploy the static website for each environment.

If you prefer, you can also run the Terraform commands manually instead of using the script.

(I ran it manually while testing, Here are some Screenshots)

After the deployment completes successfully, Terraform will output a website URL for each environment.

Open the URL in your browser — and you’ll see your static website live, hosted directly from your S3 bucket!

When you’re done testing, make sure to delete the resources to avoid unwanted charges.

You can do this easily by running the cleanup script:

cd terra-projects/terraform-workspace-s3
chmod u+x delete.sh
./delete.sh

This will remove all S3 buckets, associated objects, and delete the Terraform workspaces you created.

🧩 Conclusion

As we wrap up this project, we’ve seen how Terraform Workspaces simplify managing multiple environments like Dev, Stage, and Prod — all from a single configuration.

Instead of maintaining separate folders or repos, workspaces help isolate state files while keeping the infrastructure code consistent and scalable.

We also explored how to host a static website on AWS S3 using Terraform, learned about configuring ownership, access policies, and automating deployment across environments.

While Workspaces are great for small to medium-sized projects, they do have some limitations for larger infrastructure setups. Still, they’re a great way to get started with multi-environment IaC and understand how Terraform handles isolation through state management.

If you’ve followed along till the end, congratulations — you’ve just taken a big step toward mastering Infrastructure as Code with Terraform!

🌐 Connect with Me

If you enjoyed this guide, share it with your DevOps buddies and stay tuned for more such projects!

You can also find me sharing tech content, tutorials, and behind-the-scenes DevOps experiments here 👇

💼 LinkedIn: linkedin.com/in/pravesh-sudha
🐦 Twitter/X: x.com/praveshstwt
📹 YouTube: youtube.com/@pravesh-sudha
🌐 Website: blog.praveshsudha.com