DEV Community: Pravesh Sudha

🤔 If Data Survives in Deployments, Why Do We Need StatefulSets?

Pravesh Sudha — Mon, 01 Jun 2026 17:56:01 +0000

Hola Amigos 👋

Welcome to the second episode of K8s with Pravesh. If you're new to the series, check out the first episode where we learned how Deployments and Services work under the hood.

Most people believe that StatefulSets are needed because Deployments lose data. But is that actually true?

In today's blog, we'll answer this question by exploring StatefulSets vs Deployments through a practical hands-on demonstration.

🚀 Getting Started

Head over to my GitHub repository, fork it under your own GitHub account, and clone the code:

git clone https://github.com/<your-username>/K8s_with_Pravesh.git

Navigate to the project directory:

cd K8s_with_Pravesh/part-02-statefulsets/configs

Here you'll find:

Secrets and ConfigMaps
Deployment manifest
StatefulSet manifest

First, apply the Secrets and ConfigMaps. These contain the MySQL password, database name, and MySQL initialization script.

kubectl apply -f secrets-and-config.yml

🧪 Experiment 1: Deployment + PVC

Now let's apply our Deployment manifest.

This file contains:

Persistent Volume Claim (PVC)
Deployment
Service

Apply it using:

kubectl apply -f deployment.yml

Once the pod is running, we'll create a sample record inside MySQL, delete the pod, and verify whether the data survives.

Get the pod name:

kubectl get pods

Connect to MySQL:

kubectl exec -it mysql-XXXXXX-XXXX -- mysql -uroot -p

Enter the password:

Pravesh

(You can change this value in the secrets-and-config.yml file.)

Inside MySQL, run:

USE crud_app;

INSERT INTO users(name,email,password)
VALUES('Pravesh','pravesh@example.com','secret');

Exit MySQL:

exit

Delete the pod:

kubectl delete pod mysql-XXXXXX-XXXX

Wait for Kubernetes to create a replacement pod:

kubectl get pods

Connect to the new pod:

kubectl exec -it mysql-XXXXXX-XXXX -- mysql -uroot -p

Run:

USE crud_app;

SELECT * FROM users;

You'll notice that the data is still there.

Wait... The Data Survived?

At this point, many people expect the data to disappear because we're using a Deployment.

However, the data survived.

So the obvious question becomes:

If data survives in a Deployment, why do we even need StatefulSets?

The answer is simple.

The data survived because we attached a Persistent Volume Claim (PVC) to the MySQL container. The PVC preserved the data, not the Deployment.

In other words:

Pod
 ↓
PVC
 ↓
Persistent Storage

The pod can disappear and be recreated, but the storage remains intact.

🧪 Experiment 2: StatefulSet

Now let's perform the same experiment using a StatefulSet.

Apply the StatefulSet manifest:

kubectl apply -f statefulset.yml

Wait for the pod to start:

kubectl get pods

You'll notice that the pod has a predictable name:

mysql-0

Connect to MySQL:

kubectl exec -it mysql-0 -- mysql -uroot -p

Insert another record:

USE crud_app;

INSERT INTO users(name,email,password)
VALUES('Pravesh','pravesh@example.com','secret');

Exit MySQL:

exit

Delete the pod:

kubectl delete pod mysql-0

Wait for Kubernetes to recreate it:

kubectl get pods

Notice something interesting:

mysql-0

The pod name remains exactly the same.

Connect again:

kubectl exec -it mysql-0 -- mysql -uroot -p

Verify the data:

USE crud_app;

SELECT * FROM users;

The data survived once again.

🤨 So What Is the Real Difference?

Let's inspect the PVCs:

kubectl get pvc

With StatefulSets, each replica gets its own dedicated PVC.

For example:

mysql-data-mysql-0
mysql-data-mysql-1
mysql-data-mysql-2

This creates a stable relationship between a pod and its storage.

StatefulSets manage a group of pods while maintaining a sticky identity for each pod. Unlike Deployments, StatefulSet pods are not interchangeable.

Each pod receives:

A stable hostname
A stable network identity
Persistent storage
Ordered deployment and termination

Even if a pod is rescheduled, it retains its identity.

When Should You Use StatefulSets?

StatefulSets are valuable when your application requires:

