DEV Community: Haripriya Veluchamy

I Built an AI SEO Monitor That Remembers Everything

Haripriya Veluchamy — Fri, 10 Apr 2026 14:16:39 +0000

Most SEO monitoring tools give you a snapshot: today's clicks, today's issues, today's recommendations. You fix something, come back tomorrow, and the tool has no idea what you did or whether it helped.

I wanted something smarter a system that remembers site's history, correlates code changes with ranking shifts, and gives AI-generated insights that get better every day. Here's what I built and how.

The Problem With Basic SEO Monitoring

A typical monitoring setup looks like this:

Fetch Google Search Console data
Run a Lighthouse audit
Send a Slack message with today's numbers

That's fine. But it can't answer questions like:

"Did that metadata fix I deployed 10 days ago actually improve rankings?"
"This recommendation has been flagged for 15 days why hasn't it been fixed?"
"Clicks dropped this week was it a code change or an algorithm shift?"

To answer those questions, you need memory. That's where Cognee comes in.

What Is Cognee?

Cognee is a knowledge graph SDK. Instead of storing data as flat rows in a database, it extracts entities and relationships and stores them as nodes and edges in a graph (Neo4j) with vector embeddings in a vector database (ChromaDB).

Think of it like this: a normal database stores "clicks = 262 on April 8". A knowledge graph stores "keyword 'vibe trading' ranked at position 1.78 on April 8, which is 12 spots better than March 25, and that improvement happened 3 days after a metadata fix was deployed".

The difference matters when you want AI to reason across weeks of history not just today.

System Architecture

The full pipeline runs daily via GitHub Actions:

PHASE 1 — Parallel data collection
├── Lighthouse audit (performance, SEO scores)
├── Broken links check
├── Meta tags validation
├── Core Web Vitals (via PageSpeed API)
└── Google Search Console (clicks, CTR, position, queries)

PHASE 2 — Main analysis job
├── git-change-detector.js    → scans commits, classifies SEO-relevant changes
├── cognee_ingest.py          → writes today's data to Neo4j + ChromaDB
├── cognee-store-updater.js   → updates 30-day rolling JSON snapshot
├── audit-scraper.js          → fetches live pages, scores SEO/GEO/AEO signals
├── audit-ingest.py           → stores audit scores in the knowledge graph
├── cognee-analyzer.js        → builds enriched AI context, calls Azure OpenAI
├── send-ai-slack.js          → posts daily report to Slack
└── cognee-blob-sync.js       → backs up knowledge graph to Azure Blob Storage

PHASE 3 — Weekly (Sundays)
└── competitor-monitor.js     → fetches competitor pages, scores them, posts comparison

Why Cognee? The Knowledge Graph Advantage

Every day, cognee_ingest.py builds a structured document containing today's GSC metrics, top queries, AI recommendations, and recent git commits. Azure OpenAI reads this and extracts entities keywords, positions, dates, code changes which Cognee writes to Neo4j as connected nodes. graph starts to grow.

After 30 days, the graph contains nodes like:

(Keyword: "platform name") —[RANKED_AT]→ (Position: 1.78, date: April 8)
(CodeChange: "metadata fix") —[HAPPENED_BEFORE]→ (MetricSnapshot: April 5)
(Recommendation: "add FAQ schema") —[FLAGGED_ON]→ (Date: April 1)
(Recommendation: "add FAQ schema") —[FLAGGED_ON]→ (Date: April 2)
... (flagged 12 days in a row)

Now when the AI runs its daily analysis, it doesn't just see today's data. It sees patterns:

Keyword velocity: which keywords improved or dropped more than 5 positions in 14 days
Stuck recommendations: same issue flagged 3+ days in a row, still unactioned
Code change impact: did clicks or position change after a specific deploy?

The Slack report reflects this. Instead of "your CTR is 18.94%", it says:

"Your site has more than doubled daily clicks over the past month (106% growth), driven by a metadata fix on March 26 and header overlap fixes on March 28. Short-term momentum is slowing 7-day clicks are -3% suggesting you need to now expand content around fast-moving branded keywords."

That's a different class of insight.

The Audit Scrape SEO/GEO/AEO Scoring

Beyond GSC data, audit-scraper.js fetches your actual pages daily and scores them across three dimensions:

SEO classic signals: title tag, meta description, H1, canonical, OG tags, schema markup, JS-gated content detection

GEO (Generative Engine Optimization) how well AI search engines like Perplexity or ChatGPT Search can read and cite your content: structured data presence, content density, crawlability

AEO (Answer Engine Optimization) featured snippet and voice search readiness: FAQ schema, article schema, H2 density, word count

Each page gets a score out of 10. The system flags critical issues (JS-gated content = crawlers see a blank page, missing H1 = no primary ranking signal) and sends a separate Slack message with the audit digest.

🔴 SEO Audit — 2026-04-08
Scores: SEO 9/10 | GEO 9/10 | AEO 3/10 | Combined 21/30

Critical Issues:
🚨 missing_h1 on Pricing — Missing primary ranking signal
🚨 js_gated_content on Pricing — Crawlers see blank page

Code Change Impact Tracking

This is the part I'm most proud of. git-change-detector.js scans git commits and classifies them it looks for commit messages mentioning SEO-related terms (metadata, schema, redirect, canonical, performance, etc.) and logs them with their date.

change-impact-tracker.js then cross-references those commits with GSC metrics. For each logged change, it compares the 7-day window before vs after deployment:

✅ Migrate to new partition keys (2026-03-30)
   → Position improved 6.7 spots (17.39 → 10.71)

✅ API pagination fix (2026-03-18)
   → Clicks grew 81% (127 → 229.7/day)

⏳ content deploy (2026-03-13)
   → Monitoring... (not enough post-deploy data yet)

This surfaces directly in the Slack report under "Code Change Tracker". Over time, it tells you which types of changes actually move the needle.

Storage Architecture

Three layers, each with a different purpose:

Layer	What it stores	Why
Neo4j (Azure VM)	Graph nodes + edges — keywords, positions, code changes, relationships	Multi-hop reasoning: "which keyword improved after which deploy?"
ChromaDB (Azure VM)	Vector embeddings of all entities	Semantic search across history
cognee-knowledge.json (Azure Blob)	30-day rolling JSON snapshots	Fast daily reads without querying the graph every run

The JSON file is the workhorse for the daily Slack report. Neo4j and ChromaDB are queried for deeper pattern analysis and become increasingly valuable as history accumulates.

Key Things I Learned

Cognee initializes config at import time. If you set environment variables after import cognee, they're ignored. You have to call cognee.config.set_graph_db_config() directly after import to update the live config object. This cost me several hours.

The mistralai import conflict. Cognee's dependency instructor==1.14.x tries to import Mistral from mistralai at import time regardless of whether you use it. Fix: inject a fake mistralai module into sys.modules before importing Cognee.

JS-gated content is invisible to the audit scraper. If your page renders entirely client-side, the raw HTML fetch returns fewer than 80 words. The scraper flags this as js_gated_content — which is actually useful because it means Google probably can't index it either.

The knowledge graph gets smarter non-linearly. Day 1 the system is just a fancier GSC dashboard. Day 7 you start seeing real code change verdicts. Day 30 the AI recommendations start referencing patterns that span weeks. The value compounds.

Tech Stack

GitHub Actions — pipeline orchestration, daily cron
Node.js — audit scraper, Cognee analyzer, Slack formatting, git change detection
Python — Cognee SDK ingestion (cognee_ingest.py, audit-ingest.py)
Cognee 0.5.3 — knowledge graph SDK
Neo4j Community — graph database
ChromaDB — vector database
Azure OpenAI — GPT-4.1 for analysis, text-embedding-3-large for vectors
Azure Blob Storage — knowledge graph backup/restore
Azure VM (Standard B2s) — hosts Neo4j + ChromaDB via Docker Compose
Google Search Console API — real click/impression/position data

🚀 Beyond RAG: Simulating the Future with MiroFish

Haripriya Veluchamy — Tue, 07 Apr 2026 17:15:58 +0000

Lately, most of us have been working with RAG systems retrieving context, grounding responses, improving accuracy.

But what if instead of just retrieving knowledge, we could simulate outcomes?

I recently came across MiroFish, and decided to test it out.

🧪 What I Tried

I cloned the repo, ran it locally, and fed it a simple scenario:

“What happens when an AI assistant is introduced into a company’s daily workflow?”

Instead of a static answer, it generated a multi-agent simulation over time.

🧠 What Makes It Different

Unlike traditional systems, MiroFish:

Creates a virtual environment
Generates multiple agents (employees, managers, etc.)
Simulates interactions over time
Produces a temporal report (day-by-day evolution)

