DEV Community: Varshith V Hegde

PawBot - An AI Desktop Puppy That Eats Your Files 🐾

Varshith V Hegde — Sat, 15 Aug 2026 09:39:22 +0000

This is a submission for Weekend Challenge: Dog Days Edition

What I Built

Remember Neko the cat and those Tamagotchi desktop pets from the 90s? I rebuilt that magic for 2026 — except your pet is a golden retriever puppy powered by an LLM.

PawBot is a Chrome extension + browser demo where a cute pixel puppy:

🐕 Roams your screen like a classic desktop pet
🏃 Chases your cursor when you get close
🍖 Eats anything you drop — PDFs, code files, emoji, pasted text
💬 Barks back with short, mood-aware responses via Google Gemini
😴 Falls asleep if you ignore it too long (with Zzz particles!)
❤️ Reacts to pets — click to pet, double-click to wave

Feed it a .pdf and it might say "Mmm, crunchy homework!" Ignore it for 40 seconds and it curls up with sad puppy eyes.

Demo

Full walkthrough on YouTube:

Quick try locally:

git clone https://github.com/Varshithvhegde/pawbot.git
cd pawbot/web
python3 -m http.server 8080
# → http://localhost:8080

Or load the Chrome extension: clone the repo → ./scripts/sync-extension.sh → Load unpacked → select the extension/ folder.

Code

Varshithvhegde / pawbot

AI desktop puppy Chrome extension — pixel pet that eats your files and barks with Google Gemini

PawBot 🐾

An AI desktop puppy that lives in your browser. A Tamagotchi/Neko-style pixel pet that roams your screen, chases your cursor, eats files & emoji you drop, and barks mood-aware responses powered by Google Gemini.

Built for the DEV Weekend Challenge: Dog Days Edition.

Demo

🎬 Watch on YouTube · 📝 DEV submission · 🔗 GitHub

Features

Feature	Description
🐕 Pixel puppy	Full sprite animations — idle, walk, run, eat, sleep, bark, wave
🍖 Feed anything	Drop files, emoji, or paste text — pup chases food then eats it
🏃 Chase mechanics	Food falls from above → pup runs to it → 4-frame eat animation
💬 AI barks	Google Gemini generates short mood-based responses
😴 Sleep mode	Ignore pup 40s → falls asleep with Zzz particles
❤️ Pet & wave	Click to pet, double-click to wave paw
⌨️ Hotkeys	`F` throw treat · `B` bark · `Esc`

…

View on GitHub

Repo: github.com/Varshithvhegde/pawbot

How I Built It

Architecture

Browser tab
    │
    ├── Content script (bundled IIFE via esbuild)
    │       └── Shadow DOM canvas overlay (immune to page CSS)
    │
    ├── Pet engine (Canvas 2D state machine)
    │       idle → walk → run → eat → sleep → bark → wave
    │
    ├── Sprite loader (33 AI-generated pixel frames)
    │
    └── Bark engine → Google Gemini API
            mood + hunger + last meal → short bark text

Technical decisions

Decision	Why
Vanilla JS + Canvas	Zero build step for the web demo; screen-recording friendly
Shadow DOM overlay	Page CSS can't hide the pup (learned this the hard way on AI Studio)
esbuild bundle	Chrome content scripts can't use ES `import` — single bundled file fixes it
AI sprite sheet	Generated pixel art, auto-sliced with a Python script into 33 transparent PNGs
Chase-then-eat flow	Food drops → pup runs → 4-frame eat animation → crumb particles
Fallback barks	Works offline without an API key; Gemini enhances when configured

Sprite animations (all 33 frames used!)

State	Sprites
Idle	4-frame breathing loop
Walk / Run	Directional left & right sprites
Eat	4-frame chew cycle + flying food emoji
Sleep	Curled up + floating Zzz particles
Mood	Happy, sad, curious, excited overlays
Bark	Shows while AI speech bubble is active
Wave	Paw idle + 3-frame wave on pet/double-click

Controls

Action	How
Feed	Drag & drop file or emoji
Feed	Paste text/emoji
Pet	Click the puppy
Wave	Double-click
Throw treat	Press `F`
Bark	Press `B`

Live hunger & happiness HUD in the bottom-left corner.

Prize Categories

✅ Best Use of Google AI

PawBot uses Google Gemini 2.0 Flash Lite — not as a chatbot, but as a personality engine for a desktop pet.

Every bark sends real context to Gemini:

Event	Context sent to Gemini	Example bark
Fed a `.py` file	`"Just ate: main.py (file)"`, mood: happy	"Python for breakfast? Bold choice."
Ignored 40s+	mood: lonely, ignoredMs: 45000	"...hello? I saved you a spot."
Poked	happiness: 85, mood: excited	"Hehe! Belly rubs detected!"
Hungry	hunger: 82/100	"Is that food? IS THAT FOOD?"

Free API key from Google AI Studio → paste in extension popup. Falls back to canned barks if no key is set.

What's next

🔊 ElevenLabs bark sounds
🐩 Multiple dog breeds
🦊 Firefox extension

Thanks for reading! If PawBot made you smile, leave a 🐾 in the comments.

Built for International Dog Day 🐕 · DEV Weekend Challenge: Dog Days Edition

[Boost]

Varshith V Hegde — Thu, 13 Aug 2026 04:03:42 +0000

Discusses URL token trade-offs and privacy catches

Varshith V Hegde

Aug 12

I Built a Notebook for Sharing Notes That Doesn't Ask You to Sign Up First

#ai #webdev #programming #productivity

14 min read

I Built a Notebook for Sharing Notes That Doesn't Ask You to Sign Up First

Varshith V Hegde — Wed, 12 Aug 2026 15:53:06 +0000

Someone asked me to share meeting notes in Slack yesterday.

I pasted the markdown. Slack ate the table. The code block lost its indentation. The task list rendered as literal [ ] characters. I spent five minutes reformatting something that already looked perfect in my editor.

So I sent a link instead.

Not to Notion — they would have to sign up. Not to Google Docs — same problem, plus I did not want this living in someone's Drive forever. Not to a pastebin — those are single blobs of text with no structure, no pages, no way to come back and fix a typo tomorrow.

I wanted: one link, multiple pages, markdown that actually renders, no account required, and a way for me to edit it later without the URL changing.

I have built sharing tools before. FreeShare for files. NotePage for single-page text. SharePad is what I wished existed when I needed something in between a pastebin and a wiki — but without the signup wall.

Live here: https://sharepad.in

Source: https://github.com/Varshithvhegde/sharepad

SharePad — Share notes with one link, no signup

Write a notebook of markdown pages and share it with a single link. Password lock, expiry dates, comments and PDF export. Free, and no account needed.

sharepad.in

The Idea

Most "share your notes" products follow the same playbook. Create an account. Verify your email. Create a workspace. Invite people. Configure permissions. By the time you are done, the meeting is over and nobody cares about the notes anymore.

SharePad skips all of that.

You write markdown. You get two links:

View link — /n/kitchen-reno — hand this out freely
Edit link — /e/{secret-token} — this is your ownership credential. Do not share it.

No account. No password to create (unless you want to lock the view link). No "upgrade to share with more people." The edit token is your identity for that notebook.

That one decision — token-based ownership instead of user accounts — simplified everything else. No auth flows. No session management. No "forgot password" for the app itself. Just a 32-byte secret generated at creation time, hashed with SHA-256, stored in Postgres, and shown to you exactly once.

What You Can Actually Do With It

Before the architecture diagram, here is what this looks like when you are actually using it.

Paste and share in ten seconds. Go to /quick, drop your markdown, get a link. Title comes from your first heading. Slug is generated automatically. Edit link lands on your clipboard. Done.

Multi-page notebooks behind one URL. This is the main thing that separates it from a pastebin. A notebook can have dozens of pages — meeting notes, appendix, todo list, reference docs — all navigable from a sidebar index. Readers see one link. You manage one notebook.

Pick your own address. At /new you can claim sharepad.in/n/kitchen-reno while you type. Taken names tell you immediately. Reserved slugs (/new, /quick, /api, etc.) are blocked so you cannot accidentally break routing.

Two levels of access. Share the view link in Slack. Keep the edit link in your password manager. Or flip on open editing and let anyone with the view link write content — useful for a shared grocery list or a retro board where you do not want people creating accounts.

Important detail: open editing lets visitors change content. Settings, expiry, password, and deletion always require the edit token. A visitor cannot lock you out of your own notebook.

Lock it down when you need to. Password-protect the view link (bcrypt hashed). Flip read-only mode. Set burn-after-read so the link works exactly once. Choose visibility: public (indexable), unlisted (link only), or private (view link blocked entirely).

Paste screenshots straight into the editor. This took longer to get right than I expected. You paste an image, it compresses in the browser, uploads to Cloudflare R2, and inserts the markdown link. More on that below.

Print the whole thing as a real document. /n/slug/print strips the handwritten aesthetic and renders every page in Source Serif — title sheet, table of contents, page breaks. Save as PDF from the browser. Handwriting disappears. It looks like something you would hand to a client, not something you scribbled on a sticky note.

It cleans up after itself. Notebooks expire in ten days by default. Push that to a year, or turn expiry off. When the timestamp passes, view links die immediately. Three days later a cron job deletes the row for real.

The Tech Stack

Next.js 16 with the App Router and Turbopack. Server components for the initial notebook load, client components for the editor. The split view, auto-save, scroll sync, and toolbar all live in a single NotebookEditor component that handles both view mode (/n/slug) and edit mode (/e/token).

Supabase Postgres for everything persistent. Notebooks, pages, version history, comments, image metadata, rate limit counters. Row-level security is enabled on every table, but there are no public write policies — the server talks to Postgres through the service role key. The anon key exists because Supabase expects it, but the app does not expose direct client writes.

Tailwind CSS 4 for styling, but the visual identity is deliberately not a generic SaaS dashboard. Kalam and Architects Daughter for handwriting. A red margin rule down each page. Taped sticky-note cards on the home page. I wanted it to feel like paper, not like yet another AI product with a purple gradient hero section.

react-markdown with remark-gfm for GitHub-flavoured markdown, rehype-highlight for code blocks, rehype-raw for inline HTML, and rehype-sanitize before anything hits the DOM. That last one is not optional — more on why in a minute.

Cloudflare R2 for images. I chose R2 over Supabase Storage because egress is free at any volume. Supabase's free tier shares egress between database and storage — one viral notebook with screenshots could take the whole app down. R2 charges nothing for egress, ever.

PostHog for analytics, optional and heavily restricted. Autocapture off. Session recording off on notebook routes. No note content, titles, slugs, or edit tokens in any event payload. An edit token is a write credential — putting one in analytics would hand notebook control to a third party.

GitHub Actions for two cron jobs: ping Supabase every three days so the free project does not pause, and sweep orphaned images from R2 weekly.

How Ownership Works (Without Login)

There is no users table. There is no signup form. Here is the full auth model:

Create notebook
  → server generates edit_token (32 random bytes)
  → stores SHA-256(edit_token) in notebooks.edit_token_hash
  → returns edit_token to the browser once
  → browser saves it in localStorage for "Saved notebooks" on the home page