Stable, unique network identifiers
Stable, persistent storage
Ordered, graceful deployment and scaling
Ordered rolling updates

Common examples include:

MySQL
PostgreSQL
Kafka
ZooKeeper
Redis Clusters
Elasticsearch

Deployment vs StatefulSet

Feature	Deployment	StatefulSet
Data Persistence	✅ With PVC	✅ With PVC
Stable Pod Name	❌	✅
Stable Network Identity	❌	✅
Dedicated Storage Per Replica	❌	✅
Ordered Startup/Shutdown	❌	✅

Conclusion

A common misconception is that StatefulSets exist because Deployments cannot persist data. As we saw in this blog, that isn't entirely true.

A Deployment can preserve data just fine when paired with a Persistent Volume Claim. The PVC is responsible for data persistence, not the Deployment itself.

The real strength of StatefulSets lies in providing stable identities, predictable networking, dedicated storage per replica, and ordered deployment behavior. These features make StatefulSets the ideal choice for databases and other stateful distributed systems.

If you're running stateless applications such as frontend applications, REST APIs, or microservices, Deployments are usually the right choice. But when your workloads require stable identities and persistent state, StatefulSets become essential.

I hope this hands-on comparison helped clarify the difference between Deployments and StatefulSets.

See you in the next episode of K8s with Pravesh! 🚀

🌟 Connect With Me

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

If you found this article helpful, consider sharing it with your network and following the series for upcoming Kubernetes content.

Here's why your Prompt is WRONG 😑

Pravesh Sudha — Fri, 29 May 2026 17:48:43 +0000

The right prompt is no longer just a skill — it is becoming a necessity in this fast-paced world where almost everything is driven by AI chatbots and agents.

A lot of people think AI gives bad results because the model is not powerful enough, but in most cases, the real issue is the prompt itself.

In today’s blog, we will uncover some of the most useful AI prompting techniques that can help you write better prompts and get significantly better results.

1. Zero-Shot Prompting

This is the most common prompting technique among beginners. Almost everyone starts from this approach.

In Zero-Shot Prompting, you directly ask the AI what you need in a brief and specific way without giving any prior examples.

For example:

Instead of writing:

“Generate me a Kubernetes Deployment file”

You can write:

“Generate ONLY a Kubernetes Deployment file”

This small change cuts out unnecessary explanations, extra commands, and long guides that AI models often generate by default.

Zero-Shot Prompting works best for popular or familiar use cases where the AI already has strong contextual understanding.

Another advantage of this approach is lower token usage. In the screenshots above, you can notice that the token usage is almost 30% lower compared to longer prompts. This becomes extremely important in large organizations where APIs frequently interact with AI systems at scale.

2. Few-Shot Prompting

In this approach, before giving the actual task, we first provide the AI with a few examples.

This helps the model become context-aware and understand the expected style, structure, or format of the output.

Few-Shot Prompting is especially useful when organizations want responses to follow a particular standard rather than simply generating the “ideal” answer.

For example, if a company wants all incident reports, YAML files, or summaries to follow a fixed structure, giving examples beforehand helps maintain consistency.

For Fun: I have attached a SuperHero Example

3. Multi-Shot Prompting

Multi-Shot Prompting is very similar to Few-Shot Prompting, but instead of providing a few examples, we provide many examples for even better contextual understanding.

The advantage is usually better and more refined output quality.

However, the downside is increased token consumption because the input becomes significantly larger due to additional examples.

This is a tradeoff between output quality and cost efficiency.

4. Chain of Thought Prompting

Chain of Thought Prompting encourages the AI to break down complex reasoning tasks into intermediate steps before generating the final answer.

For example:

“Explain why this deployment failed in a step-by-step manner.”

This technique is extremely useful for debugging, analysis, problem-solving, and learning deeply about a topic instead of just scratching the surface.

It is especially beneficial for curious minds who want to understand why something happened rather than simply receiving the final answer.

5. RAG (Retrieval-Augmented Generation)

RAG is not exactly a prompting technique, but more of a workflow approach used alongside prompting.

In this method, the AI is connected to external data sources such as databases, PDFs, internal documents, or APIs.

Instead of relying solely on its internal training data, the model retrieves relevant information from these external sources before generating a response.

This helps produce more accurate, contextual, and up-to-date answers.