This means you’re not just asking:

“What will happen?”

You’re observing:

“How things evolve step by step.”

📊 Sample Insights from My Test

From a 14-day simulation, I observed:

📈 Initial boost in productivity
⚖️ Diverging employee satisfaction
🔁 Emerging dependency on AI
🧩 Different behaviors across teams

It felt less like querying an LLM… and more like watching a system evolve.

💡 Where This Can Be Useful

This kind of simulation opens up interesting possibilities:

🏢 Organization & Product

AI adoption strategies
Remote work policy changes
Feature rollout impact

📦 Business Decisions

Pricing experiments
Customer behavior prediction
Growth strategy testing

🌍 Macro Scenarios

Economic shifts
Supply chain disruptions
Policy or geopolitical changes

🔄 RAG vs Simulation (My Take)

Approach	What it does
RAG	Retrieves and explains existing knowledge
Simulation (MiroFish)	Models and predicts possible futures

Both are powerful but they solve very different problems.

⚡ Final Thoughts

We’re slowly moving from:

👉 “Answering questions”
to
👉 “Rehearsing decisions”

MiroFish feels like an early step in that direction.

Still experimenting, but this approach definitely opens up a new way of thinking about AI systems.

If you’ve tried something similar or have ideas for scenarios to test — would love to hear 👇

Everyone Suddenly Said “RAG is Dead”

Haripriya Veluchamy — Sat, 04 Apr 2026 13:41:22 +0000

Lately I keep seeing this everywhere:

“RAG is dead”
“Vector search is outdated”
“Reasoning-based retrieval is the future”

And suddenly… everyone is talking like vector search is useless.

I’m not against the hype. These things happen.

But honestly, this whole idea didn’t just click for me immediately.

Because for me, this problem was already in my head for a long time.

Not because of hype.

Just because of my use case.

What I Was Actually Trying to Figure Out

I read a lot of long tech blogs and architecture posts.

After reading, I always have questions like:

“why did they do this?”
“what’s the tradeoff here?”
“what happens if we change this design?”

So I wanted a system where I can:

paste a document
ask questions
actually get useful answers

At some point I started thinking:

should I just stick with vector RAG?
or should I try something like PageIndex / reasoning-based retrieval?
or even something like Agent-style flow later?

That curiosity is what pushed me to build this.

Not the “RAG is dead” trend.

So I Built a Simple Comparison

Nothing fancy.

Just a small app where:

same document
same question
same model
only retrieval changes

Pipeline 1 — Vector RAG

split document
embed
store in ChromaDB
retrieve top-k
answer

This is what most of us are already doing.

Pipeline 2 — PageIndex

build a tree structure from the document
let the model navigate it
pick relevant sections
answer from that

This felt very different.

Not “searching”.

More like… “reading with guidance”.

What I Noticed

The difference is actually deeper than I expected.

Vector RAG:

find similar chunks

PageIndex:

figure out where the answer should be, then go there

That “where” part is interesting.

One Example

I tested with a Netflix architecture article.

Question:

Why did they use live origin instead of only CDN?

Vector RAG

faster (~7s)
decent answer
but retrieval had some noise

PageIndex

slower (~11s)
answer felt more precise
citations were cleaner

My Honest Take

Vector RAG is not dead.

But…

Blind chunking + embedding + top-k is not enough anymore (at least for some cases).

Where I See the Difference

Vector RAG works well when:

you have multiple documents
you want speed
you just need “good enough” answers

PageIndex works well when:

single long document
structured content
you want cleaner reasoning

What I’m Actually Thinking Now

I don’t think this is:

“one replaces the other”

Feels more like:

both solve different parts of the problem

What I’m more interested in now is:

can I combine them?
use vector search to find documents
then use something like PageIndex inside that?

That feels more practical.

Why I’m Exploring This

For my use case, I’m also thinking about:

can I plug this into an agent flow later?
how does retrieval affect agent decisions?
does better retrieval reduce hallucination in multi-step tasks?

That’s where this is going for me.

Final Thought

Honestly, I didn’t build this to prove anything.

Just to understand.

And one thing became clear very fast:

hype says “X is dead”
reality says “it depends”

If you’re building something similar, I’d really suggest:

Don’t pick a side early.

Test both.

You’ll understand the difference immediately.

Harness Engineering: The Concept I Didn't Know I Needed

Haripriya Veluchamy — Wed, 25 Mar 2026 18:24:15 +0000

Honestly, when I first heard the term Harness Engineering, I thought it was just another buzzword.

I already knew about Prompt Engineering. I had heard about Context Engineering. I thought, okay this is probably just the same thing with a fancier name.

But then I started actually using agentic tools like Cursor and Windsurf in my day-to-day work. And something clicked.

"Wait... this thing is not just answering my question. It's planning, building, testing, fixing — all on its own. How?"

That's when I went deeper. And what I found actually changed how I think about building with AI.

First What Even is a Context Window?

Before we get into Harness Engineering, need to understand one thing.

Every AI model has something called a context window. Think of it like a whiteboard. The model can only see what's written on that whiteboard right now. Once the conversation gets too long, old stuff disappears. And when you start a brand new chat the whiteboard is completely blank.

That's the core problem:

AI has no memory between sessions. Every new session, it starts fresh.

For a simple question answer task, that's fine. But what if the task takes days?

What is Harness Engineering?

Let me show you how this concept evolved:

Prompt Engineering   → How do I ask better questions?
Context Engineering  → How do I manage what's inside one session?
Harness Engineering  → How do I make an agent work across many sessions?

Harness Engineering is not about writing better prompts. It's about designing the system around the model so the agent always knows where it is, what it has done, and what it needs to do next. Even after the context window resets completely.

The Moment I Really Got It

When I was exploring how tools like Cursor work under the hood, I realized something.

When Cursor builds a feature for you:

It scans your codebase
Makes a plan
Implements step by step
Runs tests automatically
Fixes bugs it finds
Continues without you prompting every single move

That is Harness Engineering. The tool is not just "smart." Someone designed a system that makes it stay on track even as context windows reset.

A Real Example: Building an App with an Agent

Let's say you ask an AI agent:

"Build me a complete Food Delivery App."

This is not a one-session task. Here's what happens without any harness:

Session 1:
Agent builds Login page, starts Restaurant list...
Context window fills up. Stops.

Session 2:
Agent starts fresh. No memory.
Builds Login page again. 😵
Duplicate code. Broken app. Confused agent.

Now with Harness Engineering:

Before any coding starts, an Initializer Agent sets up three simple things:

features.json — Every task with a status:

[
  { "task": "Login Page", "status": "pending" },
  { "task": "Restaurant List", "status": "pending" },
  { "task": "Cart System", "status": "pending" }
]

progress.txt — A running log:

Last completed: Nothing yet
Next task: Login Page

setup.sh — A script to spin up the dev server automatically.

Now every new session just does this:

Read progress.txt  → know where to continue
Read features.json → pick the next pending task
Run setup.sh       → environment is ready
Build → Test → Update files → Git commit
Session ends cleanly. Next session picks up exactly here.

The agent has no memory but it doesn't need memory. The system remembers for it.

The 3 Things That Actually Make This Work

1. Legible Environment

Every session should be able to answer three questions just by reading files:

What is the goal?
What is done?
What is next?

Feature lists, progress logs, git history, docs — these are not optional. They are the foundation.

2. Verification Before Moving On

Agents have a habit of saying "Done!" when things are actually broken. I've seen this personally with Claude Code and Cursor.

The fix is giving the agent real tools to test its own work like running the app, checking the UI, catching bugs end to end. Not just saying it worked. Actually proving it.

3. Use Simple, Familiar Tools

This one surprised me the most.

Vercel built a very fancy, specialized agent with custom tools and heavy prompt engineering. It worked but barely. Fragile. Slow.

Then they removed almost all the custom tools and replaced everything with one simple batch command tool.

Result? 3.5x faster. 37% fewer tokens. Success rate went from 80% to 100%.

Why? Because models like Claude have seen billions of lines of code using git, grep, npm. They understand these natively. Custom tools are unfamiliar territory.

Simple tools the model already knows > Fancy tools you built from scratch.

How This Connects to MCP

If you've worked with MCP (Model Context Protocol) before, this connects directly.

In a Harness Engineering setup:

The Host (Claude Desktop, Cursor) is your computer
The MCP Client is like an adapter built into the host, you don't touch it
The MCP Server is what you build your custom tools, your file readers, your test runners

Your MCP Server becomes the hands of your long-running agent. It reads progress files, runs tests, queries databases, and verifies work all between sessions.

You only build the server. The host handles the rest.

Common Mistakes to Avoid