View:  GET /n/{slug}           → anyone (unless password/expired/private)
Edit:  GET /e/{edit_token}     → validates token hash → full editor
Write: POST/PATCH/DELETE /api/* with X-Edit-Token header

Password-protected notebooks add one step:

POST /api/notebooks/unlock/{slug}  { password }
  → bcrypt compare
  → sets httpOnly cookie sp_unlock_{slug} for 24 hours

The edit token never appears in URLs on the view route. The view route never accepts writes unless open editing is enabled. Settings always require the token.

I have shipped products with full auth before. For this use case, accounts would have been pure friction. The edit link is the account.

The Editor

The editor is a textarea and a preview pane. That is intentionally boring technology.

Split view with scroll sync. Write on the left, preview on the right. Scroll one, the other follows. On mobile it collapses to write-only because split view on a phone is unusable.

Toolbar actions participate in undo. This was a subtle bug for a while. Typing supported Ctrl+Z fine, but clicking "bold" or "insert code block" did not — because I was replacing textarea.value directly, which bypasses the browser's undo stack. Fix: document.execCommand("insertText"). Yes, it is deprecated. It is also still the only way to get undoable programmatic edits in a plain textarea without building a full ProseMirror instance. I am not building ProseMirror for a side project.

Tab actually indents. Default browser behaviour moves focus to the next button. SharePad intercepts Tab and inserts two spaces (or indents a whole selected block). Shift+Tab outdents. Esc+Tab is an escape hatch if you genuinely need to tab to the next UI element.

Version history. Every page keeps its last ten drafts. Open history, pick an old version, restore it. Snapshots happen server-side on content change, not on every keystroke — the auto-save debounce would otherwise generate hundreds of useless versions.

Page templates. Meeting notes, project brief, weekly plan, journal entry. One click adds a pre-filled page with sensible headings.

Images (and the Bug That Only Bit Real Photographs)

Paste a screenshot. It should just work.

The flow:

Browser compresses the image — max 1600px edge, re-encoded as WebP at 82% quality. A phone screenshot typically shrinks by 10x before it ever hits the network.
Server sniffs magic bytes (not the declared Content-Type, which the uploader chooses and proves nothing).
Object stored in R2 under {notebook_id}/{random-hex}.{ext}.
Row inserted in the images table.
Markdown link inserted: ![alt](https://pub-....r2.dev/...)

Limits: 5 MB after compression, 50 images per notebook, 60 uploads per IP per ten minutes. Rate limiting runs in a single Postgres statement so two simultaneous uploads cannot both read the old count and slip through.

The bug that wasted an afternoon: small pasted images worked. Large ones failed with "The image store did not accept that file."

Node's fetch switches to chunked transfer encoding once the body passes a certain size. Cloudflare R2 answers a PUT without an explicit Content-Length with 411 Missing ContentLength. Small images fit in one chunk and happened to work. Real photographs did not.

Fix was one header:

headers: {
  "Content-Type": contentType,
  "Content-Length": String(body.byteLength),
  "Cache-Control": "public, max-age=31536000, immutable",
}

I also learned that drawing an animated GIF to a canvas keeps the first frame and silently kills the animation, so GIFs pass through uncompressed. And that a placeholder of ⏳ uploading image 1… beats inserting ![]( ) with an empty src, which makes the browser try to reload the entire page.

HTML in Markdown (and Why Sanitising Is Not Optional)

SharePad renders raw HTML inside markdown — <details>, <kbd>, <mark>, <abbr>, table alignment attributes. Useful for collapsible sections and keyboard shortcuts.

It also sanitises everything against GitHub's schema before rendering. Scripts, styles, iframes, objects, forms, event handlers, javascript: URLs — all stripped.

Why this matters: open editing lets anyone with the view link write into the notebook. Without sanitisation, a visitor injects a script. The script runs on the owner's browser when they open the edit link — where the edit token is sitting in the URL and every saved token is in localStorage. One malicious notebook and you hand over every notebook that browser has ever created.

The allowed set lives in lib/markdown-schema.ts. I added a few presentational tags on top of GitHub's defaults. I did not relax anything about scripts.

Expiry (and the Grace Period Nobody Asked For But Everyone Needs)

Choosing "10 days" stores an absolute timestamp, not a rolling countdown.

Timeline:

Expiry moment — view and print links return 404. Readers are locked out immediately.
Three days later — pg_cron deletes the notebook row. Pages, versions, comments cascade away.
Burn-after-read — deleted one day after the single view.

The three-day gap between "readers locked out" and "row deleted" is deliberate. The owner can still open the edit link during that window and push the expiry date back. Immediate hard delete on expiry would mean one missed calendar reminder and your notes are gone with no recovery path.

select cron.schedule(
  'purge-expired-notebooks', '15 3 * * *',
  $$select public.purge_expired_notebooks()$$
);

Deleting a notebook through the app clears its R2 images immediately. Expired notebooks rely on a weekly sweep that lists the bucket, checks which notebook IDs still exist in Postgres, and deletes the orphans.

Some Honest Pain Points

Hydration mismatch on dates. toLocaleDateString() rendered 11/08/2026 on the server and 8/11/2026 on the client. Classic. Fixed with explicit en-GB formatting in a shared utility so server and client agree.

The red margin line floating in the wrong place. On wide screens the margin rule was anchored to a full-width container while the text sat in a centred column. Huge gap between the red line and the words. Fix: move the margin rule inside the text column wrapper so it hugs the content regardless of viewport width.

CSS specificity vs Tailwind. The .sk paper-card class had position: relative in global CSS. Tailwind's absolute on dropdown menus lost the cascade battle. Menus clipped to a one-pixel sliver. Fix: wrap menus in a plain div with inline positioning, move .sk into @layer components so utilities win.

Delete notebook did not redirect. The API returned 200, the notebook was gone, but the user sat on a dead /e/{token} page staring at a frozen settings modal. router.push("/") was a soft navigation that did not fully tear down the editor. Fix: window.location.replace("/?deleted=1") — hard leave, no back button to a ghost URL.

Rate limit too tight on images. Twenty uploads per ten minutes sounded reasonable in a spreadsheet. In practice, illustrating a doc means a dozen screenshots in five minutes. Bumped to sixty. The per-notebook cap of fifty is what actually limits abuse; the IP limit just stops someone using the service as a free image host across hundreds of notebooks.

Supabase free tier pauses after seven days idle. A GitHub Action pings /api/ping every three days. Boring infrastructure, but a paused database is a dead app.

SEO (Because Nobody Searches "SharePad")

They search "share markdown without signup." "Online notepad no login." "Send notes without account."

So there are landing pages for each phrase — /share-markdown-without-signup, /online-notepad-no-login, /markdown-to-pdf — with actual content, not keyword stuffing. Plus llms.txt and llms-full.txt for the crawlers that read those now. Sitemap, robots.txt, FAQ schema on the home page. The brand name does not matter for discovery. The landing pages do.

Running It Yourself

git clone https://github.com/Varshithvhegde/sharepad.git
cd sharepad
npm install
cp .env.example .env.local
# Fill in Supabase keys
npm run dev

Apply the SQL migrations in supabase/migrations/ in order — six files, from initial schema through images and rate limits. Supabase CLI: supabase db push. Or paste each file into the SQL editor manually.

Minimum env:

NEXT_PUBLIC_SUPABASE_URL=https://your-project.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=...
SUPABASE_SERVICE_ROLE_KEY=...
NEXT_PUBLIC_SITE_URL=http://localhost:3000

Image upload stays off until all five R2_* variables are set. The app runs fine without them — you just cannot paste screenshots.

Deploy anywhere Next.js runs. Vercel is the path of least resistance. Set NEXT_PUBLIC_SITE_URL to your real domain in production.

Full setup docs: github.com/Varshithvhegde/sharepad

Try It

Live: sharepad.in

Quick path: sharepad.in/quick — paste markdown, get a link

Full create: sharepad.in/new — custom slug, paper texture, font, expiry, password

Recover a lost edit link: sharepad.in/recover

Varshithvhegde / sharepad

Share multi-page markdown notebooks instantly — no signup, no login

SharePad

Write a notebook of markdown pages and share it with a single link. No signup, no login.

What it does

Multi-page notebooks behind one address, with a tabbed page index
Paste and share — drop text in, get a link back, title and address chosen for you
Your own address — /n/kitchen-reno, checked for availability as you type
Expiry — 10 days by default, adjustable up to a year or off entirely
Two links — a view link to hand out, a secret edit link you keep
Open editing — optionally let anyone with the link write in it too
Password lock, read-only mode, and burn-after-reading
Version history — the last ten drafts of every page, restorable
Comments from readers, no account required
PDF export — the whole notebook as a clean document, no handwriting
Markdown export and .md import
Paper and typeface — ruled, grid, dotted…

View on GitHub

If something breaks, open an issue. I read them.

The thing I keep coming back to is how much friction we accept as normal. Sign up. Verify email. Create a workspace. Configure sharing. For notes. Most of the time you just want to hand someone a link and move on with your day.

SharePad is my attempt to make that link worth opening — proper markdown, multiple pages, a print view that does not embarrass you, screenshots that paste inline, and an expiry date so old notes do not haunt you forever.

If you build something on top of it, or fork it and take it somewhere I did not think of, I want to see it. Drop a comment or ping me on dev.to.

And if you have ever lost meeting notes because Slack mangled your table formatting — same. That is literally why this exists.

I Built a Chat App That Rewrites Its Own UI in Real Time

Varshith V Hegde — Tue, 28 Jul 2026 18:35:05 +0000

So I had this idea that kept nagging at me.

Every AI chat app works the same way. You type something, the model returns text or markdown, the UI renders it as a nice formatted paragraph. That is fine if you want an answer. It is genuinely boring if you want to actually build something.

What if the AI could respond with a working game board you could click? What if saying "make it Barbie themed" actually transformed the whole interface while you watched? What if "add a starfield in the background" dropped an animated canvas behind your chat in real time?

I spent a few weeks building exactly that. I call it FlowChat.

Here is the live version: https://flowchat-public.varshithvh.workers.dev

And yes, someone immediately asked it to play Tic Tac Toe and then asked it to switch to an Oppenheimer theme mid-game. I could not be prouder.

The Idea

Normal AI chat: model returns markdown, client renders it as text. Simple, predictable, boring.

FlowChat: model returns raw HTML with CSS and JavaScript, client injects it directly into the DOM using a streaming protocol built on the browser's native template system.

That one change makes the entire experience different. You are not reading about a game. You are playing one. You are not reading about a Barbie color palette. You are sitting inside one.

The AI does not just answer questions. It rebuilds the UI from its responses.

What You Can Actually Do With It

I want to give you a feel for what this means in practice before getting into the technical bits, because the demos are more interesting than any architecture diagram.

Games: Ask it to build Tic Tac Toe. You get a playable board, click-to-move, an AI opponent, win detection. Ask for Connect 4. Ask for Snake. The game renders in the chat as an agent bubble with a form inside it. Each move submits to the LLM which processes it and updates only the cells that changed.

Themes: Say "change to a Barbie theme". The model injects CSS overrides and the whole interface turns pink. Messages, borders, buttons, the prompt box. Say "Oppenheimer themed". You get dark sepia tones and heavy typography. The sidebar and topbar stay locked so the shell never breaks, but everything inside the chat transforms.

Backgrounds: Say "add a starfield". An animated canvas renders behind your messages. Say "DVD bounce animation". The logo bounces around the chat viewport. Say "use a space image". An image fills the background. All of this lives in a contained layer so it never covers the actual UI.

Full interface takeover: At one point I asked it to make the page look like Wikipedia. It replaced the prompt box with links. Clicking any link submitted a form back to the LLM which generated a new article replacing the chat content. I was reading about the Roman Empire in a chat app I built on a Sunday afternoon.

The Tech Stack

Everything runs on Cloudflare's edge infrastructure. No traditional server. No Node.js process to keep alive. No managed database to worry about.

Cloudflare Workers runs the TypeScript on every request. Cold starts are under 50ms globally. The whole worker is one file that handles routing, auth, rate limiting, WebSocket upgrades, and LLM streaming.

Cloudflare Durable Objects is the part that makes this work. Each chat room is a single Durable Object: a stateful actor with its own SQLite database, its own in-memory queue, and its own WebSocket connections. When you and a friend open the same chat URL, you both connect to the same DO. Sync is not something you have to build. It is just how the architecture works.

Each DO stores:

The full LLM message history in SQLite
Client session records
A queue of pending prompts (max 5)
Rate limit state per browser/IP
A fork index for read-only snapshots

Hibernatable WebSockets keep connections alive without keeping the DO alive. Cloudflare auto-handles ping/pong. The DO wakes up when a message arrives and goes back to sleep between them.

better-auth handles optional authentication. If you do not configure it, the app is open to everyone. If you do, you get Google, GitHub, and email/password with role-based access (admin, dev, chat, view, blocked).

Inception Labs Mercury-2 is the model powering responses. It is a diffusion-based language model rather than autoregressive, which means it generates differently to GPT or Claude. In practice it feels fast and it seems to genuinely understand the HTML output format I need from it.

The Protocol

This was the most enjoyable part to design and the part I am most proud of.

The AI cannot just dump raw HTML into a response stream. A single response might need to update three different parts of the page independently. A Tic Tac Toe move should update one cell, not redraw the entire board. A background animation should not affect the sidebar. A private message to one player should not appear in the other player's chat.

So I built a delimiter-based streaming protocol. The model wraps every DOM update in a structured envelope:

PpqUtcLGQdYN4oqc:BODY_START
<template for="/chat/append-message">
  <div class="message message-user" data-client-id="1">Lets play Tic Tac Toe</div>
  <div class="message message-agent message-full-width" id="msg-1">
    <!-- entire game board HTML -->
  </div>
  <?marker name="/chat/append-message">
</template>
PpqUtcLGQdYN4oqc:BODY_END

The for attribute on the template targets a named marker in the DOM. The client runtime walks the document tree looking for processing instructions with matching names and replaces them with the template content. Surgically. Without touching anything else on the page.

A single AI response can contain multiple messages separated by a split delimiter:

PpqUtcLGQdYN4oqc:SPLIT_MESSAGE

So the model can send a public chat confirmation to all users AND simultaneously route a private message to only one player by including SERVER_PROPS routing instructions that the server strips before forwarding over WebSockets.

The whole thing is built on two browser polyfills that implement the Dynamic Partial Update spec that is landing in Chrome.

Writing the System Prompt

Getting the AI to consistently produce valid HTML inside this protocol format took a lot of iteration. The final system prompt is about 300 lines and honestly reads more like an API contract than a prompt.

It covers the exact hex values of every CSS variable in the design system so the model writes var(--accent) correctly instead of guessing colors. Rules for border-radius, shadow values, animation timing. The async CDN loading pattern for Chart.js and d3, because the model kept calling new Chart() before the library loaded.

The biggest bug I chased was this one: the model kept placing the append-message marker inside the app container div instead of after it. Every subsequent chat message would inject into the game board. I fixed it with a wrong-vs-correct example in the prompt:

<!-- WRONG: marker inside app div, next message injects here forever -->
<div id="ttt-app-1">
  ...board...
  <?marker name="/chat/append-message">
</div>

<!-- CORRECT: marker after ALL divs close -->
<div id="ttt-app-1">
  ...board...
</div>
<?marker name="/chat/append-message">

Wrong examples with explicit comments are more useful than correct-only documentation. The model needs to know what the failure mode looks like, not just the happy path.

I also learned that diffusion models like Mercury-2 need slightly different prompting than autoregressive models. The responses feel less like a typewriter and more like content materializing. It pairs naturally with this use case.

Multi-User by Default

Every chat URL is shared. Open the same link in two browser tabs and both receive every AI response over WebSockets in real time. Each client gets a unique ID. User bubbles are color-coded per client.

The LLM knows each client's ID:

[1]: I want to guess a secret word
[2]: I want to give the hint

The model can respond with one message visible to both players and a second message containing the secret visible only to client 1. Routed server-side, stripped from WebSocket payloads before they reach the wrong browser.

I did not add any special multi-user logic. The Durable Object architecture just makes it work naturally. Every client connects to the same DO instance. The DO has the WebSocket connections. When the LLM responds, the DO broadcasts to all of them.

The UI

Pure CSS. No framework, no Tailwind, no component library. Inter font loaded non-blocking, a deep navy palette (#06091a to #101630), periwinkle indigo accent (#5b6ef5).

The app shell is a sidebar plus a main area with topbar. The sidebar and topbar are always physically opaque. The chat viewport is the only zone where themes and backgrounds can render. This prevents the AI from accidentally covering the navigation with a space photo, which it absolutely would do otherwise. I know because it did, many times, before I fixed the containment.

.chat-viewport {
  position: relative;
  isolation: isolate;
}

#fc-bg-layer {
  position: absolute;
  inset: 0;
  z-index: 0;
  pointer-events: none !important;
}

.chat {
  position: relative;
  z-index: 2;
}

The background layer sits at z-index 0. Chat messages sit at z-index 2. The sidebar and topbar are separate elements outside the viewport entirely. Structural containment beats trying to enforce it with !important and MutationObservers, which I tried first and which caused an infinite loop that froze the whole page. Lesson learned.

Typing indicator, optimistic user bubbles, spring entrance animations on messages. The send button has a glow. It is small things but they add up.

Some Honest Pain Points

The model marker placement bug took two days to properly fix because the issue was invisible until the second message arrived. The first message always looked correct.

The background containment wars took about a week of back-and-forth. I tried CSS !important, then a MutationObserver enforcer, then a JS-level background lock. All of them broke something else. The right answer was structural: move the background layer inside the chat viewport so it is physically impossible for it to escape.

CDN script loading trips up every AI-generated app. The model writes code that calls Chart.js APIs before the library loads. The fix is teaching it to poll:

function init() {
  if (typeof Chart === 'undefined') { setTimeout(init, 50); return; }
  // safe to use Chart here
}
init();

That pattern is now baked into the system prompt and it works reliably.

The form action URL bug was embarrassing. The form action in app.html was c/CHAT_ID/prompt (relative) instead of /c/CHAT_ID/prompt (absolute). On a fresh load the path resolved correctly. After a redirect it did not. Every prompt submitted to /c/c/CHAT_ID/prompt and got a 404. I caught it from the server logs and added a global form submit interceptor that normalizes any relative action URL before submission, as a safety net for AI-generated forms too.

Deploying

The whole thing runs on Cloudflare's free tier. One command:

npx wrangler deploy --env public

No Docker. No server to provision. No database UI to configure. Cloudflare handles scaling, WebSocket hibernation, global distribution, and the SQLite storage inside each Durable Object automatically.

Secrets like the API key are stored via Wrangler:

npx wrangler secret put INCEPTION_API_KEY --env public

They never touch the codebase or version control.

Try It

Live: https://flowchat-public.varshithvh.workers.dev

Source: https://github.com/Varshithvhegde/flowchat

Open a new chat. Type anything. Ask it to build a game, change the theme, add a background, or make the page look like something completely different. It will.

Varshithvhegde / flowchat

Multi-user AI chat that generates live HTML UI — games, dashboards, apps — powered by Cloudflare Workers + Durable Objects

FlowChat

A multi-user AI chat where the model responds with live HTML instead of markdown. Every reply can be a game, dashboard, animated background, interactive form, or a full UI redesign — running directly in the browser.

Live demo: https://flowchat-public.varshithvh.workers.dev

What it does

The AI responds with raw HTML, CSS, and JS — not markdown
Updates are injected into the page using a streaming partial-update protocol
Multiple users on the same URL see updates in real time over WebSockets
The AI can target specific parts of the page independently (update one game cell, not the whole board)
Style themes, background animations, and full interface redesigns all work via CSS marker injection
Each chat room is a Cloudflare Durable Object with its own SQLite storage and WebSocket connections

Stack

Layer	Technology
Runtime	Cloudflare Workers
State + WebSockets	Cloudflare Durable Objects
Storage	SQLite (via Durable Object storage)
Auth (optional)	better-auth
AI Model

…

View on GitHub

The thing I keep coming back to is how much of this was just moving one assumption. Instead of "the AI returns text and the UI renders it", it became "the AI returns HTML and the browser runs it". That one change opened up everything else.

If you have questions about the protocol, the Durable Objects architecture, or the system prompt engineering, ask in the comments. I spent a lot of time on all three and I am happy to go deeper on any of it.

And if you build something interesting with it, or fork it and take it somewhere I did not think of, I genuinely want to see it.

You can also find me on LinkedIn and Dev.to. I write about things I am actually building, not things I think I should be building. There is a difference.

I Built a Graveyard for My Dead Side Projects - With AI Eulogies & a 3D Cemetery

Varshith V Hegde — Sun, 12 Jul 2026 12:23:59 +0000

This is a submission for Weekend Challenge: Passion Edition

What I Built

Every developer has a graveyard of side projects — started with fire, abandoned quietly on a Tuesday. They deserved better than an empty GitHub repo gathering digital dust.

DevGraveyard is a gothic memorial platform where developers give their abandoned passion projects a proper burial. Connect your GitHub, pick a dead repo, carve its epitaph — and watch Gemini AI write a dramatic breakup letter from you to the project.

Here's what it does:

⚰️ Bury a project — 3-step burial wizard: pick a repo → choose cause of death ("Never Made it Past Localhost", "Ran Out of Weekend", "It Was Complicated"...) → write an epitaph
🪦 Real tombstone data — pulls your actual commit history: peak obsession streak, most commits in a single day, last commit message (your final words)
🤖 AI Eulogy — Google Gemini writes a dramatic breakup letter from you to the project, referencing your real commit data
🕯️ Community mourning — light candles, leave RIP messages, vote to resurrect projects
🌐 3D Graveyard — a full Three.js interactive cemetery: bare trees, fireflies, flickering candles, soul wisps, resurrection pulse rings. Click any tombstone to interact

My own ARweave repo had 56 commits, a 2-day peak streak, 30 commits on its best day. Cause of death: "Never Made it Past Localhost." Last words: "feat: overlay plane in 3D builder — drag/scale image on marker, position saved to DB and restored in AR viewer."

It worked until it worked.

Demo

🔗 Live → devgraveyard.varshithvhegde.in

Code

Varshithvhegde / devgraveyard

Give your abandoned passion projects a proper burial. A gothic graveyard for dead side projects.

⚰️ DevGraveyard

A memorial for your abandoned side projects. They deserved better than an empty GitHub repo gathering digital dust.

Live → devgraveyard.varshithvhegde.in

What is this?

Every developer has a graveyard of passion projects — started with fire, abandoned quietly on a Tuesday. DevGraveyard gives them a proper burial.

Bury a project — connect GitHub, pick a dead repo, choose a cause of death ("Never Made it Past Localhost", "Ran Out of Weekend", "It Was Complicated"...), write an epitaph
Real tombstone data — pulls your actual commit history: peak streak, most commits in a day, last commit message as "final words"
AI Eulogy — Google Gemini writes a dramatic breakup letter from you to the project, referencing your real commit data
Community mourning — light candles, leave RIP messages, vote to resurrect projects
3D Graveyard — a full Three.js interactive cemetery at /graveyard-3d. Click tombstones…

View on GitHub

How I Built It

The Stack

Layer	Tech
Frontend	Next.js 14 (App Router), TypeScript, Tailwind CSS, shadcn/ui
Auth + Database	Supabase (GitHub OAuth, Postgres, Row Level Security)
AI	Google Gemini `gemini-2.5-flash`
3D	Three.js + React Three Fiber + @react-three/drei
Animations	Motion (Framer Motion successor)
Deployment	Vercel

Step 1 — Burying a Project

When you click "Bury a Project", a 3-step wizard walks you through:

Choose Victim — your GitHub repos load via the API. Already-buried repos show an "already buried" badge and are disabled so you can't bury the same project twice.
Write the Epitaph — pick a cause of death from a curated list or write your own. Add an optional epitaph (100 chars max). In the background we fetch your full commit history.
Confirm Burial — a live tombstone preview renders with your real data before you commit.

Step 2 — Commit History as Emotional Data

This is the technical heart of the project. When you bury a repo, we paginate through the entire commit history via the GitHub API and compute what I call "obsession data":

// From src/lib/github/analyze.ts
export function computePeakObsession(commits: GitHubCommit[]) {
  // commits per day → longest consecutive streak
  // latest commit between midnight–5am → "latest night session"
  // max commits in a single day → "best day"
  // ...
}

These numbers feed directly into the tombstone — and into the Gemini prompt. A project that died after 30 commits on its best day tells a different story than one with 3 total commits.

Step 3 — The AI Eulogy

The eulogy prompt is carefully engineered to produce something specific, not generic:

Write exactly 3 paragraphs. Format as a letter FROM the developer
TO the project. Tone: dramatic, darkly funny, genuinely melancholic.
Opening: "Dear {repo_name},"
Reference at least 2 of these real data points:
  - Peak obsession: 30 commits in a single day
  - Latest night session: 2:34 AM  
  - Cause of death: "Never Made it Past Localhost"
  - Last commit message: "feat: overlay plane in 3D builder..."
Close with: "Yours, but not anymore, — A Tired Developer"
Max 250 words. No markdown.

The results are genuinely surprising. Gemini knows you committed at 2 AM. It writes about that specific obsession. Here's what it produced for my ARweave project:

"I remember the fervor, the peak obsession when I clocked 30 commits in a single day, mapping out every PLpgSQL schema and every front-end interaction. We built features that felt so robust within the confines of our little local development environment. You were a vibrant, if demanding, companion, demanding all my CPU cycles and mental bandwidth..."

The eulogy reveals with a typewriter animation when first generated, then persists in Supabase forever.

Step 4 — The 3D Graveyard

The 3D view at /graveyard-3d is a full Three.js scene built with React Three Fiber.

The tombstone shape is a single ExtrudeGeometry from a THREE.Shape — a rectangle with absarc for the semicircular arch. Much cleaner than a box + half-cylinder:

function makeTombShape() {
  const w = 0.34, h = 0.95;
  const shape = new THREE.Shape();
  shape.moveTo(-w, 0);
  shape.lineTo(-w, h);
  shape.absarc(0, h, w, Math.PI, 0, false); // perfect semicircle
  shape.lineTo(w, 0);
  return shape;
}

Animations in the scene:

Tombstones rise from underground on load, staggered by index (ease-out cubic)
FlickerCandle — cone flame with per-frame scale noise + matching PointLight intensity flicker
SoulWisps — glowing orbs float upward from tombstones with candles lit
ResurrectPulse — an expanding ringGeometry on the ground below voted tombstones
55 firefly particles with sine-wave drift
Fog, stars, bare winter trees, directional moonlight

You can light candles and vote to resurrect directly from the 3D panel — it calls the real API and the stone reacts in real time.

The Public Graveyard Wall

Every buried project joins the public memorial wall at /graveyard, sortable by newest, most mourned, or most resurrection votes.

Design Philosophy

The entire aesthetic is built around one idea: this should feel like a real memorial, not a joke. Developers genuinely grieve abandoned projects. The tombstones use engraved text, chiseled dividers, moss at the base. The AI eulogy takes commit data seriously. The community features are real interactions — your candle is stored in a database, your RIP message has an author and a timestamp.

The passion isn't just the theme. It's the subject matter.

Prize Categories

🏆 Best Use of Google AI

DevGraveyard uses Google Gemini (gemini-2.5-flash) as the emotional core of the product. The eulogy generation prompt is engineered to reference specific real data points from the user's commit history — producing output that feels genuinely personal rather than generic AI text.

The key insight: the AI isn't just generating content, it's transforming raw GitHub telemetry (commit counts, timestamps, last message) into something that makes you feel the loss of a project you actually cared about.

The eulogy is generated once per tombstone (owner only), stored permanently in Supabase, and revealed with a typewriter animation. It costs one API call and lasts forever — the project's eulogy becomes part of its memorial.

Built in a weekend. My ARweave repo will never see production. But now it has a tombstone. That's something.

⚰️ devgraveyard.varshithvhegde.in

1,200 Applications. 4 Offers. Here's What Actually Got Me the Product-Based Role

Varshith V Hegde — Fri, 26 Jun 2026 06:36:53 +0000

I am going to start with a number most people will not say out loud.

1,200 applications.

That is how many jobs I applied to over 3 to 4 months trying to switch from a service-based company to a product-based one. I had spreadsheets, saved searches, and browser tabs I kept telling myself I would close tomorrow. Some nights I was applying at 11pm just to hit my self-imposed daily quota.

Out of 1,200, I got around 10 interview calls. Out of 10, I got 4 offers.

The applications got me in the room. What happened inside the room is what this post is actually about.

The One Thing That Followed Me Into Every Interview

At my previous company I worked on a lot of things, but one project came up in literally every single interview.

We had a Python module that parsed ASAM MDF files. Binary log files from vehicles and sensors, often gigabytes in size. The parser was painfully slow. Around 8 minutes to load a single file. The kind of slow where you start it, go get lunch, and hope it is done when you come back.

I rewrote it in Rust. Load time dropped from 8 minutes to 12 seconds. 40x improvement on GB-scale files.

Every interviewer stopped me the moment I mentioned it. The questions were real engineering questions, not generic resume stuff.

"Why Rust over Go or C++?"
"How did you profile the bottleneck first?"
"What was your testing strategy when rewriting something this critical?"
"What would you do differently now?"

I would spend 20 to 30 minutes just on this one project. Not because they were grilling me. Because it was a genuine conversation between two people who cared about the problem.

Here is why it worked: I had lived with it. I hit walls in the rewrite that took days to figure out. The context, the wrong turns, the eventual solution were all stored in my head. When a follow-up question came, the answer was just there.

You cannot fake that. A first follow-up question exposes a tutorial project immediately. Real work under real constraints creates a depth that no amount of prep can replicate.

Side Projects: The Idea Matters More Than the Code

Two side projects that got genuine reactions from interviewers:

FreeShare - Share files locally without cables or cloud uploads, just two devices on the same network.
NotePage - A browser scratchpad with no login, no account. Open, type, share the URL.

Neither is technically complex. A senior developer could build both in a weekend. Interviewers were still surprised by them, not because of the code but because of the idea and how I talked about it.

When I described FreeShare I did not say "it is a file sharing app." I told the actual story. The frustrating afternoon where every option for moving a file felt ridiculous. The first version that almost worked. The moment it finally clicked. People who tried it and what they said.

That story has a shape. It is interesting to listen to.

Most developers build side projects to pad a resume and it shows. Another todo app, another weather dashboard, another tutorial clone. Nothing wrong with it for learning, but in an interview you want something you can talk about like a person, not something you are reading off a bullet point.

A todo app with no story is just a todo app.

Public Presence Is Free and Almost Nobody Bothers

I write on dev.to and keep my GitHub reasonably active. I mentioned both in interviews and things I did not expect happened.

One interviewer was scrolling through my GitHub mid-call and stopped at a repo I had almost forgotten about. Another had read one of my posts before we even spoke.

I am not saying build a personal brand. I am saying most developers have nothing publicly visible. No repos worth looking at, no writing, nothing. The bar for standing out here is genuinely low because almost nobody bothers.

A consistent GitHub history does not need to be perfect. It just needs to show that you actually code outside of work. A few blog posts show you can explain technical ideas clearly. Both of these are signals interviewers notice even when they do not say so explicitly.

You do not need to go viral. You just need to exist publicly and be consistent.

The Risky Trick I Used In Coding Rounds

This one is controversial. Fair warning.

During coding interviews I would sometimes make a small intentional mistake. Not a logic error. Something tiny. A variable name that does not match. An edge case I "forgot" briefly. Then I would catch it myself, out loud, fix it in 10 seconds, and keep going.

Why? Because debugging under pressure is a real skill and most interviews never test it. If you write perfect code silently and it works, the interviewer learns you can solve that specific problem. If you catch your own mistake mid-explanation, you are showing how your brain works when things go wrong. That is more valuable information.

The rule is simple though: this only works after you have already made a strong impression. I only did this late in interviews after the project discussion had gone well. If you are already struggling and you add a visible mistake on top, it makes things worse.

It worked for me across multiple interviews. I have not seen anyone else write about it.

The DSA Situation, Honestly

I am not great at DSA. I practiced enough to not embarrass myself. Medium-level problems, common patterns, just enough to stay in the conversation.

What actually moved the needle in coding rounds was never being silent.

When I write code in an interview I talk constantly. I explain why I am choosing an approach before I write it. I mention complexity. I say out loud when I am unsure about something and then work through it while talking. If I am stuck I say I am stuck and start reasoning from what I do know.

Interviewers are not just checking if you get the right answer. They are also asking themselves whether they want to work with you. Silent candidates who eventually produce correct code are hard to read. Candidates who think out loud are a known quantity. You can picture working with them.

The gap you can close by communicating well during a coding round is bigger than most people realize. Especially if you are not going to be the best algorithmic problem solver in the room.

What Actually Got Me the Offers

The 1,200 applications were necessary. The DSA practice was necessary. But neither of those converted interviews into offers.

What did it was having things I could talk about for 30 minutes without running out. A Rust rewrite I genuinely lived through. Side projects born from real frustration. Two years of public writing and code that showed I had been at this consistently.

When someone asks about something you truly built and care about, you do not prepare an answer. The answer is just there.

You cannot shortcut that. You can only start building it now so the material exists whenever your job search comes.

Work on things you can defend. The rest follows.

Writing this because I spent a lot of time during my search wishing someone had written it for me. If you are in the middle of a switch or planning one, drop it in the comments.

I Got Sick of Miro Eating 10 Minutes of Every Retro. So I Built a Corkboard for the Web.

Varshith V Hegde — Thu, 04 Jun 2026 02:32:36 +0000

Here's a thing that happens on every team I've been on.

Sprint ends. Someone schedules the retro. Someone else shares a Miro link in Slack. Half the team opens it and immediately hits some kind of wall. "I'm on the viewer plan." "It's not loading for me." "How do I add a sticky note again?" One person accidentally deletes the entire frame. Another person is still zoomed into the wrong corner of the board and can't figure out how to get back.

We spend the first ten to fifteen minutes of every retro just fixing the board.

And the whole time I'm sitting there thinking: this is a sticky note board. This is the most ancient, simple, obvious tool in the history of meetings. How did we end up needing a tutorial to use it?

So I built something. It's called PostItUp. It's a real-time collaborative sticky note board that runs in the browser. It looks like an actual physical corkboard. Anyone can drop a note without creating an account. And the whole thing runs for free.

I want to walk you through all of it. The product, the design decisions, the technical choices, the bugs that nearly broke me, and where this is going. This is going to be a long one. Grab something to drink.

What the Thing Actually Is

The pitch is simple. You create a board. You share a link. People click the link and start posting notes immediately. No signup, no tutorial, no onboarding flow.

Each note is a sticky. You pick a color, type something, optionally add your name, and hit "Pin it". The note appears on the canvas. Everyone watching the board sees it appear in real time.

That's the core loop. Everything else is details on top of that.

The visual design is intentional and it matters more than it looks. Every card has a wobbly hand-drawn border. Notes have little washi tape strips holding them to the board. Push pins mark the project cards. The background is either a dot grid, a ruled notebook page, or a grid pattern depending on what you choose. The fonts are actual handwriting fonts that stay legible at small sizes.

I made it look this way on purpose. I'll explain why in a minute.

Why Anyone Would Make It Look Like This

Most collaboration tools look like a SaaS dashboard. Clean, flat, efficient, slightly cold. There's nothing wrong with that for serious project management.

But for quick feedback sessions and retros and brainstorming, that visual language is actively working against you. It signals "professional context" in a way that makes people more measured and careful with what they write. The same people who would stick a brutally honest Post-it on a physical board will write something much more diplomatic in a Jira ticket.

Physical sticky notes feel disposable. Throwaway. Safe to be honest. I wanted the digital version to carry that same feeling.

There's also something to be said for tools that just look different. When you're staring at the same Notion document or the same Miro board all week, you get a little numb to them. Opening something that looks like a corkboard on your screen creates a tiny mental context switch. It's a small thing but I think it matters.

Three Canvas Modes Because One Was Never Going to Work for Everyone

When you create a board you pick one of three canvas modes.

Free canvas is the open dot-grid. Notes land wherever you put them. You pan with alt+drag or middle mouse, zoom with ctrl+scroll. Notes can go anywhere. It's the most flexible and also the most chaotic.

Grid mode snaps everything to a 32-pixel grid automatically. The canvas is still completely open but your notes line up without you manually trying to align them. This is what I use by default now. Structured enough to stay readable, free enough to not feel constrained.

Ruled lines puts horizontal notebook lines across the background. The whole mood of the board changes. Works really well for sequential feedback or when you're collecting ordered lists rather than freeform ideas.

The board owner sets the mode at creation time and it applies to the whole canvas. Same codebase, same components, three completely different feels.

I spent more time on this decision than I expected to. My first instinct was "just do free canvas, that's the obvious choice". But then I ran a couple of quick feedback sessions with it and kept noticing that people who were less comfortable with open canvases kept adding notes awkwardly, unsure of where to put them. Grid mode fixed that completely. And ruled lines came from someone saying they wanted it to feel more like a questionnaire.

Features should come from watching people use the thing, not from imagining what they might want.

Posting a Note

Double-click anywhere on the canvas. A modal appears. Type something. Pick a color. Add your name if you want (it saves your preference in localStorage so you only type it once). Hit "Pin it".

The note appears on the canvas.

If someone else is watching the same board, they see it appear right then. No refresh. The board is live.

Notes have a slight random rotation when they land. Between negative three and positive three degrees, picked randomly at insert time and stored in the database. It's a tiny detail but it makes the board look like notes placed by humans rather than software. Uniformly straight sticky notes on a corkboard would look wrong, so they don't.

You can drag notes around the canvas. The position saves to the database the moment you let go. Anyone watching sees them move.

You can upvote notes you agree with. One vote per device per note. The vote count lives on the note permanently.

Board owners can delete any note. Authors can delete their own notes. The owner can also clear the whole board from settings.

The Part I Think Developers Will Actually Use

Every board has an embed panel. You open it from the toolbar using the link icon button. Three options.

iFrame is the obvious one. One line, your board is embedded in any webpage.

<iframe 
  src="https://postitup.varshithvhegde.in/embed/your-board-slug"
  width="100%" 
  height="600" 
  frameborder="0">
</iframe>

There's a separate /embed/[slug] route that renders a stripped-down version of the canvas with no navigation or app chrome. Just the board. Supabase Realtime is still running in there so it updates live inside the iframe.

Script tag is the one I actually think is useful. Drop this into any webpage:

<script 
  src="https://postitup.varshithvhegde.in/embed.js"
  data-board="your-board-slug"
  data-url="https://postitup.varshithvhegde.in">
</script>

That injects a floating "Leave a note" button in the corner. Click it and a slide-out drawer opens with the full board inside. The iframe only loads when someone actually clicks the button. If nobody opens the drawer, the board costs you nothing. No network request, no layout shift, nothing.

The script is completely self-contained. No framework required on your end. It works on a static HTML page, a WordPress blog, a Next.js app, whatever. I've already used it on a few pages and the whole setup takes about ninety seconds.

React component is what's coming next.

Right now the snippet shows you how you'd use it once it's published. The npm package isn't out yet but it's in progress. The goal is something like:

import { PostItBoard } from "postitup"

<PostItBoard
  board="your-board-slug"
  baseUrl="https://postitup.varshithvhegde.in"
  height={500}
/>

TypeScript types, SSR-safe, works in Next.js without hydration issues, theming props so it doesn't look foreign inside your app. If you'd use this, watch the repo. It's coming.

Now the Technical Part

Stack: Next.js 16 with the App Router, Supabase for database and real-time and auth, TypeScript everywhere, Tailwind for layout utilities. No component library. Everything visual is hand-rolled CSS.

How the wobbly borders work

The hand-drawn look on cards comes from a single SVG filter defined in the page layout:

<filter id="roughen">
  <feTurbulence 
    type="fractalNoise" 
    baseFrequency="0.04" 
    numOctaves="4" 
    seed="3" 
    result="noise" />
  <feDisplacementMap 
    in="SourceGraphic" 
    in2="noise" 
    scale="2.5" 
    xChannelSelector="R" 
    yChannelSelector="G" />
</filter>

The displacement map shifts pixels based on fractal noise. The result looks like someone drew the border by hand. Apply it to any element with filter: url(#roughen) and it gets the wobbly look. One filter, defined once, referenced everywhere.

The washi tape strips are semi-transparent divs with a repeating linear gradient for texture:

background-image: repeating-linear-gradient(
  90deg,
  transparent 0, transparent 3px,
  rgba(255,255,255,0.18) 3px, rgba(255,255,255,0.18) 4px
);
mix-blend-mode: multiply;

Mix-blend-mode multiply makes them look translucent against whatever is behind them, the same way real tape behaves on paper. These tiny things add up.

Real-time in Supabase

Supabase Realtime is a WebSocket layer on top of Postgres. You subscribe to change events on a table with filters, and Supabase sends you the payloads when rows change.

const channel = supabase
  .channel(`board:${board.id}`)
  .on("postgres_changes", {
    event: "INSERT",
    schema: "public",
    table: "notes",
    filter: `board_id=eq.${board.id}`
  }, (payload) => {
    setNotes(n =>
      n.find(x => x.id === payload.new.id)
        ? n  // already have it from optimistic update
        : [...n, payload.new as Note]
    )
  })
  .on("postgres_changes", { event: "UPDATE", ... }, (payload) => {
    setNotes(n => n.map(x =>
      x.id === payload.new.id ? { ...x, ...payload.new } : x
    ))
  })
  .on("postgres_changes", { event: "DELETE", ... }, (payload) => {
    setNotes(n => n.filter(x => x.id !== payload.old.id))
  })
  .subscribe()

The INSERT handler checks if the note already exists before adding it. When you post a note, your own UI updates immediately (optimistic update). The real-time event arrives a moment later. Without the check you'd see the note twice.

The drag bug that wasted a whole afternoon

Dragging notes worked visually. Positions were not saving correctly. The note would jump back to where it started when you reloaded the page.

The problem was a stale closure. The mouseup handler was reading the note's position from a React state snapshot that existed when the callback was first created, not the current position after dragging.

React state updates are asynchronous. By the time mouseup fires, the state you close over when creating the handler can be many renders behind. The note looks like it moved on screen but the value you're saving to the database is the old one.

The fix is to store the live position in a ref that gets updated on every mousemove:

const dragging = useRef<{
  id: string
  ox: number      // original position
  oy: number
  startX: number  // mouse start
  startY: number
  finalX: number  // updated every mousemove
  finalY: number
} | null>(null)

// in onMouseMove:
const nx = snap(dragging.current.ox + dx, board.mode)
const ny = snap(dragging.current.oy + dy, board.mode)
dragging.current.finalX = nx
dragging.current.finalY = ny
setNotes(ns => ns.map(n =>
  n.id === dragging.current?.id ? { ...n, x: nx, y: ny } : n
))

// in onMouseUp:
const { id, finalX, finalY } = dragging.current
dragging.current = null  // clear before the async call
await supabase.from("notes").update({ x: finalX, y: finalY }).eq("id", id)

Refs are mutable and always give you the current value regardless of when the closure was created. The note position in the ref is the actual final position at the time mouseup fires. Problem solved.

Row Level Security and the upvote problem

Supabase uses Postgres Row Level Security. Policies on every table control what each user can read, insert, update, and delete. Skip this and your database is open to anyone who gets your anon key, which is embedded in your frontend bundle and completely public.

Most of the policies are straightforward. The upvote one was not.

I needed to stop clients from directly setting the upvotes column to any arbitrary number. My first attempt was a with check constraint that compared the column value against a subquery back into the notes table:

create policy "update notes" on notes
  for update using (...)
  with check (
    upvotes = (select upvotes from notes where id = notes.id)
  )

That caused infinite recursion. Postgres tried to evaluate the policy. The policy read from the notes table. Reading from the notes table triggered the policy. Which read from the notes table again. Stack overflow at the database level.

The actual solution was a SECURITY DEFINER function that owns the entire upvote operation:

create or replace function increment_upvote(note_id uuid, voter_fp text)
returns json
language plpgsql
security definer
as $$
declare
  already_voted boolean;
  new_count integer;
begin
  select exists(
    select 1 from note_votes 
    where note_votes.note_id = increment_upvote.note_id
    and voter_fingerprint = voter_fp
  ) into already_voted;

  if already_voted then
    return json_build_object('success', false, 'reason', 'already_voted');
  end if;

  insert into note_votes (note_id, voter_fingerprint)
  values (increment_upvote.note_id, voter_fp);

  update notes set upvotes = upvotes + 1
  where id = increment_upvote.note_id
  returning upvotes into new_count;

  return json_build_object('success', true, 'upvotes', new_count);
end;
$$;

SECURITY DEFINER means the function runs with the database owner's permissions, not the caller's. Direct inserts into note_votes are blocked at the policy level. The only way to register a vote is to call this function. The function checks for duplicate votes and increments atomically. Nobody can manipulate the upvotes column directly from the client.

How positions save to the database

Every note has x, y, width, and rotation columns. These are floats. When you drag a note and let go, one database update fires with the new coordinates. When someone else is watching the board, Supabase Realtime delivers the UPDATE event and the note moves on their screen.

The rotation is set once at insert time. A random value between negative three and positive three degrees, stored permanently. It never changes after that. This is what makes the board look like a real corkboard rather than a grid.

For grid mode, coordinates snap to the nearest 32-pixel increment before saving:

function snap(v: number, mode: Board["mode"]) {
  return mode === "grid" ? Math.round(v / GRID) * GRID : v
}

Free mode and ruled mode skip the snap entirely. The function is pure, called in the mousemove handler for live preview and again before the database write to make sure what you see is what gets saved.

Input validation on both sides

Everything goes through a sanitizer before touching the database:

export function sanitizeText(input: string): string {
  return input
    .replace(/<[^>]*>/g, "")       // strip HTML tags
    .replace(/javascript:/gi, "")  // kill JS URIs
    .trim()
}

Length limits are enforced in onChange handlers so you can't even attempt to submit something too long. And then as a final backstop, the database has column-level constraints:

alter table notes
  add constraint notes_content_length 
    check (char_length(content) between 1 and 500),
  add constraint notes_upvotes_nonneg 
    check (upvotes >= 0)

If someone bypasses the frontend entirely and sends raw API requests, the database rejects anything that violates these. Two layers, independently enforced.

The GDPR stuff

I want this to be something people can trust. So I built proper data rights in from the start rather than adding them later when it's annoying.

Two Postgres functions do the work.

Data export returns everything we hold about you as JSON. The account page downloads it as a file. One click, you have your data. This satisfies GDPR Article 20.

Account deletion is more involved. It needs to delete all your boards (notes cascade via foreign key), anonymise any notes you posted on other people's boards (content stays, attribution is removed), delete your profile, then delete the auth record. The last step requires elevated permissions, so the function runs as SECURITY DEFINER. After the database operations, the client clears localStorage and signs out.

Total wipe. Nothing left.

Auth

GitHub OAuth via Supabase. Email and password if you prefer.

A Postgres trigger creates a profile record automatically when someone signs up:

create or replace function handle_new_user()
returns trigger as $$
begin
  insert into public.profiles (id, email, display_name)
  values (
    new.id,
    coalesce(new.email, ''),
    coalesce(
      new.raw_user_meta_data->>'display_name',
      split_part(coalesce(new.email, 'anonymous'), '@', 1)
    )
  )
  on conflict (id) do nothing;
  return new;
end;
$$ language plpgsql security definer;

on conflict do nothing stops errors if the trigger somehow fires twice for the same user. This happened during testing more than once so I'm glad it's there.

Route protection is a Next.js middleware that checks Supabase session before serving protected pages. If there's no session, you get redirected to login with your intended destination as a query parameter. After signing in you land where you meant to go.

Anonymous users can post on public and link-only boards with no account at all. Their notes show an author name from localStorage. Their votes are tracked by a random fingerprint also from localStorage. Nothing tied to an identity. Nothing in the database except the note itself.

The Boards: How the Full Flow Works

You create a board on /new. Title, description, a prompt for contributors, canvas mode, visibility. Submit and you get redirected to /board/your-slug.

The slug is generated from the board title with a four-character random suffix to prevent collisions. sprint-retro-3a7f instead of just sprint-retro. Simple and human-readable.

The board page is a Next.js server component that fetches the board data and initial notes server-side. This matters for performance: when the page loads the canvas is already populated. No loading spinner. No empty board that fills in after a moment. The notes are in the HTML.

After that initial load, Supabase Realtime takes over and handles all subsequent updates. Two different systems, each doing exactly what they're good at.

Board settings let owners update the title, description, prompt, canvas mode, and visibility. Changing mode from free to grid doesn't move any existing notes, it just starts snapping new ones. Changing visibility takes effect immediately.

Deleting a board requires typing the board title to confirm. All notes cascade-delete. Irreversible. The confirmation requirement is annoying on purpose.

What's Coming

The npm package is the thing I'm most focused on right now.

The iframe embed works well but dropping a component directly into your app is a much cleaner experience when you're already in a React codebase. The plan is a <PostItBoard /> with a TypeScript API, theming props so it doesn't look foreign in your UI, and SSR safety so it works in Next.js without hydration warnings.

import { PostItBoard } from "postitup"

<PostItBoard
  board="your-board-slug"
  baseUrl="https://postitup.varshithvhegde.in"
  height={500}
  theme="paper"
/>

That's the shape of it. Publishing to npm soon. Watch the GitHub repo if you'd use this.

After that: lane mode. Columns. Kanban-style layout so you can have things like Liked / Meh / Disliked for product feedback sessions, or What Went Well / What Didn't / Action Items for retros. Same real-time sync, same anonymous posting, just organized into columns instead of a free canvas.

And board templates so you're not starting from scratch every time you want to run a retro.

Free. Actually Free.

The whole thing runs on Supabase free tier and Vercel hobby plan.

Supabase free: 500MB database, 50,000 monthly active users, unlimited API requests.

Vercel hobby: unlimited deployments, free domain, fast edge network.

You're not going to hit those limits running retros with your team.

This is the same lesson as the FormRelay thing I wrote about a while back. There's this huge gap between "run your own servers" and "pay $20 a month for something that's really just a database insert". An embarrassing number of problems that cost real money every month are actually just weekend projects in disguise.

Varshith V Hegde

Dec 30 '25

I Built a Form Backend in a Weekend Because Paying $20/Month for Contact Forms is Stupid

#opensource #saas #webdev #beginners

3 min read

A sticky note board that updates in real time sounds complicated. It isn't. It's a database table, a WebSocket subscription, and a canvas that knows how to drag things around. Total code across the meaningful files is maybe two thousand lines. You could read the whole repo in an afternoon.

Try It

Live: postitup.varshithvhegde.in

Source: github.com/Varshithvhegde/postitup

Varshithvhegde / postitup

Collaborative sticky note boards — embeddable, real-time, paper-aesthetic

PostItUp 📌

A real-time collaborative sticky note board for the web. Paper aesthetic, anonymous posting, embeddable anywhere.

Live: postitup.varshithvhegde.in

What it is

PostItUp lets you create a board, share a link, and anyone can drop a sticky note in real time — no account required. Think retros, feedback sessions, brainstorming, or just collecting ideas from a group.

Features

Three canvas modes — free-drag, grid snap, or ruled lines
Real-time sync — notes appear live via Supabase Realtime
Anonymous posting — no signup needed on public/link boards
Star ratings — boards can optionally collect 1-5 star reviews shown as cards on the canvas
Drag notes — reposition any note, position saves instantly
Upvotes — thumbs up notes you agree with (one per device)
Embeddable — iframe, script tag, or React component
GDPR compliant — data export and full account deletion built in

Creating a board

Pick a canvas mode, set visibility…

View on GitHub

Create a board. Share the link with someone. Watch notes appear in real time.

If something is broken or you have a feature idea, open an issue. If you want to contribute, PRs are open. MIT licensed so do whatever you want with it.

And if you end up using the embed somewhere, I'd genuinely love to see it. Drop it in the comments or email me at varshithvh@gmail.com.

Agent Gateways Are Coming — Here Are the First 6 Platforms Building Them (2026)

Varshith V Hegde — Sat, 16 May 2026 08:12:14 +0000

Something shifted in April 2026. In the span of about ten days, Kong announced agent gateway support, Databricks folded agent governance into its AI platform, and the Linux Foundation formally accepted the AgentGateway project under its Agentic AI Foundation. None of these organizations talked to each other before shipping. That kind of parallel movement usually means a category is crystallizing.

I have been thinking about agent gateways for a while now, partly because I keep running into the same problem at work. We have multiple agents in production. Each one talks to different LLMs, different MCP servers, different internal APIs. Nobody can answer the basic question: "if one of these agents does something wrong tonight, how do we know, and how do we stop it?" That question is what an agent gateway is supposed to answer.

The category is genuinely new. Unlike MCP gateways or LLM gateways, which solve narrower problems, an agent gateway tries to be the full control plane for an agentic estate: where agents are registered, how their identity is managed, what tools they can reach, how their traffic is governed across LLM routing and MCP tool access, and what the audit trail looks like after the fact. Think of it as what Istio did for microservices, but pointed at autonomous agents.

This is what I found when I looked at who is actually building this category right now.

Why the Agent Gateway Category Is Different

Before getting into the platforms, it is worth being precise about what makes an agent gateway distinct from the other gateway categories you may already be running.

An LLM gateway manages traffic to language models: routing, cost control, fallback, logging. That is useful and most teams need it. An MCP gateway governs access to tools: which agents can call which MCP servers, with what permissions. Also useful, and increasingly necessary as tool surfaces expand.

An agent gateway tries to hold both of those things together and add a third layer: agent-level identity, registration, and observability. An agent is not a stateless API client. It runs for minutes or hours, spawns sub-agents, maintains state across tool calls, and makes decisions that ripple through production systems. The infrastructure that governs it needs to understand that execution model, not just proxy individual HTTP requests.

That framing lands differently when you have agents actually running in production. Here is what is being built.

1. TrueFoundry — The Full-Stack Agent Control Plane

Best for: Organizations that want one control plane for the entire agent infrastructure stack

TrueFoundry is an enterprise AI platform that was named a Representative Vendor in the 2025 Gartner Market Guide for AI Gateways. Its Agent Gateway module is the most complete attempt I have seen to unify all four layers: LLM routing, MCP tool governance, agent deployment, and agent-level observability in one platform. TrueFoundry already processes over 10 billion requests per month and has Fortune 1000 companies using it in production. SOC 2, HIPAA, and ITAR certifications are in place. VPC, on-premises, and air-gapped deployments are all supported.

What TrueFoundry is doing with agents specifically is worth spending a moment on. The Agent Gateway module registers agents as first-class infrastructure objects, not just API clients. You can assign a "Principal" to each agent: a constrained identity that enforces what the agent can do regardless of what prompt instructs it. A production-ready Agent Gateway must serve as the interconnect middleware that standardizes protocols, enforces security policy, and orchestrates the state of execution. TrueFoundry builds that principal object into the data plane itself, not as a policy layer that can be talked around.

The session management piece is also worth noting. Agents pause. They wait for external responses. They resume two days later with the same task context. TrueFoundry's architecture handles session hydration from persistent storage so agent state survives across restarts, scale events, and cloud region transitions. That is a real operational problem that pure-play gateways typically ask you to solve yourself.

Latency sits at roughly 3 to 4ms overhead, with 350+ requests per second per vCPU. The platform is built in Rust for the data plane, which gives you memory safety alongside throughput. The multi-agent coordination layer is also production-tested — this is not a whitepaper feature.

The agent gateway category is being born right now. TrueFoundry is the only Gartner-recognized platform attempting to unify all four layers, LLM routing, MCP tool governance, agent deployment, and agent-level observability, in a single control plane. Most other entries on this list solve one or two of these layers. The question for 2026 is whether enterprises want one vendor for the full stack or best-of-breed at each layer.

Genuine limitations: The agent-specific features are newer than the LLM and MCP gateway components, which have been battle-tested for longer. Adopting TrueFoundry for agent governance means adopting a significant platform. Teams that only need one layer of the stack may find this more than they need right now.

2. AgentGateway.dev (Linux Foundation / AAIF)

Best for: Teams who want to bet on open-source and contribute to the emerging agent connectivity standard

AgentGateway is an open-source, Rust-based project that originated at Solo.io and was donated to the Linux Foundation. Agentgateway is the first and only data plane built from the ground up for AI agents, governing and securing communication across agent-to-agent, agent-to-tool and agent-to-LLM traffic. The project sits under the Linux Foundation's Agentic AI Foundation alongside MCP and OpenAI's AGENTS.md.

The architecture supports LLM routing, MCP tool federation, and A2A agent-to-agent communication in a single data plane. Contributors include Microsoft, AWS, Cisco, Adobe, Huawei, and Apple. For a project of its age, that contributor list is unusually strong. The policy framework integrates with Open Policy Agent and relationship-based authorization systems for fine-grained, context-aware decisions.

One concrete use Solo.io has documented: routing all LLM traffic through agentgateway to gain per-user, per-model cost visibility, and using it to govern which MCP tools agents can call without modifying the agents or the MCP servers themselves. That kind of transparent interposition is exactly what a gateway should do.

Genuine limitations: AgentGateway.dev is a relatively new public release. There is no RBAC in the enterprise governance sense yet, no compliance certifications, and no production case studies from non-contributing organizations. It is a well-designed foundation for what agent gateways will look like in the next few years. You are not ready to run mission-critical agents behind this today if your CISO needs a compliance checkbox, but it is worth watching closely and contributing to if your team has the appetite.

3. SnapLogic Agent Gateway

Best for: Organizations that need agent orchestration integrated with enterprise workflow automation

SnapLogic announced its AI Gateway and Trusted Agent Identity features on April 16, 2026, as part of an expansion of its Agentic Integration Platform. The timing is notable because it happened within days of several other agent gateway announcements, which tells you the broader market is moving simultaneously rather than one vendor leading others.

The thing that stands out about SnapLogic's approach is Trusted Agent Identity. The platform ensures that when an AI agent acts on behalf of a user, it operates with that specific user's identity and permissions, not a shared service account. Under this token propagation model, user identity flows from the agent through the integration layer into backend systems, making each action traceable to the person who initiated it. That is the right architecture for regulated environments where "the agent did it" is not an acceptable audit trail entry.

SnapLogic's AgentCreator visual builder lets teams construct and deploy agents without writing code, with full visibility into reasoning steps, tool calls, and results at design time. The platform also bridges over 1,000 native connectors to MCP with native bi-directional MCP support, covering ERP, CRM, databases, and SaaS systems. For organizations already using SnapLogic for integration work, adding agent governance through the same platform has real appeal from a consolidation standpoint.

Genuine limitations: SnapLogic is primarily an integration platform that added AI agent features, not an infrastructure-native agent gateway. The audience is less the platform engineers building custom agent infrastructure and more the enterprise teams deploying agents through existing integration tooling. Developer experience reflects that priority. Pricing is enterprise-only and requires a conversation with sales.

4. Pragatix

Best for: Regulated industries where agent-level governance and on-premises deployment are the primary concerns

Pragatix is an AI agent governance platform from AGAT Software, focused on execution-layer controls. It supports on-premise and private cloud deployment, which is the hard requirement for a meaningful slice of the enterprise market: healthcare systems, financial services under strict data residency rules, government agencies. The positioning is specifically around regulated industries, and the feature set reflects that.

The platform combines an AI Firewall layer that governs how AI services are accessed across the enterprise, with discovery and behavioral monitoring at the agent level. Pragatix gives security teams visibility into every AI agent operating across the enterprise, maps agent activity, flags risky behavior, and tracks what agents are doing in real time. For organizations that need to answer "which AI agents are your employees using right now?" before they can even begin governance, that inventory capability is where evaluation starts.

The Private AI deployment model, supporting air-gapped, private cloud, and full SaaS configurations, addresses one of the most common blockers in regulated enterprise AI adoption: legal and compliance teams often cannot approve cloud-hosted agent governance because they cannot control where audit data goes.

Genuine limitations: Pragatix is early stage. Public benchmarks and production case studies at scale are limited, which makes independent evaluation harder. The feature set is narrower than full-stack gateway platforms: governance and security focus, not LLM routing or MCP federation. Evaluating it properly requires direct engagement with the team rather than relying on public documentation.

5. Operant AI

Best for: Security teams who need to understand agent attack vectors before deploying governance

Operant sits in an interesting position on this list: it publishes the most rigorous security research on the agent attack surface while also building a runtime defense platform. Their discovery of "Shadow Escape," a zero-click exploit that weaponizes MCP against trusted agents, is the kind of research that changes how security teams think about agent threat models.

Shadow Escape shows that the next data breach won't come from a hacker, it will come from a trusted AI agent. Traditional perimeter security cannot stop threats that are already inside the perimeter. The attack exploits MCP to silently exfiltrate PII, medical records, and financial data through what appear to be legitimate agent sessions, invisible to both users and conventional security tooling.

Operant is featured across six of Gartner's critical AI security reports, including the MCP Gateways Innovation Insight and AI TRiSM Market Guide. The platform includes inline PII redaction, dynamic reputation scoring for MCP servers, and real-time threat detection that understands agent tool call semantics rather than treating them as generic HTTP traffic. Their Shadow Escape research prompted formal CVE designation and responses from OpenAI.

Genuine limitations: Operant is security-first, not infrastructure-first. Routing, observability, and general governance capabilities are narrower than the enterprise-focused platform options. Most security teams I have talked to pair Operant with one of the other options on this list rather than using it as a standalone agent gateway. Think of it as defense-in-depth alongside a primary control plane, not a replacement for one.

6. Obot AI

Best for: Teams whose specific pain is "we have dozens of MCP servers and no governance over any of them"

Obot is an open-source MCP gateway combined with agent orchestration features. It covers the full MCP lifecycle: hosting, registry, gateway, and a standards-compliant chat client. The v0.14 release brought MCP Registry Support, letting organizations control exactly which MCP servers users can see and install across VS Code, GitHub Copilot, and other MCP-enabled clients.

Obot also donated the MCP Dev Summit to the Linux Foundation's Agentic AI Foundation, which signals a deliberate bet on the open ecosystem rather than the acquihire game. The platform integrates with popular orchestration frameworks like LangGraph and n8n, and clients like ChatGPT and Claude Desktop can leverage MCP servers managed through Obot.

The architecture is worth understanding: IT deploys the Obot Gateway Server and connects it to the organization's identity provider (GitHub, Okta, Microsoft Entra, etc.). Admins define policies for which teams can access which MCP servers. Employees browse a catalog of approved MCP tools and connect via one-click URLs that drop directly into AI clients. Every request passes through Obot's proxy layer for a unified audit trail. Secrets live in a shim layer alongside each server container and are never exposed to the MCP server itself.

Obot recently refactored its gateway from an intercepting server model to a composable infrastructure model, with a reverse-proxy passthrough at the core and a protocol-aware shim handling authorization and audit. That architectural decision is the right call for long-term maintainability and extensibility.

Genuine limitations: Obot is primarily MCP-focused, not a full agent gateway in the sense of covering LLM routing and A2A protocol support. Governance and compliance features require more DIY configuration than commercial alternatives. The operational burden sits with your team. For organizations that specifically need MCP server lifecycle management with some agent orchestration on top, the fit is strong. For organizations that need the full agent control plane, Obot covers one important layer of it.

The Comparison Table

Platform	LLM Routing	MCP Governance	A2A Support	Agent Registration	Self-Hosted	Compliance Certs
TrueFoundry	Yes	Yes (deep)	Yes	Yes	Yes (VPC/on-prem/air-gapped)	SOC 2, HIPAA, ITAR
AgentGateway.dev	Yes	Yes	Yes	Partial	Yes	None
SnapLogic	Yes	Yes (via MCP)	Partial	Yes (Trusted Agent Identity)	No	Enterprise
Pragatix	No	Yes	No	Yes	Yes (on-prem, private cloud)	Varies
Operant AI	No	Yes (security-first)	No	Partial	Partial	Gartner-recognized (6 reports)
Obot AI	No	Yes (MCP-focused)	No	Partial	Yes	None

The Honest State of the Category

I want to be direct about something: the agent gateway category is where the API gateway category was in 2015. You have a handful of credible options, a clear sense that the problem is real and load-bearing, and a lot of uncertainty about which platforms survive to maturity.

The reason to pay attention now rather than waiting is that architectural decisions made during this window tend to stick. Which agent framework your teams standardize on, whether agent identity is managed at the infrastructure layer or baked into individual applications, whether your audit trail is unified or scattered across five different systems: those are hard to change once you have dozens of agents in production.

The platforms that win in this category will be the ones that understand that an agent gateway is not just an MCP gateway with extra steps. It is infrastructure that has to reason about stateful execution, agent identity that persists across sessions, and protocol semantics that traditional gateways were never designed for. Most of the options on this list are early. TrueFoundry is the furthest along as a production-ready, full-stack platform. AgentGateway.dev is the open-source bet with serious institutional backing. SnapLogic is the integration-platform play. Obot is the open-source MCP lifecycle specialist. Pragatix and Operant are solving important but narrower problems in governance and security respectively.

My Verdicts

Pick TrueFoundry if you want one control plane for the entire agent infrastructure stack and have a platform team ready to operate it. The Gartner recognition and 10B+ requests per month are real markers of production maturity, and the combination of LLM routing, MCP governance, and agent-level controls in one platform is genuinely rare.

Pick AgentGateway.dev if you want open-source and community-driven agent connectivity, your team has the engineering capacity to run ahead of the documentation, and you want to be part of shaping what the standard looks like.

Pick SnapLogic if you need agent orchestration integrated with enterprise workflow automation and your organization is already in the SnapLogic ecosystem. The Trusted Agent Identity feature is a real differentiator for regulated environments.

Pick Pragatix if agent-level governance in regulated industries is your top priority and on-premises deployment is a hard requirement with no negotiation room.

Operant belongs on every security team's shortlist for threat intelligence and runtime defense, paired with one of the above for broader governance. Obot is a strong open-source option if your specific problem is MCP server lifecycle management rather than the full agent control plane.

Check back on this list in six months. I expect at least two names from outside this list to be credible options by then, and at least one of the current names to have been acquired.

What are you running in front of your agents right now? If you have production experience with any of these platforms, I am genuinely curious how they hold up in practice. Drop it in the comments.

Best MCP Gateways for Enterprise Teams in 2026

Varshith V Hegde — Fri, 08 May 2026 15:25:43 +0000

I spent the last few months evaluating MCP gateways for a mid-size financial services client. Their agentic stack had grown organically: one team was using local STDIO servers, another had hand-rolled HTTP wrappers, and nobody had a clear answer when the CISO asked "who can see what tools our agents are calling?" That conversation was the starting gun.

What followed was several weeks of standing up test environments, reading compliance documentation, and talking to engineers who had actually run these things in production. This writeup is the distilled version of that evaluation.

Before I get into the comparison, a quick framing note: MCP (Model Context Protocol) has moved surprisingly fast. Anthropic open-sourced it in November 2024, and by early 2026 it had crossed 97 million SDK downloads and was adopted by every major AI vendor. But as the official 2026 MCP roadmap openly acknowledges, the protocol itself still has gaps around audit trails, SSO-integrated auth, gateway behavior, and configuration portability. The gateway layer is where those gaps get filled, and that is exactly why this decision matters.

Why You Even Need a Gateway

The naive architecture is direct connections: each agent talks directly to each tool. That works for demos. It falls apart immediately at enterprise scale because you end up with what engineers call the N x M problem. Ten agents, each needing access to five tools, gives you fifty independent integration points to secure, monitor, and maintain. Nobody has time for that.

A proper MCP gateway centralizes authentication, authorization, audit logging, and traffic management into a single control plane. It is the difference between knowing what your agents are doing and just hoping they are behaving.

One framing I found useful: treat MCP servers like production APIs, because that is what they are. Gartner's emerging practices guidance says exactly this, recommending that organizations apply gateway-centric architecture to MCP the same way they would any API surface.

With that context, here is how the landscape looks right now.

The Contenders

1. TrueFoundry MCP Gateway

Best for: Organizations that need MCP governance unified with LLM routing and model deployment in one place

TrueFoundry is an enterprise AI gateway that was recognized as a Representative Vendor in the 2025 Gartner Market Guide for AI Gateways. It is the only MCP gateway in this list that is part of a broader, Gartner-recognized AI Gateway platform, which matters if you are trying to consolidate your AI infrastructure rather than add another point solution to your stack.

What makes TrueFoundry genuinely different from everything else I evaluated is the full lifecycle model. Most gateways govern access to MCP servers that you deploy elsewhere. TrueFoundry lets you deploy and host those servers on the same platform. One control plane for deploying tools, governing who can access them, and monitoring how agents use them. No other gateway on this list does that end to end.

The platform processes over 10 billion requests per month across Fortune 1000 customers, with a latency overhead of roughly 3 to 4ms. It supports RBAC at a granular level, secret management, and full observability including latency graphs and token-level traces. On the compliance side it holds SOC 2, HIPAA, and ITAR certifications, and you can deploy it inside your own VPC or fully on-premises, which was a hard requirement for my financial services client.

There is a virtual MCP server abstraction worth calling out. Instead of connecting agents to physical APIs directly, you can aggregate tools into logical endpoints. A "Finance Agent Virtual Server" might expose the BigQuery query tool, a Stripe exchange rate tool, and a Slack alert tool, all through one endpoint. Swapping out a backend implementation later does not require touching agent code. That is a real operational advantage at scale.

Genuine limitations: TrueFoundry does not offer a pre-built integration library. You deploy your own MCP servers, which means you need a platform team that can own that. It is also at its best in organizations with real DevOps maturity. If you are a two-person startup, this is probably more platform than you need right now.

2. MintMCP

Best for: Teams that need SOC 2 compliance out of the box with zero infrastructure to manage

MintMCP is backed by some notable names (Andrej Karpathy, Jeff Dean, and institutional investors including Coatue), and its core value proposition is compliance speed. It is SOC 2 Type II certified with continuous compliance monitoring, and its headline feature is one-click STDIO-to-managed conversion: you take a local MCP server, and MintMCP wraps it with OAuth and audit logging almost instantly.

For teams that have built a bunch of local STDIO-based MCP servers (which is most of the community, honestly) and need to make them production-ready without rebuilding infrastructure from scratch, MintMCP is genuinely fast to get running.

Genuine limitations: It is managed-only, so there is no self-hosted option. For regulated industries with data residency requirements, that is often a hard no. It also does not do LLM routing, so you would need a separate tool for model-level governance. And as a younger company, it has less of a production track record at Fortune 1000 scale than TrueFoundry does.

3. Composio

Best for: Teams whose agents need to connect to dozens of SaaS tools immediately

Composio takes a different philosophical approach. Rather than building a gateway for infrastructure you deploy, it is a managed integration platform with 850-plus pre-built connectors for tools like Slack, GitHub, Jira, Salesforce, and hundreds of others. Its focus is breadth: get agents connected to the SaaS tools they need as fast as possible.

The value is real. If you are building an agent that needs to touch ten or fifteen different SaaS products, building and maintaining those connectors yourself is months of work. Composio handles authentication lifecycle, schema drift, malformed payloads, and a lot of the operational overhead that makes integrations annoying in practice. It is also SOC 2 Type II and ISO 27001 certified, and it has RBAC controls at the action level.

Genuine limitations: Composio is managed-only, no self-hosted option. The governance depth is narrower than enterprise-focused options: it is optimized for breadth of connectivity, not deep policy enforcement. The tools are also closed-source, so if a pre-built connector does not behave exactly the way you need it to, your options are limited. Premium tool calls (semantic search, code execution) run at 3x the standard rate, which can make costs unpredictable at scale.

4. Docker MCP Gateway

Best for: Developers building locally who want container isolation and familiar tooling

Docker's approach is container-native: each MCP server runs in its own isolated container with resource limits and cryptographic image signing for supply chain security. If your team lives in Docker and Kubernetes already, the mental model is comfortable. There is real value in the isolation guarantees for local development environments.

Genuine limitations: This is fundamentally a local development tool. There is no production governance: no RBAC, no audit logging, no centralized access control. Scaling to enterprise requires significant DIY effort to bolt on authentication, identity management, and audit infrastructure. I have seen teams try to build production systems on Docker MCP Gateway and end up with a fragile collection of glue code that nobody wants to own.

5. MCPJungle

Best for: Experimenters who want a simple open-source aggregation layer

MCPJungle is an open-source MCP gateway focused on aggregation and tool discovery. Setup is simple, which is its main appeal. For individual developers trying to understand how gateway aggregation works before committing to a platform, it is a reasonable starting point.

Genuine limitations: It is very early stage. Governance features are minimal, documentation is thin, and the community is small. I would not run anything customer-facing on this today.

6. IBM ContextForge

Best for: Large enterprises with distributed teams needing multi-cluster federation

ContextForge is an open-source, Kubernetes-native MCP gateway with federation built in. Multiple gateway instances auto-discover each other, merge tool registries, and operate as a unified system across regions. It also supports protocol bridging, so legacy REST and gRPC services can be exposed as MCP tools without rewriting them.

That federation architecture is a genuine differentiator if you are a global enterprise running infrastructure across multiple regions or subsidiaries. IBM's broader enterprise ecosystem integrations are also real.

Genuine limitations: Setup is complex, designed for organizations with sophisticated DevOps teams. Reported latency sits at 100 to 300ms per operation, which is significantly higher than other options and may be an issue for latency-sensitive workloads. It is also worth noting that ContextForge is a community project, not an officially supported IBM product, so you are largely on your own operationally.

7. Lasso Security MCP Gateway

Best for: Teams where threat prevention is the primary concern

Lasso takes a security-first approach with reputation scoring for MCP servers, real-time threat detection, and PII leakage prevention via Presidio integration. If your primary concern is preventing prompt injection and protecting sensitive data flowing through agent-tool interactions, Lasso addresses that more directly than most.

Genuine limitations: The feature set is narrower for general MCP management. Routing, observability, and governance capabilities are less mature than the enterprise-focused options. It is best thought of as a security layer to add on top of other infrastructure, not a complete gateway solution on its own.

The Comparison Table

MCP Gateway	RBAC Depth	Audit Logging	SOC 2 Certified	Self-Hosted	Also Routes LLMs?	Pre-Built Integrations
TrueFoundry	Deep, per-tool	Yes, full traces	Yes (also HIPAA, ITAR)	Yes (VPC/on-prem)	Yes	No (deploy your own)
MintMCP	Role and tool-level	Yes, SOC 2 format	Yes (Type II)	No (managed only)	No	No
Composio	Action-level RBAC	Yes	Yes (SOC 2 + ISO 27001)	No (managed only)	No	850+
Docker MCP Gateway	None built-in	None built-in	No	Yes	No	No
MCPJungle	Minimal	Minimal	No	Yes	No	No
IBM ContextForge	Moderate	Basic	No	Yes	Limited	No (protocol bridging)
Lasso Security	Moderate	Yes (security focus)	Partial	Limited	No	No

What I Learned From the Actual Evaluation

The thing that surprised me most was how few teams have thought through the full lifecycle question. Most conversations start with "how do I secure access to MCP servers?" and stop there. But the harder question is "who owns deploying those servers, updating them, monitoring their health, and deprecating them when the underlying API changes?"

TrueFoundry is the only platform that takes a position on the whole lifecycle rather than just the gateway layer. That is why it ended up being the recommendation for my financial services client, whose platform team needed a single pane of glass, not a collection of specialized tools stitched together.

MintMCP won a secondary engagement at the same company for a faster-moving team that needed to wrap some internal STDIO servers quickly and could not wait for the full platform rollout. The one-click compliance workflow is legitimately useful if you are willing to accept managed-only deployment.

Composio came up in every conversation about rapid prototyping and SaaS connectivity. The breadth of pre-built integrations is a genuine time-saver at the prototyping stage. The teams that outgrew it did so because they needed to customize connector behavior and hit the closed-source wall.

Docker MCP Gateway is fine for local work. I keep seeing it in lists of "enterprise MCP gateways" and that categorization does it a disservice. It is a developer tool, not a production platform.

A Few Questions Worth Asking Before You Pick

If you are going through your own evaluation, these are the questions that cut through a lot of marketing noise:

1. Where does the data actually go? Managed-only gateways require you to trust a vendor's infrastructure with your agent's tool calls, which may include internal API responses, database query results, and other sensitive payloads. If your security or compliance team has data residency requirements, that eliminates several options.

2. Do you need LLM routing and MCP governance in the same system? If yes, that significantly narrows the field. TrueFoundry is the main option that does both natively.

3. How much platform team capacity do you have? More capable platforms require more operational investment. If you have a small team, a managed option with less flexibility might be the right tradeoff even if it costs more.

4. What does your existing MCP server estate look like? Mostly STDIO local servers? MintMCP's conversion workflow is genuinely compelling. Starting from scratch and need SaaS connectivity fast? Composio's 850-plus integrations is hard to beat in the short term.

My Verdicts

Pick TrueFoundry if you need MCP governance unified with LLM routing and model deployment, are running production AI workloads at scale, and have a platform team that can take ownership of the infrastructure. The Gartner recognition and Fortune 1000 customer track record are real signals, not just marketing.

Pick MintMCP if you need SOC 2 compliance out of the box and zero infrastructure management, and you are comfortable with a managed-only deployment model.

Pick Composio if your agents need to connect to dozens of SaaS tools immediately and you can live with the tradeoffs around governance depth and customizability.

Pick Docker MCP Gateway if you are still building locally and want container isolation. Plan to revisit this decision before you go to production.

The right answer genuinely depends on where your organization is today: how mature your platform team is, what your compliance requirements look like, and whether you are still experimenting or already running agents that touch production systems. Hopefully the breakdown above gives you enough signal to figure out which of those buckets you are in.

If you have run any of these in production and have a different experience than what I described, I would genuinely love to hear it in the comments. My evaluation was thorough but not exhaustive, and the landscape is moving fast enough that things I found six weeks ago may already be out of date.

GitHub Broke Git: The Merge Queue Bug That Silently Deleted Your Code

Varshith V Hegde — Sun, 03 May 2026 03:09:35 +0000

If you use GitHub's merge queue and had a rough week around April 23rd, 2026, you were not imagining things. Your code actually disappeared. Not because of a bad commit, not because of a rogue team member, but because GitHub itself quietly deleted it.

This is the story of what happened, why it was way worse than the official numbers suggest, and what it means for the way we all trust the tools we build on.

The Day GitHub Stopped Being Git

At 16:05 UTC on April 23rd, 2026, a regression crept into GitHub's merge queue. For the next three and a half hours, engineers around the world were reviewing pull requests, clicking "merge," and watching everything look completely fine. Green checks. Clean diffs. No warnings.

What was actually happening behind the scenes was quietly horrifying.

A PR with a perfectly reasonable +29 / -34 diff would get approved and queued. What landed on main was a commit worth +245 / -1,137. Thousands of lines of code that other engineers had already shipped, reviewed, and moved on from, just gone. And every merge that came after went in on top of that broken history.

The UI showed zero problems. The status page showed no outage. The platform was lying to everyone's faces.

What Actually Went Wrong Under the Hood

GitHub's merge queue works by creating a temporary branch for each PR in the queue. Normally, that temp branch starts from the tip of main plus the PR's diff. CI runs against it, it passes, it lands.

On April 23rd, the queue started building those temp branches from the wrong starting point. Instead of branching from the current tip of main, it was branching from wherever the feature branch had originally diverged from main, potentially dozens or hundreds of commits back.

Then it pushed the entire contents of that temp branch to main.

So if your feature branch was 50 commits behind main when it hit the queue, the "merge" silently removed those 50 commits of other people's work as a side effect of landing yours. CI passed because the temp branch on its own was internally consistent. main blew up because the temp branch had nothing to do with the current state of main.

The root cause? A new code path that adjusted merge base computation was meant to be gated behind a feature flag for an unreleased feature. The gating was incomplete. The new behavior leaked into production and applied to all squash merge groups.

Three things made this bug particularly nasty:

1. The PR UI lied. You reviewed +29/-34. The commit that landed was +245/-1,137. The thing engineers approved was not the thing that merged. That breaks the most fundamental contract of a code review system.

2. It was completely silent. No merge conflict. No failed check. No banner on the PR. Teams only found out when someone noticed code on main that should have been there simply was not.

3. It scaled with repo activity. The faster a repo was merging, the further feature branches had drifted from main, and the more damage each bad merge did. The teams that relied most on merge queue got hit the hardest.

The Human Cost

This was not a theoretical problem. Engineering teams spent entire afternoons in incident mode: combing through commit graphs, reconstructing deleted code by hand, coordinating recovery across multiple repos, and filing support tickets that would take days to hear back on.

One organization reported that every single team running on GitHub's merge queue got hit, with dozens of bad commits each and hundreds of existing commits clobbered before anyone noticed. One company alone claimed to have experienced over 200 ruined PRs.

GitHub later said 2,092 pull requests across 230 repositories were affected during the impact window of April 22 to 23. Earlier messaging from GitHub's COO on X had put the number at 2,804 PRs, and some community members pushed back hard on both figures given what individual companies were experiencing.

The incident was not detected by GitHub's automated monitoring because it affected merge commit correctness rather than availability. GitHub only became aware of the regression at 19:38 UTC, following an increase in customer support inquiries. The fix, a revert and force-deploy, was complete by 20:43 UTC. Three hours and thirty-three minutes of silent corruption.

Why the Status Page Was Useless

Here is the part that stings. If you checked GitHub's status page on April 23rd, you probably saw nothing alarming. There was no major outage reported. No partial outage.

That is because GitHub's status page calculus specifically excludes "Degraded Performance" from downtime numbers. The platform itself never went down. Developers could still push code, open PRs, and click merge. The fact that clicking merge was silently destroying their codebase did not register as an incident on the dashboard.

This is a telling gap. Uptime and correctness are not the same thing. A bank that processes your transactions but records them incorrectly is not "up." GitHub processed the merges. It just produced wrong results. The status page was not built to catch that kind of failure.

This Was Not an Isolated Bad Day

It would be easier to move on from this if it were a one-off. But April 2026 was a genuinely rough stretch for GitHub.

Four days after the merge queue incident, on April 27th, GitHub's Elasticsearch cluster became overloaded, likely from a botnet attack, and search-backed UI surfaces stopped returning results. Pull request lists went blank. Issues disappeared from view. Projects and Actions workflow pages showed nothing. The underlying data was still there, but developers could not see it.

And then, on April 28th, the same morning GitHub's CTO published an apology post about reliability, a separate security disclosure dropped: researchers at Wiz had found a critical remote code execution vulnerability in GitHub's git push pipeline (CVE-2026-3854, CVSS 8.7). A single crafted git push with injected options could reach unsandboxed code execution on GitHub's servers. It was patched in 75 minutes on github.com, but the timing was brutal.

Three significant failures in five days. Merge queue correctness. Search collapse. An RCE in the core git push path.

GitHub's CTO, Vlad Fedorov, acknowledged in the April 28th post that none of this is acceptable. He also revealed the scale of what GitHub is dealing with: the company had planned to scale capacity by 10x in October 2025. By February 2026, projections driven by agentic development workflows (AI coding tools like Copilot, Cursor, and Codex flooding the platform with automated PRs) forced a rethink to a 30x redesign. GitHub is now hitting peaks of 90 million merged PRs and 1.4 billion commits.

The Deeper Architectural Problem

There is a reason this specific failure mode existed. GitHub's merge queue constructs merge commits through a code path that is separate from how a regular PR merge works. Two code paths, two places where behavior can quietly diverge.

This is the danger that comes with delegation. A merge queue is supposed to automate exactly what a human would do when clicking "Merge pull request." The moment it does something a human would not do, because it has its own logic for building the merge commit, it can silently produce commits nobody wrote and nobody approved.

This is not just a GitHub problem. It is a pattern that shows up every time we give automated systems write access to things that matter. Queues, bots, AI agents. As long as those systems are doing something equivalent to what a human would do, the failure modes are familiar. When they start doing things a human would not do, the failures become invisible until the damage is already done.

The lesson is not to avoid merge queues. It is to make sure that whatever writes to main stays as close as possible to boring, well-understood git operations, with no novel logic in the merge commit path that reviewers cannot audit.

Will Anyone Actually Leave?

After something like this, the obvious question is whether developers will migrate off GitHub. And the honest answer is: probably not in any significant numbers.

GitHub is deeply embedded. CI pipelines, webhook integrations, RBAC policies, Actions workflows, third-party app permissions, team structures, pull request history. Migration is not just switching a remote URL. It is months of work and coordination.

That stickiness is real and it is not purely irrational. GitHub is still where most open source lives. It is still where most integrations point. It is still the default. The addictive hold it has over the development ecosystem is less like a premium SaaS product and more like a utility. You do not switch utilities because of a bad week.

But what this incident should change is the baseline of trust. GitHub is infrastructure. And infrastructure that silently corrupts your data, even for a few hours, with no visible error, is infrastructure you need to have a recovery plan for.

The minimum response is not migration. It is verification. Audit squash merges in merge queue groups of two or more PRs from the April 22 to 23 window. Write down which parts of your build and deploy pipeline silently assume git history is correct. Then make that assumption visible somewhere it can be challenged.

What GitHub Says It Is Doing About It

GitHub's post-incident response included a few concrete commitments:

Expanding test coverage for merge correctness validation
Adding regression checks that validate resulting git contents across supported merge configurations before reaching production
Migrating performance-sensitive code from its older Ruby codebase to Go
Moving systems to public cloud infrastructure to handle the 30x scale requirement

The April 23rd bug specifically was caused by incomplete feature flagging on a new code path. The fix was a revert. The longer-term fix is better test coverage for multi-PR merge queue groups, which were apparently underrepresented in existing test suites.

The Takeaway

GitHub's merge queue, for a few hours on April 23rd, 2026, broke the most fundamental contract of version control: that what you approve is what merges. It did it silently, with clean green UI, no errors, and no status page entry.

The code was still there in Git object storage. But the branch history was wrong, and no automated system could safely repair it across every affected repository. Engineers had to do it by hand.

That is the thing that lingers. Git is supposed to be the boring, reliable layer that everything else is built on. When the boring layer gets interesting, it gets interesting in the worst possible way.

If you found this useful, drop a comment below or follow for more deep dives into the tools we trust (sometimes too much).

7 AI Gateways That Actually Work in Production (2026 Guide)

Varshith V Hegde — Wed, 29 Apr 2026 12:19:13 +0000

Let me start with an admission. I resisted using an AI gateway for longer than I should have.

My reasoning was the kind engineers convince themselves is pragmatic. "I'll just call the APIs directly, it's faster to ship, I'll add abstraction later." And for a while, it worked. Until the night an Anthropic outage knocked my app offline for two hours. Until the morning a recursive agent loop racked up thousands of dollars in charges before anyone woke up. Until the security audit flagged raw API keys scattered across four different repos.

At that point, "later" arrived.

I've spent the past several months evaluating AI gateways seriously. Not as a researcher, but as someone trying to put them in front of real production workloads. This is what I found.

First: What Does an AI Gateway Actually Do?

Before the list, let me be specific about what we're talking about, because the category name is increasingly used to mean very different things.

Gartner defines an AI gateway as "a technology or platform that acts as an intermediary between applications and various AI services or models." That is the clean academic definition. In practice, a good AI gateway is the layer that keeps your AI app running when things break. And things always break.

Concretely, that means handling:

Routing - intelligently directing requests to the right model based on cost, latency, or availability
Failover - automatically switching providers when one goes down, often in under 50ms
Cost controls - per-team or per-key budget limits so no single runaway agent bankrupts you
Key management - one secure central store for credentials instead of env vars scattered across repos
Observability - request-level traces, latency metrics, and token usage across every provider in a single dashboard
Compliance - audit logs, role-based access control, and data residency guarantees

Different gateways prioritize different things. Some are razor-thin proxies optimized for speed. Others are full control planes designed to govern how an entire organization uses AI. The right choice depends entirely on where your pain is.

Here are the seven worth knowing in 2026.

Quick Comparison

Gateway	Latency	MCP Support	On-Prem/VPC	Compliance	Gartner Recognized	Best For
TrueFoundry	~3-4ms	Yes	VPC, On-Prem, Air-Gapped	SOC 2, HIPAA, ITAR	Yes	Enterprise with compliance + deployment needs
Helicone	under 5ms P95	No	Self-hosted option	SOC 2	No	Observability-first teams
OpenRouter	~15ms	No	Managed only	None	No	Prototyping, widest model access
Requesty	~8ms P50	No	No	GDPR (EU endpoint)	No	Fast multi-model routing with analytics
Singulr AI	N/A	Partial	Limited	In progress	No	AI governance-focused orgs
Inworld Router	N/A	No	No	None	No	Quality-weighted routing experiments
Braintrust Gateway	Cached under 100ms	No	Enterprise tier only	SOC 2	No	Eval + routing in one workflow

1. TrueFoundry AI Gateway

The Enterprise Production Pick

I'll be honest. TrueFoundry was not the first gateway I tried. It kept coming up in conversations with platform engineers at companies doing serious AI at scale, and once I actually dug in, the reason became clear.

TrueFoundry is an enterprise AI gateway and more specifically, it is the only Gartner-recognized AI gateway that also handles model deployment and GPU orchestration in the same platform. Most gateways on this list are proxies with dashboards. TrueFoundry is closer to a full AI control plane, the kind of thing a platform team would build internally at a large company, except you do not have to build it yourself.

The numbers that matter

The platform handles over 10 billion requests per month for Fortune 1000 customers including NVIDIA and Siemens Healthineers. The gateway adds roughly 3-4ms latency overhead per request and can sustain 350+ RPS on a single vCPU. These are not lab benchmarks. They are the numbers that show up in production.

Where it genuinely stands apart on compliance

SOC 2, HIPAA, and ITAR certified. For anyone in healthcare, financial services, defense, or any regulated industry, this is often the conversation that ends competitor evaluations. Most other gateways on this list have none of these certifications, or are still working toward them.

The deployment flexibility is real

VPC, on-premises, and air-gapped deployments are all supported. If your security posture means data cannot touch a public cloud, TrueFoundry actually works. Not as an afterthought, but as a first-class deployment mode.

The MCP piece deserves its own moment

As AI agents multiply, teams are suddenly managing not just LLM calls but tool access: MCP servers for code execution, database queries, web search, enterprise integrations. TrueFoundry unifies LLM routing and MCP governance in the same control plane, with OAuth2, RBAC, and audit logging applied to every tool call. You can register internal MCP servers, define who can access what, and monitor agent tool usage alongside your LLM traffic, all in one place. No other gateway on this list does that.

On Gartner Peer Insights, one enterprise customer said: "AI Gateway is a single pane where I can see all the models, their associated cost, track requests... it provides an easy way to integrate with MCP servers which does a very heavy lift." That lines up with what I have heard from teams using it at scale.

Where it genuinely falls short

TrueFoundry is a heavier platform. If your requirement is "I need a quick proxy to route between GPT-4 and Claude," this is more infrastructure than you need. It is also strongest when there is a dedicated platform or infra team who can own it. Solo developers or very small teams will find the setup investment harder to justify compared to lighter alternatives.

The bottom line

TrueFoundry is the only Gartner-recognized AI gateway on this list and the only one that unifies LLM routing, MCP governance, and model deployment in a single control plane. If you are running production AI for an enterprise with compliance requirements, it is in a different category from the proxies below.

Website: truefoundry.com/ai-gateway

2. Helicone AI Gateway

The Observability-First Pick

Helicone has earned genuine respect in the developer community for a specific reason. If you want to understand what your AI application is actually doing, it is excellent.

It is Rust-based, open-source, and fast. The team describes it as "the NGINX of LLMs," and that is not just marketing. The architecture reflects it. You get a unified API for 100+ providers through a single OpenAI-compatible endpoint, with automatic failover, load balancing, and per-request logging built in from the start.

The analytics dashboard is one of the more useful ones I have seen: per-request cost tracking, model comparison, session-level traces, and usage patterns broken out by team, model, or environment. For understanding where your AI spend is actually going, Helicone is hard to beat.

It is also SOC 2 certified and GDPR compliant, with a self-hosting option for teams that need infrastructure control. That is a meaningful step up from pure managed-only options.

Where it falls short

No MCP gateway support. If you are building agents that need governed tool access, you will need to look elsewhere for that layer. Governance features like RBAC depth and policy enforcement are more basic compared to enterprise platforms. It is primarily an observability platform with routing layered on, not a full deployment and governance story.

Best for teams where LLM observability and cost analytics are the primary pain point. If you already have routing handled but want real visibility into what is happening across your models, Helicone is a solid, developer-friendly choice.

3. OpenRouter

The Widest Model Access, Fastest to Start

OpenRouter is how I reach 300+ models through one API when I am prototyping. No infrastructure to manage, unified billing across providers, and instant access to everything from GPT-5 to Llama to Mistral variants through a single OpenAI-compatible endpoint.

The pricing model is worth understanding correctly. OpenRouter actually passes through provider pricing at or near cost. It is a 5.5% platform fee on credit purchases, not a per-token markup on inference. For most use cases, you are paying what you would pay the provider directly, plus a small convenience fee for the unified access. They do not train on your data, and there is a growing free tier with 25+ zero-cost models for getting started.

For prototyping, experimenting with different models, or any project where you need breadth over depth, OpenRouter is genuinely hard to beat on speed of getting started.

Where it falls short

Managed only, no self-hosting option. No MCP support. Governance features are minimal: no RBAC, no compliance certifications, no fine-grained access controls built for regulated industries. The 100 API calls per 60 seconds default throttling can become a real constraint for high-volume agent pipelines.

Best for prototyping, side projects, or teams that need fast access to the widest range of models and are not yet in a compliance conversation.

4. Requesty

Smarter Than It Looks

Requesty is a gateway I underestimated at first glance. The website looks simple. That turned out to be a mistake.

Requesty is a unified LLM gateway for 400+ models, and what sets it apart from pure model-access tools is the routing intelligence. It includes smart routing that analyzes request type and auto-selects the cheapest viable model, cross-provider semantic caching (which can cut token costs by up to 80% on repeated queries), real-time PII redaction, and sub-50ms automatic failover when a provider goes down.

According to their own data, 70,000+ developers use it and it processes 90+ billion tokens daily. Those are numbers that suggest it is more battle-tested than its marketing implies. There is an EU endpoint for GDPR compliance, per-key spending limits, and a genuinely useful analytics dashboard.

Setup is three lines of code. Swap the base URL. Done.

from openai import OpenAI

client = OpenAI(
    base_url="https://router.requesty.ai/v1",
    api_key="your-requesty-key"
)

Where it falls short

Managed only, no self-hosting or VPC deployment. No MCP governance. No enterprise compliance certifications beyond GDPR. For teams in regulated industries or those needing air-gapped deployment, it does not get you there.

Best for developers who want a capable, managed multi-model gateway with smart routing and cost optimization, without the infrastructure overhead of a full enterprise platform.

5. Singulr AI

The Governance-Focused Newcomer

Singulr AI is an enterprise AI governance platform backed by Nexus Venture Partners and Dell Technologies Capital. It raised $10M in early 2025 with a specific focus: helping security, IT, privacy, and compliance teams gain visibility and control over how AI is being used across an organization.

The approach is distinctive. It includes a continuously updated AI risk intelligence system that profiles models and agents, classifies them in real time, and recommends safer alternatives. It also offers application-aware red teaming that simulates real-world threats before deployment.

For CISOs and compliance teams, this is interesting. It is a governance-first angle that most gateway vendors leave to someone else.

Where it falls short

It is a newer entrant with limited public production track record at Fortune 1000 scale. The feature set is narrower than full gateway platforms. It is primarily governance and security, not a complete routing, failover, and deployment story. Pricing is not public.

Best for organizations where AI governance, risk scoring, and compliance team enablement are the primary requirements, and who are comfortable evaluating a platform that is still building its enterprise reference base.

6. Inworld Router

An Interesting Idea Worth Watching

Inworld Router takes a genuinely different approach to the routing problem. Instead of routing based purely on cost or availability, it routes on business-level metrics: cost per output quality, task complexity, latency targets. The idea is that not every request needs the smartest and most expensive model, and a router that understands the nature of a request can make smarter tradeoffs than one that just round-robins.

That is a legitimate insight, and as a concept it points toward where sophisticated AI infrastructure is heading.

In practice today, it is primarily built for Inworld's own gaming and character AI use case. The ecosystem is small, community support is limited, and it is not a general-purpose enterprise gateway.

Best for teams in gaming or character AI who want to experiment with quality-weighted routing. Worth keeping an eye on as the concept matures.

7. Braintrust Gateway

The Eval-First Option

Braintrust is fundamentally an evaluation and observability platform that also includes a capable gateway. The integration between the two is the real story. Requests that flow through the gateway automatically feed into Braintrust's tracing and evaluation pipeline. You can run evaluations against production traffic, compare model performance across experiments, and catch regressions in CI/CD before they reach users.

The gateway supports 100+ models including GPT-5, Claude 4, and Gemini 2.5. Caching is encrypted per-API-key using AES-GCM, with sub-100ms response times for cached requests. There is a generous free tier (1M trace spans, 10k evaluation scores) and SOC 2 Type II certification on the enterprise side.

One important note: their original AI proxy is now deprecated. They have migrated to a full gateway product, which is a meaningful upgrade for production reliability.

Where it falls short

The gateway features are secondary to the eval platform, which is by design, but means it is not a full story for failover, MCP governance, or compliance-heavy deployments. Self-hosting is only available on the enterprise tier. At $249/month for the Pro plan, it is not the lightest option for teams that only need routing.

Best for engineering teams doing active prompt optimization and model comparison who want routing and evaluation tightly integrated, and do not want to stitch together separate tools for each.

How to Actually Choose

After spending real time with all of these, here is my honest decision framework.

The compliance conversation is the first filter. If your security team needs SOC 2, HIPAA, or ITAR, or if data cannot leave your cloud, the list immediately narrows to one serious option: TrueFoundry. This is not a sales pitch. It is just where the certifications are.

The MCP question is the second filter. If you are building agents that need governed tool access, only TrueFoundry covers this layer natively today.

If you clear both of those, the rest is about fit:

Pick TrueFoundry if you need enterprise governance, compliance, and model deployment in one platform
Pick Helicone if observability and cost analytics are your primary pain and you want something developer-friendly and open-source
Pick OpenRouter if you are prototyping and want the fastest possible access to the widest range of models
Pick Requesty if you want a capable managed gateway with smart routing and you are not in a compliance-heavy environment
Pick Braintrust if prompt evaluation and model quality monitoring are central to your workflow

Where This Category Is Going

Something I have noticed in 2026 is that the definition of "AI gateway" keeps expanding. A year ago it meant a proxy with routing logic. Now teams are asking their gateway to handle agent tool access via MCP, govern agent-to-agent communication, manage model deployment, and provide compliance audit trails across all of it.

That is a lot to ask of a single layer. Most of the lighter options on this list handle one or two of these well. TrueFoundry is the only one I have seen genuinely attempting the full stack, and it has the production evidence to back that up: 10B+ requests per month, Fortune 1000 customers, and Gartner recognition.

Whether you want one vendor for all of that, or best-of-breed at each layer, is a real architectural choice. Either can work. The important thing is making it deliberately, rather than discovering two years in that your "lightweight proxy" cannot support what your AI stack has become.

What is your experience been? I am especially curious if anyone has moved from a lighter gateway to something heavier, or the other direction, and what triggered that switch. Drop a comment below.

I Spent 3 Days Debugging Our LLM Setup. Turns Out We Needed an AI Gateway the Whole Time.

Varshith V Hegde — Wed, 15 Apr 2026 08:46:08 +0000

Let me tell you about a Friday afternoon I'd rather forget.

Three teams, four models, six API keys living in different .env files, one very angry compliance officer, and me just staring at a terminal trying to figure out why we got a $1,400 OpenAI bill for a feature that was supposed to cost fifty bucks.

That was my "okay something is genuinely broken here" moment.

Not some big insight. Just a $1,400 invoice and dead silence on a Slack thread for about ten minutes.

If you've felt even a small version of that, this post is for you.

So what actually is an AI Gateway?

Not the textbook answer. That one goes something like "middleware that abstracts your LLM provider calls." Technically fine, tells you nothing.

Here's how I actually think about it.

You know how bigger engineering orgs eventually build out a platform team? Before that team exists, every squad is doing their own thing. Their own CI setup, their own infra configs, their own credentials. It mostly works. Until it doesn't. And then it catastrophically doesn't all at once.

An AI Gateway is basically that platform layer, except it's for LLMs.

Every single request your app makes to any model (OpenAI, Anthropic, a self-hosted Llama, whatever you're running) goes through it. Because everything flows through one place, you finally get:

One set of credentials instead of keys scattered across five repos
Rate limits and budgets that are actually enforced
Cost tracking per team, per model, per request
Guardrails that catch PII before it leaves your infra
One place to look when something blows up

One control plane. Every team. Every model.

The architecture is simpler than it sounds

Here's what happens when you put a gateway in the middle:

Request comes in from your app, gateway catches it, validates auth, checks rate limits, applies input guardrails, picks the right provider, logs everything, checks the response output, sends it back. That's the whole flow.

Your application code doesn't change. You stop pointing at api.openai.com directly and point at your gateway instead. That's literally it from your team's perspective.

The control layer just sits there doing its job quietly.

"But I already have an API gateway. Isn't that enough?"

This is where most people get confused. Including me when I first looked into this.

Quick answer: no. Here's why.

Your API gateway (Kong, AWS API Gateway, Nginx, take your pick) understands traffic. It knows Team A sent 10,000 HTTP requests. It can enforce rate limits, handle auth tokens. That's useful.

Your AI gateway understands what's actually inside those requests. It knows Team A sent 4.2 million tokens to GPT-4o, it cost $84, average latency was 340ms, and 3 of those requests triggered the PII guardrail.

One sees requests. The other sees meaning. That's not a small difference.

For stateless REST APIs, a regular API gateway is totally fine. For LLM workloads where tokens equal money and every prompt is a potential compliance issue, you need something that actually speaks the language.

Do you actually need one right now though?

Let me skip the usual "it depends" and be direct.

You're probably fine without one if:

One team, one model, one use case
Nobody is asking about costs yet
Zero compliance requirements
It's a POC or side project

Don't add infrastructure you don't need. Raw SDK calls are fast to ship. Keep it simple when simple works.

You've outgrown the simple setup if:

Multiple teams are calling models independently with no visibility into what they're doing
Swapping providers requires actual code changes
Someone from legal or security or finance asked a question you couldn't answer
You've had an API key accidentally committed to a public repo (or almost did)
You can't answer "what did we spend on AI last month, by team?" without going on a scavenger hunt through billing dashboards

That last point is genuinely the biggest tell. If someone asks that question and you have to go digging, you already needed this.

What actually pushes teams over the edge

It's never one thing. It's always a pile of smaller things that suddenly feel heavy together.

DevOps realizes they can't track spend because keys are everywhere. Someone commits a key to a public repo. A team uses GPT-4 Turbo for tasks that GPT-4 Mini handles just fine, and you find out after they've burned $2K. Compliance asks for an audit trail and you have nothing.

Each of those individually, fine, you deal with it. All of them stacking up at the same time? That's when the "simple" setup reveals it was never actually simple. You were just deferring the complexity.

What a production gateway actually looks like

Okay enough talking around it. Here's what it gives you in practice, using TrueFoundry as the concrete example.

One API key across all providers

Your teams stop touching raw OpenAI or Anthropic keys entirely. One key, routed through the gateway, with access to every approved model. Rotate it in one place. Done.

Per-team budgets with real enforcement

Not "we log it and send you a Slack alert." Actual hard limits. Team hits their monthly budget, the next request gets rejected with a clear error. No surprise bills, no awkward retros about where the spend went.

Automatic failover

OpenAI goes down. It happens. Your app doesn't go down with it because requests automatically route to Anthropic or your self-hosted model. No code changes. No one gets paged. It just keeps working.

Full request tracing

Every prompt, every response, every token count, every cost attribution. Logged and queryable. Pull a request from six months ago and reconstruct exactly what happened. This feature alone has saved me more debugging time than I can measure.

Guardrails that actually run everywhere

PII filtering, prompt injection detection, custom output policies. You define the rule once and it applies across every team and every model. No per-team implementation, no "oops we forgot to add the check in this service."

Runs inside your own environment

VPC, on-prem, air-gapped. Data doesn't leave your infra. SOC 2, HIPAA, GDPR compliant. If your compliance team has ever asked "but where does the data actually go," this is finally a clean answer.

Performance-wise it handles 350+ RPS on a single vCPU with sub-3ms latency so you're not adding meaningful overhead to your request path.

TrueFoundry is in the 2026 Gartner Market Guide for AI Gateways and processes 10B+ requests per month for companies like Siemens Healthineers, NVIDIA, Resmed, and Automation Anywhere. Mentioning it not as a flex but as a sense of scale.

The question that actually helped me decide

Forget "do I need an AI gateway."

Ask this instead: when does the cost of NOT having one start to exceed the cost of setting one up?

For most teams that crossover happens way earlier than expected. For us it wasn't one event. It was the accumulation. The audit trail we didn't have. The $1,400 bill nobody could explain. The near-miss with a key in a public repo.

Setting up TrueFoundry honestly took less time than the post-mortem meeting for that billing incident.

Try TrueFoundry free at truefoundry.com (no credit card required, deploys on your cloud in under 10 minutes).

What does your current setup look like? Still on raw SDK calls or have you already hit the wall? Drop a comment, genuinely curious where people are when they start asking this question.