I got tired of manually figuring out what AWS CloudFormation infrastructure needed to be promoted

Hitesh Shinde — Sun, 23 Aug 2026 02:24:04 +0000

If you work with AWS CloudFormation across multiple environments, you probably know this routine.

You have Development, Test, and Production AWS accounts.

Development is moving constantly. Test is usually a little behind. Production is further behind.

And when you're ready for a release, someone has to figure out:

What exactly changed in Dev?

Which of those changes are already in Test?

What is Test running that Prod isn't?

And most importantly:

What actually needs to be promoted?

The frustrating part is that AWS CloudFormation doesn't really answer these questions across environments. The same logical infrastructure can also have completely different stack names in different accounts. So before you can even compare them, you need to know that those stacks represent the same thing.

That was the problem I wanted to solve.

Meet PromoteOps

PromoteOps connects to your multiple AWS accounts and generates a report showing the promotion state of your CloudFormation stacks.

Instead of manually going through stacks and trying to figure out what's different, you get a clear view of what's current and what's behind.

Everything is current:

When something is outdated:

And when you need to understand exactly why a stack is considered outdated, you can inspect the CloudFormation template diff directly.

So the workflow becomes:

Report → Identify → Diff → Plan → Promote

From reporting to promotion

Once I had the ability to identify what needed to move between environments, I wanted to make the promotion itself part of the workflow.

So I built PromoteOps as an MCP server.

It exposes tools such as:

report_stacks
diff_stack
plan_stack_promotion
execute_stack_promotion

This allows an MCP-compatible AI client to interact with the infrastructure instead of treating the report as a static dashboard. You can ask what's different between environments, inspect a stack's changes, create a promotion plan, review it, and then execute the promotion. But infrastructure changes shouldn't be treated like a simple file operation. So the promotion workflow includes safeguards.

PromoteOps verifies the target environment hasn't changed since the promotion plan was created and prevents stale plans from being blindly executed.

The goal isn't to let AI blindly deploy infrastructure.

It's to give AI a structured and controlled way to understand what's happening before anything gets promoted.

The problem in one sentence

PromoteOps answers a simple question that becomes surprisingly difficult with CloudFormation across multiple AWS accounts:

What's ready to move from Dev → Test → Prod?

And once you know the answer, it can help you move it.

It's open source

PromoteOps is available on npm and GitHub:

npm: https://www.npmjs.com/package/promoteops

GitHub: https://github.com/Hitesh1326/promoteops

If you work with CloudFormation across multiple AWS accounts and this problem sounds familiar, I'd genuinely like to hear how you handle it today.

I built a VS Code extension that lets you chat with your database - everything runs locally

Hitesh Shinde — Tue, 10 Mar 2026 00:39:59 +0000

I spent a week onboarding into a project with a SQL Server database I'd never seen before. Dozens of stored procedures, no documentation, and the previous dev had left. I kept thinking — why can't I just ask this database what it does?
I couldn't find a tool that solved that specific problem, so I built one.
SchemaSight is a VS Code extension that connects to SQL Server, PostgreSQL, or MySQL, crawls your schema, and lets you ask plain English questions about it. What does this procedure do? What tables are involved in invoicing? Is there row-level security anywhere? It answers from the indexed schema itself — no live query execution, nothing leaves your machine.

How it works under the hood

When you crawl a database, the extension walks every table, view, stored procedure, and function, summarizes each one using your local Ollama model, embeds those summaries with Transformers.js (all-MiniLM-L6-v2) running entirely in Node.js, and stores everything in LanceDB.

At query time, a QueryClassifier first decides what kind of question you're asking — broad ("what is this database about?"), semantic ("what tables relate to orders?"), or a detail request ("explain this specific procedure"). Broad queries fetch all indexed chunks. Semantic queries run hybrid search — combining vector similarity and full-text search, merged and reranked with LanceDB's built-in RRF reranker. Detail requests resolve the referenced object and inject its full definition straight into the prompt.
There's also a "How this was answered" panel that shows exactly which chunks were retrieved — no black box.

A thing I got wrong early on
I tried a two-model setup: a smaller model to handle indexing summarization (faster, cheaper), and a larger one for chat. Seemed sensible.
It wasn't. The smaller model's summaries were just weak enough that the larger chat model couldn't recover from the bad retrieval context. The answers degraded in ways that were hard to debug. I scrapped it and went back to a single model for everything — llama3.1:8b as the default — with a warning if you pick something lighter. Sometimes the boring solution is the right one.

Why local-first
A lot of databases SchemaSight is built for — legacy systems, internal tooling, anything with real business logic — you genuinely can't send to a cloud API. Stored procedures often contain sensitive logic and real data shapes. Running through Ollama on your own hardware sidesteps that entirely. No API key, no subscription, no data going anywhere.

Getting started

Install and start Ollama
Install SchemaSight from the VS Code Marketplace
Add a connection and follow the onboarding flow — it walks you through Ollama verification, model pull, and schema crawl in one place

One honest caveat: initial indexing summarizes every schema object using your local LLM. On my M5 MacBook Pro with ~95 objects it takes 15–20 minutes. It's a one-time cost though — you only re-index when your schema changes or you swap models.