Letting the agent "one-shot" the whole task it will run out of context and leave things half done
Not giving the agent a way to test its own work it will always claim success
Building overly specialized tools simpler is almost always better
No clean state at end of each session the next session will be confused

A Simple Harness Checklist

Before building a long-running agent system, make sure:

[ ] Feature list exists with pass/fail status per task
[ ] Progress file updated at end of every session
[ ] Git commits made with descriptive messages
[ ] Dev environment spins up automatically (setup script)
[ ] Agent has real testing tools not just unit tests
[ ] Generic tools used wherever possible

Final Thoughts

The models today are genuinely capable. The missing piece is almost never the model itself.

It's the system around it.

That's what Harness Engineering is. Not a new model. Not a new prompt trick. Just smart system design that lets an agent stay on track across sessions, verify its own work, and actually finish what it started.

Once I understood this, the way I think about building AI-powered tools completely changed.

If you're building anything agentic even something small think about what happens when the context window resets. Does your agent know how to pick up where it left off?

If yes, you're already doing Harness Engineering. 😊

Why Your PostgreSQL Keeps Running Out of Connections

Haripriya Veluchamy — Tue, 17 Mar 2026 17:31:11 +0000

PostgreSQL connection errors are one of those things that look terrifying when they hit production.

I used to think:
"Why is the database refusing connections?"
"Did something crash?"
"Is the server overloaded?" 😅

Recently, while working on a production system, I ran into the classic TooManyConnectionsError. Not once twice. On two different services. Same database, same root cause.

That experience helped me clearly understand why this happens and how to fix it properly.

This post is me breaking that down in a simple way, based on what actually worked.

What does TooManyConnectionsError actually mean?

In simple terms, PostgreSQL has a limit on how many connections it allows at the same time.

This limit is set by max_connections and is usually:

50–100 for small/basic tiers
100–200 for general purpose tiers

When your application tries to open more connections than this limit, PostgreSQL says no. That's the error.

The important thing to understand:

The database isn't down. It just has no room for new connections.

But I'm using a connection pool... why is this still happening?

This is the part that confused me.

I was already using a connection pool. Every tutorial says "use a pool" and I did. So why was I still exhausting connections?

Here's what I found out:

The problem wasn't that I didn't have a pool. The problem was I had too many pools.

Let me explain.

How the bug actually works

Most people write their database client class something like this:

class DatabaseClient:
    def __init__(self):
        self.pool = create_pool(min=2, max=10)

Looks clean right? Every instance gets its own pool. Professional.

But here's what happens in a real application:

Health checker creates a DatabaseClient() → pool of 10
Dependency checker creates a DatabaseClient() → another pool of 10
Each worker/task creates a DatabaseClient() → another pool of 10 each

If you have 6 workers, that's already:

10 + 10 + (6 × 10) = 80 connections from ONE container

Run 2 containers? That's 160.

Your database allows 100.

💥 TooManyConnectionsError

And the worst part? Each pool individually looks reasonable. It's only when you add them all up that it explodes.

The fix is embarrassingly simple

One process, one pool. Everything borrows from it.

Instead of each class creating its own pool, create ONE pool at the module/process level and every instance uses that shared pool.

# Created once at module level
_shared_pool = None

def get_shared_pool():
    if _shared_pool is None:
        _shared_pool = create_pool(min=2, max=5)
    return _shared_pool

class DatabaseClient:
    def get_connection(self):
        return get_shared_pool().acquire()

Now it doesn't matter how many DatabaseClient() instances you create. They all share the same 5 connections.

That's it. That's the fix.

Things I learned the hard way

Here are some gotchas that bit me:

1. The close() trap

If your client class has a close() method that closes the pool, and some other code calls it mid-process congratulations, you just killed the pool for everyone.

Make close() a no-op on individual instances. Only close the shared pool when the entire process shuts down.

2. The cascade effect

When the database runs out of connections, it doesn't just fail your query. It also fails your health check. And when the health check fails, your orchestrator thinks the container is unhealthy and might restart it. Which creates new pools. Which makes things worse.

I literally got two alerts 30 seconds apart. First one: TooManyConnectionsError. Second one: dependency_check_failed. Same container, same root cause. One bug, two pages.

3. Make pool size configurable

Use an environment variable like PG_POOL_MAX_SIZE=5. When you're debugging at 2 AM, you don't want to redeploy just to change a number.

4. Do the napkin math

Before deploying, always calculate:

pool_max_size × max_replicas < max_connections - admin_headroom

Example:

Pool max: 5
Total replicas across all services: 10
Total: 50
Database max_connections: 100
Admin headroom: 20
50 < 80 ✅

If the math doesn't work, either reduce pool sizes or put a connection pooler like PgBouncer in front of the database.

Common mistakes I see (and made myself)

Creating a new pool per class instance instead of sharing one
Not accounting for multiple services hitting the same database
Forgetting that container scaling = more pools = more connections
Not closing pools gracefully on shutdown (idle connections linger)
No rollback plan when the fix itself has a bug 😅

A simple checklist before you deploy

Before pushing connection pool changes to production:

✅ Single shared pool at module/process level
✅ Pool size is configurable via env variable
✅ close() on individual instances is a no-op
✅ Shared pool closes on process shutdown
✅ Napkin math checks out
✅ Code compiles/passes syntax check (trust me on this one 😅)

Final thoughts

Connection pool exhaustion doesn't have to be scary.

If I had to summarize everything in one line:

Many pools = trouble. One shared pool = peace.

The bug is almost never that you forgot to use a pool. It's that you accidentally created too many of them.

Once you understand this, TooManyConnectionsError stops being a 1 AM panic and becomes just another thing you know how to handle.

Hope this helps someone who just got paged for the first time because their database "ran out of connections"... 🙂

EnvHub: A Zero-Knowledge Secret Manager Built with GitHub Copilot CLI

Haripriya Veluchamy — Sun, 15 Feb 2026 16:11:25 +0000

This is a submission for the GitHub Copilot CLI Challenge

What I Built

I built EnvHub a secure, versioned environment variable manager that finally treats your .env files with the same respect as your code.

Show the Full Application flow here https://youtu.be/54do2TvHB3Y

But before I show you what it does, let me tell you why it exists.

The Problem That Kept Happening

Every developer has done this at least once:

You're working on a feature. You pull the latest code. You run the app. It breaks. You spend 30 minutes debugging only to realize someone added a new environment variable and forgot to tell the team.

Or worse: you accidentally overwrote your .env with an old version and replaced new config with outdated values. Production keys? Gone. New API endpoints? Reverted.

I've lost count of how many times this happened to me and my team:

"Hey, can you Slack me the new .env?" Insecure and lazy
"Wait, which version of the .env are you using?" Pure chaos
"Who changed the DATABASE_URL and when?" No audit trail whatsoever
"I just overwrote the new config with my old .env..." Silent disasters

We treat code with version control with Git, pull requests, code reviews. But we treat our most sensitive configuration database passwords, API keys, encryption secrets like scratch paper.

That's insane.

So I decided to build something better.

The Vision: Git, But For Secrets

I wanted a tool that worked the way developers already think:

Push your .env to a central place (like git push)
Pull it down on any machine (like git pull)
History of every change with who, what, and when (like git log)
Encrypted so even if someone accesses the storage, they can't read the secrets

And critically: Zero-knowledge architecture. I didn't want to build another SaaS where I hold everyone's secrets. That's a liability nightmare and honestly, I wouldn't trust a random developer with my production credentials either.

The solution? You deploy EnvHub to YOUR Vercel account, with YOUR storage, encrypted with YOUR keys. I literally cannot access your data even if I wanted to.

What EnvHub Actually Does

Let me walk you through the complete experience.

The Web Dashboard

When you first log in (via GitHub OAuth no new passwords to remember), you see a clean, dark-themed dashboard.

On the left sidebar, you have your Workspace Explorer. It's organized hierarchically:

📁 Project (e.g., "my-startup")
   └── 🖥️ Service (e.g., "backend-api")
       └── 🔵 Environment (e.g., "production")

Click on any environment, and you see all your variables displayed clearly keys and values visible right there, no extra clicks needed.

Want to edit? Click the edit button, and you get a full editor. You can:

Add variables individually one at a time with key-value inputs
Bulk upload paste your entire .env file content at once

Every save requires a change reason because six months from now, you'll want to know why someone changed the STRIPE_API_KEY.

Below the variables, you'll see the Version History table. Every single change is recorded:

Version	Date	User	Reason
v3	Feb 14, 2026	@harivelu0	Updated Stripe to production keys
v2	Feb 10, 2026	@teammate	Added Redis connection string
v1	Feb 1, 2026	@harivelu0	Initial setup

Click on any version to view what the variables looked like at that point in time. Full time-travel debugging. Accidentally overwrote something? Just check the previous version.