RAG is widely used in AI agents, enterprise chatbots, documentation assistants, and knowledge-based systems.

Final Thoughts

Writing an efficient prompt is not as difficult as it seems.

It simply involves understanding which technique works best for your specific use case.

Experiment with different prompting approaches, observe the outputs, and gradually build your own prompting style.

If you liked this blog, make sure to follow me on LinkedIn, Twitter, and YouTube where I regularly share my learnings around AI, DevOps, and technology.

Till then,

Adios 👋

🤫 Firebase Is Quietly Preparing for an Offline-First AI Future

Pravesh Sudha — Fri, 22 May 2026 17:10:50 +0000

Firebase announcements at Google I/O 2026 covered an array of products and features, but the one that grabbed my attention the most was Firebase itself. Most people are understandably focused on Gemini integrations, AI Studio, and the new SQL capabilities inside Firebase, but I believe there is something deeper happening underneath these announcements.

Firebase introduced offline caching support, which helps applications remain responsive even in little or no connectivity. Combined with local and hybrid AI inference, this suggests that Firebase is quietly moving toward an offline-first, hybrid-intelligence model.

A large number of companies are transitioning to the cloud because of the convenience of not managing physical infrastructure and data servers. However, cloud dependency comes with its own trade-offs. Heavy reliance on cloud infrastructure introduces dependence on continuous high-speed internet connectivity, recurring subscription costs, and potential vendor lock-in.

The reality is that not every place in the world has fast and stable internet connectivity. Offline caching can help reduce cloud costs while improving application responsiveness, even in low-connectivity environments.

Modern Applications Are Too Cloud Dependent

Modern applications often assume that users:

have constant internet access,
can perform fast cloud API calls with low latency,
and are always connected to online AI services.

In reality, connectivity is far from universal, especially in rural areas, trains, crowded public networks, and emerging markets such as India.

AI has further increased cloud dependence because AI applications continuously send prompts, images, voice data, and user content to remote servers. This increases:

latency,
cloud costs,
bandwidth usage,
and potential privacy concerns.

As a result, “smart applications” can quickly become fragile applications when internet connectivity is lost. AI features stop functioning, synchronization fails, and the overall user experience degrades significantly.

What Firebase Actually Announced

Firebase introduced custom resolvers, allowing developers to extend Firebase Data Connect beyond Cloud SQL and integrate additional data sources. Alongside this, realtime sync improves application UX by enabling live updates and synchronization across devices.

However, the most interesting feature, in my opinion, is offline cache support, which helps applications remain responsive even with limited or no connectivity. Firebase AI Logic also supports local inference with cloud fallback, allowing certain AI workloads to run directly on-device while heavier tasks can still rely on cloud infrastructure when required.

Additionally, Firebase AI Logic simplifies the integration of generative AI features without requiring extensive server-side setup. It supports multiple programming languages, including Kotlin, Java, Swift, and Flutter.

Taken together, these are not isolated features. Firebase appears to be gradually reducing dependence on centralized cloud execution.

Firebase Is Moving Toward an Offline-First AI Architecture

With offline caching, applications can remain usable even without network connectivity by treating local application state as a first-class component. Synchronization can happen later once connectivity is restored. This improves responsiveness, resilience, and overall application UX while reducing the frequency of frustrating “No Internet Connection” screens.

Local AI inference also changes the compute model. Instead of every AI request depending entirely on cloud APIs, certain AI tasks can now happen directly on-device. For example, in an AI-powered note-taking application, features such as summarization, translation, smart suggestions, and classification could potentially run locally without continuously communicating with remote servers.

For heavier reasoning tasks, hybrid inference becomes important. Lightweight tasks can execute locally, while more computationally intensive operations can seamlessly fall back to cloud models when necessary. This creates a distributed intelligence model where computation is shared between the device and the cloud.

Why This Matters for Emerging Markets

Many cloud-first applications are designed around assumptions that often reflect:

Silicon Valley-like infrastructure conditions,
premium hardware,
and stable high-speed internet connectivity.

However, the ground reality is very different for billions of users around the world. Many people rely on affordable Android devices and unstable mobile networks.

Hybrid architectures can help address this gap by enabling:

lower latency,
reduced bandwidth usage,
partially offline AI experiences,
and better accessibility.