The CLI (Where the Real Power Lives)

The web dashboard is great for browsing and quick edits. But for developers who live in the terminal, the CLI is where it gets powerful.

Install it with one command:

pip install https://your-envhub-instance.vercel.app/cli/envhub_cli-2.0.3-py3-none-any.whl

Initialize it to point to your instance:

envhub init --api-url https://your-envhub-instance.vercel.app/api

Why do we need this step? Because EnvHub is self-hosted everyone deploys their own instance. Your company's EnvHub might live at envhub.mycompany.com while another team uses secrets.startup.io. The init command tells the CLI where YOUR backend lives.

Login using your existing GitHub credentials:

envhub login

This uses the GitHub CLI (gh) under the hood, so if you're already logged into gh, you're good to go. No new passwords, no separate accounts.

Now you're ready.

Push your local .env to the cloud:

envhub push -p my-startup -s backend-api -e production -r "Added new payment gateway keys"

The -r flag is the change reason required, so your team always knows why things changed. -p flag refers project name, -s refers service and -e refers environment

Pull variables to any machine:

# Print to console (great for reviewing or piping)
envhub pull -p my-startup -s backend-api -e production

# Save directly to a file
envhub pull -p my-startup -s backend-api -e production -o .env

By default, pull outputs to the console. This is intentional it lets you review what you're getting before saving it.

View the audit history:

envhub history -p my-startup -s backend-api -e production

┏━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Version ┃ Date                ┃ User        ┃ Reason                          ┃
┡━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┩
│ 3       │ 2026-02-14 09:30:00 │ @harivelu0  │ Added new payment gateway keys  │
│ 2       │ 2026-02-10 14:22:00 │ @teammate   │ Added Redis connection string   │
│ 1       │ 2026-02-01 11:00:00 │ @harivelu0  │ Initial setup                   │
└─────────┴─────────────────────┴─────────────┴─────────────────────────────────┘

New developer joining the team? envhub pull. Spinning up a new server? envhub pull. Debugging why production broke last Tuesday? envhub history.

The Security Model (I Take This Seriously)

Let me be clear about how EnvHub protects your secrets.

1. Zero-Knowledge Architecture

When you deploy EnvHub, you deploy it to your own Vercel account. Your data lives in your own Vercel Blob storage. The encryption key is your own key that you generate.

I, as the creator of EnvHub, have absolutely zero access to:

Your Vercel account
Your Blob storage
Your encryption key
Your secrets

Even if someone subpoenas me, I literally cannot hand over your data because I don't have it.

2. Encryption at Rest

Every single variable value is encrypted using Fernet (AES-128 symmetric encryption) before it's stored.

Here's what actually gets saved in Vercel Blob:

Without your ENVHUB_MASTER_KEY, those encrypted values are worthless.

3. Organization Gating

Set the ALLOWED_ORGS environment variable to your GitHub organization name, and only members of that organization can log in.

ALLOWED_ORGS=my-company,partner-org

Random person finds your EnvHub URL? They can't even access anything. Access denied.

4. Audit Everything

Every single change records:

Who made the change (GitHub username)
When they made it (timestamp)
What they changed (full variable snapshot)
Why they changed it (required change reason)

Six months later when production breaks, you'll know exactly who to ask and what changed.

How GitHub Copilot CLI Made This Possible

Here's my situation: I work in DevOps. I'm comfortable with infrastructure, CI/CD pipelines, cloud services, React, and Next.js. But building a distributable Python CLI tool? That was new territory for me.

GitHub Copilot CLI was my guide through unfamiliar terrain.

The First Conversation: "How Do I Structure This?"

I knew what I wanted to build. I didn't know how to build a proper CLI.

I asked Copilot:

"How do I create a Python CLI that can authenticate with a Next.js API using GitHub OAuth?"

Copilot gave me a clear strategy:

Use the typer library for CLI structure (modern, type-hint based)
Use the rich library for beautiful terminal output and created folder structure and initialize with code snippets
Don't reinvent auth use the GitHub CLI (gh auth token) to get the user's existing token

That last point was the key insight. Instead of building a complex OAuth flow for the terminal, I just grab the token that's already there from the GitHub CLI. Users are already logged into gh for their daily work. Why make them log in again?

def get_auth_headers(api_url):
    result = subprocess.run(["gh", "auth", "token"], capture_output=True, text=True)
    token = result.stdout.strip()
    return {"Authorization": f"Bearer {token}"}

Secure authentication in 4 lines of code.

The Battle: Cross-Platform Path Handling

My CLI worked perfectly on my Linux. Then I tested it on Windows.

Immediate crash.

The problem? I was building file paths with forward slashes (/), but Windows uses backslashes (\). When uploading to Vercel Blob, the paths were getting mangled.

I asked Copilot:

"My CLI works on Linu but fails on Windows because of path separators. How do I handle this?"

Copilot showed me how to normalize paths consistently:

from pathlib import Path

def normalize_path(path_str):
    return Path(path_str).as_posix()  # Always use forward slashes

Simple fix. Now EnvHub runs seamlessly on Windows, Mac, and Linux.

The Optimization: Smart "No-Change" Detection

Early testers reported a problem: they'd accidentally run envhub push twice and create duplicate versions with identical content. The history log was getting cluttered with meaningless entries.

I asked Copilot:

"How can I detect if the variables being pushed are identical to the current version and skip the write?"

Copilot helped me implement a comparison check on the backend:

// Check if variables actually changed
const currentBundle = await manager.getBundle(project, service, environment);
if (currentBundle && JSON.stringify(currentBundle.variables) === JSON.stringify(variables)) {
    return NextResponse.json({
        status: 'success',
        version: currentBundle.version,
        message: 'No changes detected. Version not incremented.'
    });
}

Now EnvHub only creates a new version when something actually changes. Clean history, lower storage costs.

The Encryption Decision

I knew I needed encryption at rest. I had some familiarity with the options AES, RSA, and others but I wanted to make sure I picked the right approach for this specific use case.

I asked Copilot:

"What's a good symmetric encryption approach that works in both Python and Node.js?"

The answer: Fernet.

Fernet is built on AES-128-CBC with HMAC for authentication. It's secure, widely used, and has solid libraries for both Python and Node.js. Copilot pointed me to the exact packages:

Python: cryptography library
Node.js: fernet package

# Python (CLI side)
from cryptography.fernet import Fernet
key = Fernet.generate_key()
f = Fernet(key)
encrypted = f.encrypt(b"my secret value")

// Node.js (API side)
import fernet from 'fernet';
const secret = new fernet.Secret(key);
const token = new fernet.Token({ secret, ttl: 0 });
const encrypted = token.encode(value);

The right tool for the job, implemented quickly.

The Distribution Problem

Here's a challenge I didn't anticipate: how do users install the CLI?

I couldn't publish to PyPI (the public Python package index) because each user's CLI needs to point to their specific EnvHub instance. My EnvHub lives at envhub-harivelu.vercel.app. Your EnvHub lives at envhub-yourcompany.vercel.app. We can't share the same hardcoded package.

I asked Copilot:

"How can I distribute a Python CLI where each deployment has a different backend URL?"

Copilot's solution was elegant: host the .whl file on the EnvHub instance itself.

Each deployed EnvHub instance serves its own CLI package at /cli/envhub_cli-2.0.3-py3-none-any.whl. Users install directly from their instance:

pip install https://your-instance.vercel.app/cli/envhub_cli-2.0.3-py3-none-any.whl

Then they run envhub init to configure the API URL. Decentralized, self-contained, and each team gets their own setup.

Demo

🎥 Watch the Full Walkthrough: https://youtu.be/54do2TvHB3Y

🔗 Try the Live Demo: https://env-hub-nu.vercel.app/
(Click "Continue with Demo Account" you can only access the sandboxed demo-project)

🐙 Source Code: github.com/Harivelu0/EnvHub

Screenshots

The Login Experience

Clean, dark-themed login with GitHub OAuth. No new passwords.

The Dashboard

Your entire workspace at a glance. Projects, services, environments.

Variable Editor

Add variables individually or bulk upload. Change reason required.

Version History

Full audit trail. Click any version to see that point in time.

CLI in Action

Push, pull, and history right from your terminal.

Try It Yourself (Complete Setup Guide)

Want to deploy your own EnvHub? Here's the full walkthrough.

Prerequisites

Before you start, make sure you have:

A GitHub account
A Vercel account (free tier works)
Python 3.8+ installed
GitHub CLI (gh) installed get it here

Step 1: Clone and Deploy

# Clone the repository
git clone https://github.com/Harivelu0/EnvHub.git
cd EnvHub

# Install dependencies
npm install