This is particularly important for regions such as India, Africa, and Southeast Asia, where connectivity challenges still exist despite massive growth in smartphone adoption.

The Bigger Industry Shift

With the rapid growth of AI, the industry is gradually moving toward edge AI. Examples include:

on-device Gemini,
Apple Intelligence,
AI NPUs in smartphones,
and local LLMs.

The future of AI may not remain fully centralized. Instead, intelligence may become distributed across devices, edge systems, and cloud infrastructure working together collaboratively.

Critique and Challenges

Like any architectural shift, this approach also comes with trade-offs.

Local AI inference introduces the challenge of device fragmentation. Not all devices are capable of handling local AI workloads efficiently. On-device inference can also increase battery consumption and thermal load.

Hybrid architectures are often more difficult to monitor, debug, and optimize compared to traditional centralized cloud systems.

There is also the issue of vendor lock-in. Heavy dependence on tools such as Firebase, Gemini, and the broader Google Cloud ecosystem could limit developer flexibility over time.

Finally, local models still have computational limitations compared to larger cloud-hosted models.

Conclusion

I believe the Firebase announcements at Google I/O 2026 were not simply about adding more AI capabilities. They reflected a broader shift in how modern applications may operate in the future: less dependent on permanent connectivity, more resilient at the edge, and increasingly capable of running intelligence closer to the user.

The most important AI infrastructure trend may not be larger models alone, but the gradual movement of intelligence from centralized cloud systems toward user devices themselves.

If you liked the blog, consider sharing it among your peers and follow me on Linkedin, Twitter and subscribe to my Youtube Channel.

🚀 Democratizing Frontier AI for Bharat: Gemma 4’s Edge Capabilities in Low-Resource Environments

Pravesh Sudha — Mon, 18 May 2026 12:57:02 +0000

This is a submission for the Gemma 4 Challenge: Write About Gemma 4

How Google’s open-weight Gemma 4 models are shifting AI from a Silicon Valley luxury to a practical tool for India’s primary sector and developers working at the edge.

Introduction: The Ground Reality

India is set to solidify its position as the world’s most populous nation. Yet, even in 2025-26, around 43% of its workforce remains employed in the primary sector — agriculture, animal husbandry, and allied activities. For millions of farmers in rural Rajasthan, Haryana, or Bihar, AI is still largely an abstract, distant concept.

A mustard farmer in rural Rajasthan dealing with crop infestation or a livestock owner in a tier-3 town cannot rely on cloud-first AI. High latency, expensive USD-billed APIs, and poor or intermittent internet make frontier models inaccessible. This is where the paradigm must shift — from cloud-first to edge-first architecture.

Google’s Gemma 4 family, particularly its edge-optimized models (E2B and E4B), represents a meaningful step in that direction.

Why Gemma 4 is Different for Bharat

Gemma 4 stands out because of its intentional design for real-world constraints:

Apache 2.0 license — Fully open weights with commercial freedom.
Edge-optimized models — E2B (2.3 billion effective parameters) and E4B are built for phones, tablets, and single-board computers like Raspberry Pi.
Native Multimodal — Text + high-resolution images + audio (especially strong on E2B/E4B).
Multilingual strength — Pre-trained on over 140 languages, with strong performance on Indian languages and dialects.
Long context — Up to 128K tokens on edge models, enabling richer reasoning.

Getting started is surprisingly simple. Download the free Google AI Edge Gallery app (available on Android and iOS), select the Gemma 4 E2B model (~2.5 GB download), and you have a fully offline multimodal AI assistant on your phone. Once downloaded, it works without internet — text chat, image analysis, and voice input all run locally.

Real-World Performance: Benchmarks on Edge Hardware

Performance numbers show why this is viable for low-resource settings:

Model Size & Memory: E2B quantized (INT4/Q4) has a ~2.58 GB footprint and runs in 1.5–3 GB RAM on devices, making it accessible on mid-range smartphones and Raspberry Pi.
Raspberry Pi 5 (16GB): Prefill 133 tokens/sec, Decode 7.6–8 tokens/sec, Peak memory ~1.5 GB. This is usable for batch advice, diagnostic reports, or non-real-time assistance.
High-end Android (e.g., Samsung S26 Ultra): Decode speeds reach 47–52 tokens/sec on CPU and over 50 tokens/sec on GPU, with first-token latency under 2 seconds.
iOS Devices: Similar strong performance, especially on newer flagships.