# Deploy to Vercel
vercel deploy

Vercel will ask you some questions. Accept the defaults. At the end, you'll get a URL like https://envhub-yourname.vercel.app.

Step 2: Create a GitHub OAuth App

Go to GitHub Developer Settings
Click "New OAuth App"
Fill in:
- Application name: EnvHub (or whatever you want)
- Homepage URL: https://envhub-yourname.vercel.app
- Authorization callback URL: https://envhub-yourname.vercel.app/api/auth/callback/github
Click "Register application"
Copy the Client ID
Click "Generate a new client secret" and copy the Client Secret

Step 3: Create Vercel Blob Storage

Go to Vercel Dashboard
Click on "Storage" in the sidebar
Click "Create Database" → Select "Blob"
Name it something like envhub-storage
Copy the Read/Write Token

Step 4: Generate Your Encryption Key

Run this command to generate a secure Fernet key:

python3 -c "from cryptography.fernet import Fernet; print(Fernet.generate_key().decode())"

You'll get something like: Sn-S2vY5W4HuScQ60IG8JXiK9aIMmC-SadbyY1NxWBY=

Keep this safe! If you lose this key, you lose access to all your encrypted variables.

Step 5: Configure Environment Variables

In your Vercel Dashboard:

Go to your EnvHub project
Click "Settings" → "Environment Variables"
Add these variables:

Variable	Value
`GITHUB_ID`	Your OAuth App Client ID
`GITHUB_SECRET`	Your OAuth App Client Secret
`NEXTAUTH_SECRET`	Run `openssl rand -base64 32` and paste the result
`NEXTAUTH_URL`	`https://envhub-yourname.vercel.app`
`BLOB_READ_WRITE_TOKEN`	Your Vercel Blob token
`ENVHUB_MASTER_KEY`	Your Fernet key from Step 4
`ALLOWED_ORGS`	Your GitHub organization name (optional but recommended)
`ALLOWED_USERS`	Your GitHub username (optional, for personal use)

Step 6: Redeploy

vercel --prod

Step 7: Install and Configure the CLI

# Install the CLI from your instance
pip install https://envhub-yourname.vercel.app/cli/envhub_cli-2.0.3-py3-none-any.whl

# Point it to your instance
envhub init --api-url https://envhub-yourname.vercel.app/api

# Login via GitHub
envhub login

Step 8: Push Your First Environment

# Create a test .env file
echo "DATABASE_URL=postgres://localhost:5432/mydb" > .env
echo "API_KEY=sk_test_12345" >> .env

# Push it to EnvHub
envhub push -p my-project -s backend -e dev -r "Initial setup"

# Verify it worked
envhub pull -p my-project -s backend -e dev

You're done! You now have a fully functional, encrypted, versioned secret manager.

The Tech Stack

Layer	Technology	Why
Frontend	Next.js 16 + React 19	Latest features, seamless API routes
Styling	Tailwind CSS 4	Fast iteration on the dark theme
Auth	NextAuth.js + GitHub OAuth	No new passwords, org gating built-in
Storage	Vercel Blob	Serverless, no database to manage
Encryption	Fernet (AES-128)	Industry standard, cross-platform
CLI	Python + Typer + Rich	Clean terminal UI, good DX

The entire backend is serverless. No database servers to maintain, no scaling headaches. Vercel Blob handles storage, API routes handle logic.

What's Next?

EnvHub is already useful for small teams, but I have plans:

Cloud-Agnostic Storage

Currently uses Vercel Blob. Some enterprises need their data in AWS S3 or Azure Blob Storage for compliance. I'm abstracting the storage layer to support multiple providers.

Enterprise Identity (RBAC)

Right now, access control is binary: you're in the allowed org or you're not. For larger teams, I want role-based access:

DevOps Lead → All projects
Backend Dev → Backend services only
Intern → Read-only on dev environments

Audit Log Export

For SOC2 compliance, security teams need to export audit logs to SIEM tools (Splunk, Azure Sentinel). Adding a one-click export feature.

Lessons Learned

1. Scratch your own itch. The best tools come from real frustration. I built EnvHub because I was tired of the .env chaos. That frustration carried me through the hard parts.

2. AI accelerates learning. GitHub Copilot CLI didn't build EnvHub for me. But it helped me learn CLI development faster than I would have on my own. I still made the architecture decisions and debugged the weird issues. Copilot just shortened the learning curve.

3. Security can't be an afterthought. It would've been easier to build EnvHub as a hosted SaaS. But zero-knowledge architecture is the right choice for a secrets tool. Your secrets should be yours.

4. Developer experience matters. A secure tool that's annoying to use gets ignored. I spent real time on the CLI output formatting and dashboard UI. Good tools should feel good to use.

Conclusion

EnvHub started as frustration with the way we handle environment variables and became a tool I'm genuinely proud of.

It solves a real problem. It's secure by design. It's open source. And building it taught me that with tools like GitHub Copilot CLI, you can pick up new skills faster than ever.

If you've ever Slacked a .env file to a teammate, or overwritten new config with old values, or spent an hour debugging a missing variable EnvHub is for you.

⭐ Star the repo: https://github.com/Harivelu0/EnvHub

🐛 Found a bug? Open an issue

💬 Questions? Drop a comment below!

Thanks for reading. Now go secure your secrets.

Canary Deployments in Azure Container Apps: A Complete Guide

Haripriya Veluchamy — Tue, 03 Feb 2026 12:36:07 +0000

Why Do We Need Canary Deployments?

Imagine you push a new update to production. Everything looked fine in testing, but suddenly your users start experiencing errors. By the time you notice, thousands of users are affected. You scramble to rollback, but the damage is done.

This is exactly what canary deployments prevent.

The Problem with Traditional Deployments

In a traditional deployment, when you push new code, 100% of your traffic immediately goes to the new version. If something breaks, all your users are affected.

Traditional Deployment:

Before:  [Old Version] ████████████ 100% traffic
After:   [New Version] ████████████ 100% traffic  ← If broken, everyone is affected!

The Canary Solution

Canary deployment gets its name from the old mining practice of bringing canaries into coal mines. If dangerous gases were present, the canary would die first, warning miners to evacuate.

Similarly, in canary deployments, we send a small portion of traffic to the new version first. If something goes wrong, only a small percentage of users are affected.

Canary Deployment:

Step 1:  [Old Version] ██████████ 90%
         [New Version] ██ 10%        ← Test with small traffic

Step 2:  [Old Version] ██████ 50%
         [New Version] ██████ 50%    ← Gradually increase

Step 3:  [New Version] ████████████ 100%  ← Full rollout after validation

How Azure Container Apps Supports Canary Deployments

Azure Container Apps has built-in support for traffic splitting through its revision system. Every time you deploy, a new revision is created. You can then control how much traffic goes to each revision.

Key Concepts

Revision: A snapshot of your container app at a specific point in time. Each deployment creates a new revision.

Traffic Weight: The percentage of traffic each revision receives. All weights must add up to 100%.

Active Revision: A revision that is running and can receive traffic.

Inactive Revision: A revision that exists but receives no traffic and consumes no resources.

Implementation: Single Region Canary Deployment

Let's build a complete canary deployment pipeline for a single-region setup.

The Deployment Flow

Push Code
    │
    ▼
Build Image (tagged with git SHA)
    │
    ▼
Save Current Stable Revision
    │
    ▼
Deploy New Revision (Canary)
    │
    ▼
Health Check (5 attempts)
    │
    ├── PASS ──▶ Split Traffic 50/50
    │
    └── FAIL ──▶ Auto Rollback + Alert

Step 1: Build and Deploy with Unique Tags

Never use the latest tag for production deployments. It's mutable and causes inconsistencies.

- name: Deploy Application
  run: |
    # Use git SHA for unique, immutable image tag
    IMAGE_TAG="${{ github.sha }}"
    REVISION_SUFFIX=$(echo "$IMAGE_TAG" | cut -c1-8)

    # Build and push with unique tag
    az acr build \
      --registry $REGISTRY_NAME \
      --image $APP_NAME:$IMAGE_TAG \
      --file Dockerfile .

    # Deploy with revision suffix for easy identification
    az containerapp update \
      --name $APP_NAME \
      --resource-group $RESOURCE_GROUP \
      --image "$ACR_SERVER/$APP_NAME:$IMAGE_TAG" \
      --revision-suffix "$REVISION_SUFFIX"

Step 2: Health Check

Before routing traffic, verify the new deployment is healthy.

- name: Health Check
  run: |
    FQDN=$(az containerapp show \
      --name $APP_NAME \
      --resource-group $RESOURCE_GROUP \
      --query properties.configuration.ingress.fqdn \
      --output tsv)

    HEALTH_PASSED=false
    for i in {1..5}; do
      if curl -sf --max-time 5 "https://${FQDN}/health" > /dev/null 2>&1; then
        HEALTH_PASSED=true
        break
      fi
      sleep 10
    done

    echo "HEALTH_PASSED=${HEALTH_PASSED}" >> $GITHUB_ENV

This tries 5 times with 10-second intervals. Why 5 attempts? Because containers need time to start, connect to databases, and warm up.

Step 3: Traffic Splitting

If health check passes, split traffic between stable and canary.

- name: Route 50/50 Traffic
  if: env.HEALTH_PASSED == 'true'
  run: |
    STABLE="${{ env.STABLE_REVISION }}"
    CANARY="${{ env.CANARY_REVISION }}"

    if [[ -n "${STABLE}" && "${STABLE}" != "${CANARY}" ]]; then
      az containerapp ingress traffic set \
        --name $APP_NAME \
        --resource-group $RESOURCE_GROUP \
        --traffic-weight ${STABLE}=50 ${CANARY}=50
    else
      # First deployment - no stable exists
      az containerapp ingress traffic set \
        --name $APP_NAME \
        --resource-group $RESOURCE_GROUP \
        --traffic-weight ${CANARY}=100
    fi

Step 4: Auto Rollback on Failure

If health check fails, immediately rollback to protect users.

- name: Auto Rollback
  if: env.HEALTH_PASSED == 'false'
  run: |
    # Route all traffic back to stable
    az containerapp ingress traffic set \
      --name $APP_NAME \
      --resource-group $RESOURCE_GROUP \
      --traffic-weight ${{ env.STABLE_REVISION }}=100

    # Deactivate broken revision to free resources
    az containerapp revision deactivate \
      --name $APP_NAME \
      --resource-group $RESOURCE_GROUP \
      --revision "${{ env.CANARY_REVISION }}" || true

    # Send alert to team
    curl -X POST "$WEBHOOK_URL" \
      -H "Content-Type: application/json" \
      -d '{"text":"Auto rollback triggered for '$APP_NAME'"}'

    exit 1

Implementation: Multi-Region Canary Deployment

For applications deployed across multiple regions, we need a sequential approach to prevent global outages.

Why Sequential Deployment?

If you deploy to all regions simultaneously and there's a bug, all regions go down together. Sequential deployment means:

Deploy to Region 1
Health check Region 1
If healthy, deploy to Region 2
Health check Region 2
Continue...

If any region fails, stop the rollout immediately.

Multi-Region Deployment Flow

Deploy to US Region
    │
    ▼
Health Check US
    │
    ├── FAIL ──▶ Stop! Don't deploy to other regions
    │
    └── PASS ──▶ Deploy to EU Region
                    │
                    ▼
                Health Check EU
                    │
                    ├── FAIL ──▶ Rollback EU, keep US on canary
                    │
                    └── PASS ──▶ All regions on 50/50 split

Multi-Region Implementation

- name: Deploy to All Regions
  run: |
    REGIONS="us eu uk"
    REVISION_SUFFIX=$(echo "${{ github.sha }}" | cut -c1-8)

    for REGION in $REGIONS; do
      APP_NAME="myapp-${REGION}-prod"

      echo "Deploying to $REGION..."

      # Deploy
      az containerapp update \
        --name $APP_NAME \
        --resource-group $RESOURCE_GROUP \
        --image $IMAGE_NAME \
        --revision-suffix "$REVISION_SUFFIX"

      # Health check this region before proceeding
      FQDN=$(az containerapp show \
        --name $APP_NAME \
        --resource-group $RESOURCE_GROUP \
        --query "properties.configuration.ingress.fqdn" \
        --output tsv)

      HEALTHY=false
      for i in {1..5}; do
        if curl -sf "https://$FQDN/health" > /dev/null 2>&1; then
          HEALTHY=true
          break
        fi
        sleep 10
      done

      if [[ "$HEALTHY" != "true" ]]; then
        echo "Region $REGION failed health check. Stopping deployment."
        exit 1
      fi

      echo "$REGION deployed and healthy"
    done

- name: Route Traffic All Regions
  run: |
    REGIONS="us eu uk"

    for REGION in $REGIONS; do
      APP_NAME="myapp-${REGION}-prod"
      CANARY="${APP_NAME}--${REVISION_SUFFIX}"

      # Get stable revision for this region
      STABLE=$(az containerapp revision list \
        --name $APP_NAME \
        --resource-group $RESOURCE_GROUP \
        --query "[?properties.trafficWeight>\`0\` && name!='${CANARY}'] | [0].name" \
        -o tsv)

      if [[ -n "$STABLE" ]]; then
        az containerapp ingress traffic set \
          --name $APP_NAME \
          --resource-group $RESOURCE_GROUP \
          --traffic-weight ${STABLE}=50 ${CANARY}=50
      fi
    done

Manual Promotion and Rollback

After the canary has been running for a while and you've validated it's working correctly, you need to promote it to 100% or rollback if issues are found.

Promotion Workflow

name: 'Canary: Promote or Rollback'

on:
  workflow_dispatch:
    inputs:
      action:
        description: 'Action to perform'
        required: true
        type: choice
        options:
          - promote-100
          - rollback

jobs:
  canary-action:
    runs-on: ubuntu-latest
    steps:
      - name: Azure Login
        uses: azure/login@v2
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}

      - name: Get Current Revisions
        id: revisions
        run: |
          REVISIONS=$(az containerapp revision list \
            --name $APP_NAME \
            --resource-group $RESOURCE_GROUP \
            --query "[?properties.trafficWeight>\`0\`] | sort_by(@, &properties.trafficWeight)" \
            -o json)

          # Highest traffic = stable, lowest = canary
          STABLE=$(echo "$REVISIONS" | jq -r 'last | .name')
          CANARY=$(echo "$REVISIONS" | jq -r 'first | .name')

          echo "STABLE=${STABLE}" >> $GITHUB_OUTPUT
          echo "CANARY=${CANARY}" >> $GITHUB_OUTPUT

      - name: Execute Action
        run: |
          case "${{ github.event.inputs.action }}" in
            promote-100)
              # Send 100% to canary
              az containerapp ingress traffic set \
                --name $APP_NAME \
                --resource-group $RESOURCE_GROUP \
                --traffic-weight ${{ steps.revisions.outputs.CANARY }}=100

              # Deactivate old stable
              az containerapp revision deactivate \
                --name $APP_NAME \
                --resource-group $RESOURCE_GROUP \
                --revision "${{ steps.revisions.outputs.STABLE }}" || true
              ;;

            rollback)
              # Send 100% back to stable
              az containerapp ingress traffic set \
                --name $APP_NAME \
                --resource-group $RESOURCE_GROUP \
                --traffic-weight ${{ steps.revisions.outputs.STABLE }}=100

              # Deactivate broken canary
              az containerapp revision deactivate \
                --name $APP_NAME \
                --resource-group $RESOURCE_GROUP \
                --revision "${{ steps.revisions.outputs.CANARY }}" || true
              ;;
          esac

Cleaning Up Inactive Revisions

Over time, you'll accumulate many inactive revisions. While they don't consume compute resources, they clutter your revision list. Deactivating revisions after promotion or rollback keeps things clean.

# Deactivate a specific revision
az containerapp revision deactivate \
  --name $APP_NAME \
  --resource-group $RESOURCE_GROUP \
  --revision "myapp--abc12345"

The || true after deactivation commands ensures the pipeline doesn't fail if the revision is already inactive.

Best Practices

1. Use Immutable Image Tags

Never use latest. Always tag images with git SHA or build number.

❌ myapp:latest
✅ myapp:a1b2c3d4e5f6

2. Start with Higher Canary Percentage for Low Traffic

If you have few users, start with 50/50. You need enough traffic on the canary to detect issues.

Low traffic:  50/50 split (need volume to detect issues)
High traffic: 10/90 split (even 10% is thousands of users)

3. Implement Proper Health Checks

Your /health endpoint should verify:

Application is running
Database connections work
Critical dependencies are reachable

4. Set Up Alerts

Always send alerts on rollback. Your team needs to know when deployments fail.

5. Use Revision Suffixes

Name revisions with git SHA prefix for easy identification.

myapp--a1b2c3d4  ← Easy to trace back to commit

Conclusion

Canary deployments are essential for safe production releases. With Azure Container Apps, you get native support for traffic splitting that makes implementation straightforward.

Key takeaways:

Deploy new code as a separate revision
Run health checks before routing traffic
Split traffic gradually (50/50 for low traffic, 10/90 for high traffic)
Auto-rollback on health check failure
Use sequential deployment for multi-region setups
Clean up inactive revisions after promotion/rollback