These benchmarks prove that capable multimodal AI no longer requires expensive cloud GPUs or high-end laptops. A ₹8,000–15,000 smartphone or a ₹5,000–8,000 Raspberry Pi can now deliver practical intelligence offline.

On-the-Ground Use Cases: AI That Farmers Can Actually Use

Visual Diagnostics: A farmer points their phone at diseased leaves or livestock. Gemma 4 processes the image locally and suggests possible issues and remedies.
Voice Interaction in Mother Tongue: Thanks to strong multilingual capabilities, users can speak in Hindi, Rajasthani, Haryanvi, or other regional languages. The model understands intent without clumsy translation layers. “Kos-kos par badle paani, chaar kos par vaani” (The water changes every few miles, and the speech every fourth) — Gemma 4’s broad language coverage helps bridge this diversity.
Agentic Assistance: Beyond simple Q&A, the model supports multi-step reasoning and tool use, making it suitable for practical workflows like “Analyze this crop image, suggest next steps considering common local practices.”
Market & Supply Chain: Quick offline quality assessment of produce or basic price trend insights when connectivity returns.

These capabilities turn a regular smartphone — now owned by a large majority of the population — into a personal Krishi advisor.

The DevOps Reckoning: From Cloud Comfort to Edge Reality

As someone who has spent years in AI + DevOps, I’ve lived the cloud-native comfort zone: auto-scaling clusters, infinite compute, low-latency pipelines on AWS/GCP. That architecture collapses spectacularly when you try shipping frontier AI to rural India.

Deploying Gemma 4 at the edge forces us to relearn core principles:

1. Orchestration: Hard Limits Over Auto-Scaling

Swap EKS/GKE for lightweight solutions like K3s or Docker Compose on edge nodes. Use cgroups and strict memory caps so multimodal inference doesn’t crash the host device (critical on phones or shared village Raspberry Pi hubs).

2. Artifacts: Quantization as a First-Class CI/CD Stage

The model itself becomes the build artifact. Integrate automated INT4/INT8 quantization (using tools like llama.cpp or LiteRT) into your pipelines. Ship deltas and LoRA adapters instead of full models.

3. Delivery: Pull-Based GitOps for Sporadic Networks

Traditional push-based deployments fail offline. Design pull-based agents that sync during network windows — downloading only necessary updates or adapters.

4. New Observability

Monitor battery drain, thermal throttling, and inference latency on diverse low-resource hardware. “High availability” now means the system works when the farmer needs it most — even with zero bars of signal.

Cloud vs Edge: Indian Context Comparison

Aspect	Cloud-First Models	Gemma 4 Edge Models
Cost	Recurring API fees (USD)	One-time hardware, free inference
Internet Requirement	High	Fully offline capable
Data Privacy	Data leaves the device	Stays local
Language Support	English-first	Strong 140+ languages
Latency	Variable (network dependent)	Near-instant local
Deployment Control	Vendor locked	Full ownership (Apache 2.0)
Suitability for Rural Bharat	Limited	Purpose-built

Challenges We Must Address

No technology is perfect. Key issues include:

Risk of hallucinations in critical advice (needs verification loops or hybrid human-AI systems).
Need for domain-specific fine-tuning on Indian crop/livestock datasets.
Energy and thermal constraints on very low-end devices.
Last-mile distribution and digital literacy.

These are engineering + ecosystem problems we can solve together.

Conclusion: Engineering for the 43%

The true frontier of AI is not in multi-million dollar clusters in Silicon Valley. It is being forged at the rugged edge — in the hands of farmers, extension workers, and developers who understand local realities.

Gemma 4 won’t solve every problem overnight, but it lowers the barrier dramatically. By embracing edge-first design with open models, we shift DevOps responsibility from managing cloud bills to solving real constraints: every kilobyte, unpredictable networks, and diverse hardware.

It’s time to stop building only for the comfortable few. Frontier engineering should level the playing field for Bharat.

Let’s build for the 43%.

If you find the Article useful, make sure to share it among your socials, tagging me on Linkedin, Twitter.
Checkout my Youtube Channel

🚀 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

🎥 Practical Demonstration

🤔 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! 🚀