The initial setup takes effort, but the peace of mind knowing your deployments are safe is worth it. No more 2 AM panic calls because a bad deployment took down production.

I Fixed a Terraform State Lock Issue in GitHub Actions Here’s What I Learned

Haripriya Veluchamy — Tue, 20 Jan 2026 15:47:44 +0000

When you start running Terraform inside CI/CD pipelines like GitHub Actions, state management becomes a silent troublemaker.
Recently, I hit one of those classic issues:

Error: Error acquiring the state lock
state blob is already locked

And the pipeline refused to continue.

If you’ve ever seen this, trust me you’re not alone. Here’s exactly how it happened, how I fixed it, and what you should always remember to avoid getting stuck like this again.

❗ The Issue: Terraform State Blob Got “Leased”

Terraform uses state locking to prevent multiple processes from modifying the state at the same time.

In my case, the state was stored in Azure Blob Storage.
During a GitHub Actions run:

The job acquired a lease on the blob
The job got interrupted
The lease never got released

So when the next GitHub Actions workflow started, Terraform immediately failed with:

state blob is already locked

When I opened the Azure Blob container, the state file showed:

👉 Leased

That’s when I realized the lock was stuck at the storage level.

🔧 How I Diagnosed It

Three things told me the lock was real:

1. Terraform showed the same lock ID repeatedly

ID: 6a8f9229-xxxx
Who: runner@githubactions

2. My local `terraform force-unlock` failed

The CLI told me:

local state cannot be unlocked by another process

This showed that the lock wasn’t local it was in Azure.

3. Azure Blob Portal confirmed “Leased” status

Inside the container:

newsraag-prod.tfstate State: Leased

So the GitHub Actions runner died, but the backend still thought it was running.

🛠️ The Fix: Break the Lease Manually

The only clean solution:

👉 Break the lease directly in Azure Blob Storage

Steps:

Go to Azure Portal
Open your Storage Account
Go to Containers → open your Terraform state container
Click your .tfstate file
Choose Break Lease

Within seconds, the blob state changed to:

State: Broken

After this, I re-ran the GitHub Action it worked perfectly.

🧠 What You Should Remember (Very Important)

State lock issues happen in almost every team using Terraform.
Here are the important lessons I learned — and the practices you should follow too.

✅ 1. Never Run Parallel Terraform Jobs for the Same State

If two pipelines hit the same state file → deadlock.

Use GitHub Actions concurrency control:

concurrency:
  group: terraform-prod
  cancel-in-progress: false

✅ 2. Add Lock Timeout to Terraform Commands

Instead of failing instantly, Terraform will wait for the lock:

terraform plan -lock-timeout=300s
terraform apply -lock-timeout=300s

✅ 3. Don’t Cancel Terraform Pipelines Mid-Way

Cancelling the job leaves Azure Blob leases behind.

Let the job finish unless absolutely necessary.

✅ 4. Use Separate State Files for Each Environment

Do NOT use the same state file for dev, stage, and prod.

Example:

dev.tfstate
stage.tfstate
prod.tfstate

✅ 5. Break Lease ONLY When You’re Sure No Job Is Running

Breaking the lease while Terraform is actively writing = corrupted state.

Always confirm:

No other Terraform processes
No pipeline in progress

✨ Bonus: Recommended GitHub Actions Pattern

Here’s the workflow I now use:

concurrency:
  group: terraform-${{ github.ref_name }}
  cancel-in-progress: false

steps:
  - name: Terraform Init
    run: terraform init -lock-timeout=300s

  - name: Terraform Plan
    run: terraform plan -lock-timeout=300s

  - name: Terraform Apply
    if: github.ref == 'refs/heads/main'
    run: terraform apply -lock-timeout=300s -auto-approve

This avoids 99% of locking issues.

🏁 Final Thoughts

This issue taught me one big lesson state is the heart of Terraform, and anything that interrupts it can break the entire pipeline.

But once you understand:

how locking works
where leases get stuck
how to break them safely
and how to prevent them

…you’ll never panic when you see the “state blob is already locked” error again.

If you’re using Terraform in CI/CD pipelines, keep this checklist handy. It will save you hours of debugging.

Best Ways to Migrate a Database (What I Learned Doing It in Production)

Haripriya Veluchamy — Fri, 16 Jan 2026 13:11:38 +0000

Database migration is one of those things that sounds scary especially when it’s production data. I used to think:

“What if data is lost?”
“What if the app goes down?”
“What if I mess this up?” 😅

Recently, while working on a production system, I had to migrate a database across environments. The database wasn’t huge, but it was live. That experience helped me clearly understand which migration approach to use and when.

This post is me breaking that down in a simple, beginner-friendly way, based on what actually works in real projects.

What do we really mean by Database Migration?

In simple terms, database migration means moving data from one database to another.

This could be:

One cloud account to another
One region to another
On‑prem to cloud
Old DB to a new DB engine

The challenge is never just copying data.

The real challenge is:

How do we move data safely without breaking production?

The 4 Common Ways People Migrate Databases

From what I’ve seen, almost every migration falls into one of these categories.

1️⃣ Dump & Restore (The simplest and most common)

This is the approach most people start with.

How it works

Take a logical dump from the source database
Restore it into the target database

Examples:

PostgreSQL → pg_dump / pg_restore
MySQL → mysqldump

When this works best

Database size is small to medium
One‑time migration
A short maintenance window is okay

Why I like this approach

Very easy to understand
No extra tools required
Works almost everywhere

Downside

You need downtime

👉 If you’re new to database migration, this is the best place to start.

2️⃣ Managed Migration Tools (Cloud‑native way)

Cloud providers give managed services to handle migrations for you.

Examples:

Azure Database Migration Service
AWS Database Migration Service
GCP Database Migration Service

How it works

You give source DB details
You give target DB details
Cloud handles the data movement

When to use this

Production databases
Medium to large data
You want minimal downtime

Pros

Less manual work
Safer for production
Monitoring built‑in

Cons

Slight learning curve
Setup takes time

👉 This is what I’d pick for most production workloads.

3️⃣ Logical Replication (Advanced, but powerful)

This is where things get serious.

How it works

Source DB keeps running
Data changes stream continuously to target
Final cutover takes minutes

Best for

Large databases
Near‑zero downtime
Business‑critical systems

Trade‑off

More complex
Requires strong DB understanding

👉 Amazing when needed, but not beginner friendly.

4️⃣ Backup & Restore (Good for recovery, not migration)

Some platforms allow restoring backups directly.

Examples:

Azure point in time restore
RDS snapshots

Reality check

Mostly limited to same account
Not designed for cross‑account migration

👉 Great for disaster recovery, not real migrations.

How I Decide Which Migration Method to Use

This simple table helped me a lot:

Situation	What to choose
Small DB	Dump & Restore
Production DB	Managed Migration Tool
Large DB	Logical Replication
Recovery	Backup Restore

Common Mistakes I See (and almost made)

Migrating during peak traffic
Forgetting extensions and roles
Version mismatch between databases
No rollback plan

Trust me these things matter.

A Simple Production Migration Checklist

Before migrating, I always make sure:

Backup exists
Writes are stopped
Schema and data are migrated
Data is validated
App connection is switched cleanly

Final Thoughts

Database migration doesn’t have to be complicated.

If I had to summarize everything in one line:

Small DB → Dump & Restore
Production DB → Managed Tool
Large DB → Replication

Once you understand this, migrations stop being scary and start becoming just another engineering task.

Hope this helps someone who’s about to migrate their first production database...

Docker Compose: Orchestrating Multi-Container Applications 🧩

Haripriya Veluchamy — Wed, 14 Jan 2026 08:54:00 +0000

After working with individual Docker containers for a while, I quickly realized that most real-world applications require multiple containers working together. Managing these with individual docker run commands became tedious and error-prone. That's where Docker Compose comes in - it's been a game-changer for my workflow.

What is Docker Compose? 🤔

Docker Compose is a tool for defining and running multi-container Docker applications. With a single YAML file and a few commands, you can configure all your application's services and spin up your entire stack with one command.

Why Use Docker Compose?

Before diving into the how, let me explain why I switched to Docker Compose:

Simplicity: Define your entire application stack in a single file
Reproducibility: Everyone on your team gets the exact same environment
Service coordination: Automatic networking between containers
Environment variables: Easy configuration management
One-command operations: Start, stop, and rebuild your entire application stack

Writing docker-compose.yml Files

The heart of Docker Compose is the docker-compose.yml file. Here's a basic example:

version: '3'
services:
  web:
    image: nginx
    ports:
      - "80:80"
  db:
    image: postgres
    environment:
      POSTGRES_PASSWORD: example

Let's break down the structure:

Basic Structure

version: Specifies the Compose file format version
services: Defines the containers to be created
volumes: (Optional) Defines named volumes
networks: (Optional) Defines custom networks

Defining Services

Each service represents a container. You can configure:

services:
  web:
    image: nginx                 # Use an existing image
    # OR
    build: ./web                 # Build from a Dockerfile
    build:                       # More build options
      context: ./web
      dockerfile: Dockerfile.dev
    ports:
      - "8080:80"                # Port mapping
    environment:                 # Environment variables
      NODE_ENV: development
    env_file: .env               # Or use an env file
    volumes:                     # Mount volumes
      - ./web:/usr/share/nginx/html
    depends_on:                  # Service dependencies
      - api
    restart: always              # Restart policy

Managing Application Stacks

A Complete Example: Web App with Database and Cache

Here's a more realistic example of an application stack I might use:

version: '3'

services:
  web:
    build: ./frontend
    ports:
      - "3000:3000"
    volumes:
      - ./frontend:/app
      - /app/node_modules
    environment:
      - REACT_APP_API_URL=http://api:5000
    depends_on:
      - api

  api:
    build: ./backend
    ports:
      - "5000:5000"
    volumes:
      - ./backend:/app
      - /app/node_modules
    environment:
      - DB_HOST=db
      - REDIS_HOST=redis
    depends_on:
      - db
      - redis

  db:
    image: postgres:13
    volumes:
      - postgres-data:/var/lib/postgresql/data
    environment:
      - POSTGRES_PASSWORD=secretpassword
      - POSTGRES_USER=myuser
      - POSTGRES_DB=myapp

  redis:
    image: redis:alpine
    volumes:
      - redis-data:/data

volumes:
  postgres-data:
  redis-data:

This setup includes:

A React frontend
A backend API
A PostgreSQL database
A Redis cache
Persistent volumes for data
Environment configuration
Service dependencies

Environment Configuration

There are several ways to manage environment variables:

Inline in the compose file:

services:
  web:
    environment:
      - NODE_ENV=development
      - API_URL=http://api:5000

From a .env file:

services:
  web:
    env_file:
      - ./web.env

From the shell environment:

services:
  web:
    environment:
      - NODE_ENV
      - API_KEY

For sensitive data, I prefer using .env files that are git-ignored.

Compose Commands

Building and Running Services

These are the commands I use most often:

# Start all services
docker-compose up

# Start in detached mode (background)
docker-compose up -d

# Build or rebuild services
docker-compose build

# Build and start
docker-compose up --build

# Stop services
docker-compose down

# Stop and remove volumes
docker-compose down -v

Viewing Logs and Status

# View logs of all services
docker-compose logs

# Follow logs of a specific service
docker-compose logs -f web

# See running services
docker-compose ps

Conclusion

Docker Compose has fundamentally changed how I develop and deploy multi-container applications. What used to take dozens of commands and careful coordination can now be defined in a single file and launched with one command.

The key benefits I've experienced:

Development environments that perfectly match production
Easy onboarding for new team members
Consistent deployments across environments
Simplified local development workflow

If you're working with Docker and managing more than one container, Compose should definitely be part of your toolkit.

In the next post, I'll discuss how to move your Docker Compose setups towards production-ready deployments.

Next up: "Docker in Production: From Development to Deployment"

5 Dockerfile Misconfigurations You Should Avoid

Haripriya Veluchamy — Sun, 11 Jan 2026 16:48:33 +0000

When I started learning Docker and optimizing my containers, I realized that most of my issues weren’t about missing tools they were about how I wrote my Dockerfiles. Over time, I identified a few mistakes I repeatedly made, and I want to share them so others can avoid the same pitfalls.

0️⃣ Don’t Forget to Open Docker Desktop

When I started building images locally, I got stuck for almost a day without realizing the problem: I hadn’t opened Docker Desktop! 😅

If you’re building locally, always make sure Docker is running before you start it can save you hours of frustration.

1️⃣ Running Containers as Root

When I first ran containers, I didn’t think much about users. By default, Docker runs as root which felt convenient but was risky.

✅ What I learned:
Always create and use a non-root user inside your container.

FROM python:3.12-slim

RUN useradd -m appuser
USER appuser

WORKDIR /app
COPY . .
CMD ["python", "app.py"]

It’s a small change, but it adds a huge layer of security.

2️⃣ Using Untagged or Heavy Base Images

Early on, I would just use python:latest or big base images for convenience. The result? Bloated, unpredictable containers.

✅ What I learned:
Use versioned tags and multistage builds to keep images clean and stable.

# Build Stage
FROM maven:3.9.6-eclipse-temurin-21 AS builder
WORKDIR /app
COPY . .
RUN mvn clean package

# Runtime Stage
FROM eclipse-temurin:21-jre-alpine
WORKDIR /app
COPY --from=builder /app/target/app.jar /app/
CMD ["java", "-jar", "app.jar"]

This approach keeps your final image smaller and more predictable.

3️⃣ Using COPY . . Without Thinking

I used COPY . . in almost every Dockerfile at first. It was easy until I realized I was dragging in build artifacts, configs, and secrets by mistake.

✅ What I learned:
Be explicit about what you copy.

COPY target/app.jar /app/

A little extra effort here avoids heavier and riskier images later.

4️⃣ Splitting Updates and Installs into Separate Layers

I once ran apt-get update and apt-get install in separate RUN commands. It worked… until the cache broke during updates.

✅ What I learned:
Combine updates, installs, and cleanup in a single layer.

RUN apt-get update && \
    apt-get install -y curl vim && \
    rm -rf /var/lib/apt/lists/*

Fewer layers = cleaner cache = smaller images.

5️⃣ Installing Extra Dependencies

I used to install packages with all the extras, thinking it wouldn’t matter. It did images grew larger and the attack surface increased.

✅ What I learned:
Install only what’s necessary and clean up after.

RUN apt-get update && \
    apt-get install -y --no-install-recommends curl && \
    rm -rf /var/lib/apt/lists/*

Less clutter, more control.

🧭 Takeaways From My Docker Journey

Building Dockerfiles the right way is all about:

Least privilege (non-root user)
Minimal base images
Explicit COPY instructions
Single-layer installs
Trimmed dependencies

After applying these lessons, my containers became smaller, safer, and more predictable exactly how modern DevOps should be.

Automating Terraform Import for Existing Azure Infrastructure via Pipeline

Haripriya Veluchamy — Mon, 05 Jan 2026 13:43:00 +0000

Recently, I faced an interesting challenge while working with Terraform and Azure. I had already deployed a bunch of resources container apps, storage accounts, and more manually. Later, my team wanted to replicate this setup automatically in another Azure account using Terraform pipelines.

At first, it sounded straightforward just write Terraform code for everything, run the pipeline, and it’s done. But reality hit me hard:

How do you make Terraform aware of resources that already exist?

The Problem

Terraform relies on its state file to track infrastructure. If a resource exists in Azure but isn’t in Terraform’s state, running terraform apply will attempt to recreate it, which either fails or risks breaking things.

A few complications in my setup:

We were using a remote backend for the state (so the state wasn’t local).
Manual terraform import was not practical for dozens of resources.
We wanted the pipeline to be fully automated, without manual interventions.

At this point, I was stuck until the idea hit me.

The “Aha” Moment

I thought:

Terraform can create resources via pipeline automatically…
Why can’t I import existing resources via pipeline too?

And that’s when I realized I could automate the import process itself.

The Solution

Here’s what I did:

1. Create a Separate Import Pipeline

I wrote a dedicated pipeline that loops over existing Azure resources.
For each resource, it runs terraform import using Terraform CLI.
The state gets automatically recorded in the remote backend.

2. Sync the State

After the import pipeline runs, the Terraform state now accurately reflects all existing resources.
No more mismatch between Azure and Terraform.

3. Run the Regular Terraform Pipeline

Now, the normal pipeline (terraform apply) works seamlessly.
Terraform can manage both existing and new resources.
The setup is now fully repeatable in other Azure accounts.

Why This Matters

This approach solved multiple challenges:

Automates importing resources no manual effort.
Works with remote backends.
Ensures Terraform pipelines can manage existing and new infra seamlessly.
Makes infrastructure replication across accounts practical and safe.

Key Takeaways

Terraform Import is pipeline-friendly: You don’t need to run it manually for each resource.
Remote backend doesn’t block imports: You just need a process to sync state first.
Planning is critical: When onboarding existing infrastructure into IaC, always think about state synchronization.

This experience taught me that Terraform is incredibly flexible if you combine automation with a little bit of creativity. Sometimes, the solution is not in writing more code, but in automating the right process.

💡 Pro Tip: Always test imports on non-production environments first to avoid accidental overrides.