DEV Community: Basavaraj Patil

Three bugs that each cost me a full day building a self-hosted AI gateway on Supabase

Basavaraj Patil — Mon, 24 Aug 2026 16:34:23 +0000

I've been building an open-source project called Keyroute, a self-hosted AI API gateway that lets you use one API key to route requests to multiple providers (OpenAI, Gemini, Groq, etc) instead of juggling separate keys and separate integration code for each one.

The whole point of it is that it runs entirely inside YOUR own Supabase project, not on any server of mine. No relay, no third party sitting between you and your AI provider. Setup is one button, no CLI needed.

Getting there wasn't smooth. Here are three bugs that each ate a full day, in case any of these save someone else the same pain.

Bug 1: "Invalid multipart boundary"

The Deploy Gateway button needs to actually deploy a Supabase Edge Function programmatically, through Supabase's Management API, from the browser.

My first attempt sent JSON, since that's what basically every other API expects these days. Kept getting rejected with an "Invalid multipart boundary" error that told me nothing useful.

Turns out the function-deploy endpoint needs real multipart/form-data: the slug goes as a query param, there's a metadata part as a JSON string, and then one separate file part per source file. Not obvious at all from the error message, took a lot of trial and error against a real project to get the exact shape right.

Bug 2: the email domain nobody warns you about

Since Keyroute has no login/signup flow (there's a single auto-provisioned owner account created during setup), I needed to generate a synthetic email for that account behind the scenes.

First attempt: owner@local.keyroute. Rejected by Supabase Auth as invalid.

Second attempt: I switched to my own real domain, @local.basavaraj.dev. This worked, but it bugged me, since it meant every single person who self-hosts this project would have my personal domain baked into their database. Not a good look for an open source project other people are supposed to run themselves.

Ended up landing on @example.com, which is an actual RFC 2606 reserved placeholder domain, made exactly for situations like this. Verified it against real Supabase Auth and it worked cleanly. Small fix, but the kind of thing that's easy to get wrong in a way that quietly ships something awkward.

Bug 3: RLS was right, but reads still failed

This one really got me. I had Row Level Security policies set up correctly on four tables. Tested with a real, valid, logged-in session. Reads still failed.

Spent a long time assuming this was a session or auth token issue, since that's usually what "valid session but no data" means.

It wasn't. In Postgres, RLS policies and table-level GRANTs are two completely separate permission systems. You can have perfect RLS policies and still block every request if the authenticated role was never explicitly granted access to the table itself. I'd done the policies and just... never done the grants.

Once I ran the GRANT statements, everything worked instantly. Felt a little silly after how long I spent debugging it as an auth problem.

Bonus lesson: don't trust "commit succeeded" from an AI coding tool

Not a code bug, but worth mentioning since it almost caused a real problem. I'm using an AI coding assistant to help implement changes, and at one point it reported "committed and pushed successfully" when in reality only git add had run, no commit ever happened.

I only caught it because I checked GitHub directly and saw nothing new there. Now I always verify against raw git log / git status output myself instead of trusting a prose summary, especially for anything commit or push related.

Where it's at now

Keyroute is open source, MIT licensed, and self-hostable. Still has some gaps (no Anthropic routing yet, no rate limiting yet, single-owner model for now), but the core flow works end to end.

Repo: github.com/basavarajpatil660/the-keyroute-project

If you've hit similar Supabase Edge Function or RLS quirks, or have thoughts on the architecture, I'd genuinely like to hear about it.

I built a Telegram-native AI agent on free-tier infra — here's the stack and what broke

Basavaraj Patil — Thu, 09 Jul 2026 20:30:00 +0000

I'm Basavaraj Patil (Basavaraj_nick), a self-taught dev and CS diploma student, and I built a Telegram-native multi-agent AI system entirely on free-tier infrastructure — no server bills, no paid APIs. Here's how it works, and what broke along the way.

What it does

It's not a chatbot. It's a full agent system that lives inside Telegram — 14+ commands, 8 autonomous sub-agents running on schedules, image generation, web research, and memory that persists across conversations. All of it running on free tiers.

The stack

Cloudflare Workers — two workers (github-backend + image-api) handle routing and image requests
GitHub Actions — 8 sub-agents run on cron schedules throughout the day (IST)
Telegram Bot API — the entire interface; no web dashboard needed
Cloudflare D1 — logs commands and stats to a dashboard
Cloudflare KV — a 5-minute rolling memory window so the agent has short-term conversational context
LLM chain: Mistral → Cerebras → Groq → OpenRouter → Gemini, falling back in that order so a single provider's rate limit never takes the whole thing down
Image gen: FLUX 1 Schnell as primary, Pollinations AI as fallback
Image editing: Stable Diffusion v1.5 img2img for the /edit command
Web research: Tavily + Jina for live search grounding

Why Telegram, not a web app

Every other agent framework I looked at assumed you'd build a dashboard. I didn't want to maintain a frontend, an auth flow, and a backend just to send myself a daily briefing. Telegram already solved auth, mobile notifications, and UI. The bot is the UI.

What actually broke

A few patterns that cost real debugging time, in case they save you some:

Return-type mismatches across agents — when 8 sub-agents pass data between each other, one agent returning a slightly different shape than the next one expects fails silently until something downstream breaks.
GitHub Actions permissions on workflow files — Actions can't modify other workflow files by default; needed explicit permissions.
KV memory misconfiguration — early versions stored memory in a public repo memory.json, which is a bad idea for anything with even mildly sensitive context. Moved it to private Cloudflare KV.
RLS conflicts — wherever a database enforces row-level security, make sure your service role key is actually bypassing it where intended, or reads silently return empty sets.

Where it stands now

The repo is public and secrets-clean — full README with the architecture, a competitor comparison, and the env var table if you want to run your own version.

Repo: github.com/basavarajpatil660/Ultimate-Ai
More of what I'm building: basavaraj.dev
Project page: basavaraj.dev/projects/ultimate-ai-agent

If you're building something similar or want to talk architecture, find me at @basavaraj_nick or drop a comment below.

How I built a production AI agent system on zero budget (and what free tiers actually break first)

Basavaraj Patil — Wed, 08 Jul 2026 23:04:17 +0000

I'm a CS diploma student, and a few months back I set myself a constraint: build a real, always-on AI system, and don't spend a single rupee on infrastructure. No paid APIs, no paid hosting, nothing.
What came out of it is Ultimate AI Agent — a multi-agent system that runs entirely through Telegram. No web dashboard needed day to day, you just chat with it.
Here's what it does, and more importantly, what I learned about where free tiers actually break.
The setup
Everything lives on Cloudflare Workers, with GitHub Actions handling anything that needs to run on a schedule. The bot has 14+ commands and actually remembers recent conversation context — most toy Telegram bots don't bother with that part, but it's what makes it feel like an assistant instead of a command parser.

It can generate images (FLUX as the primary model, with a fallback so it doesn't just die when FLUX is rate-limited), pull in live web research through Tavily and Jina, and runs 8 sub-agents on autopilot — a daily AI/tech news briefing, a YouTube trend report, that kind of thing.

The thing nobody warns you about: rate limits, not compute
Going in, I assumed compute or request limits would be the wall I'd hit. They weren't.

The real bottleneck on free tiers is almost always LLM API rate limits — you get maybe a few hundred requests a day per provider before you're throttled, and that adds up fast if the bot is chatty.
The fix that actually worked: chain multiple providers instead of relying on one.
Cerebras → Groq → Mistral → OpenRouter → Gemini
If the first provider is rate-limited or errors out, the request just falls through to the next one. It's a simple try/catch chain, nothing fancy, but it's the single biggest reason this thing stays up 24/7 without me babysitting it.

Cloudflare KV + D1 cover more than you'd think
I expected to need a "real" database pretty quickly. Turns out Cloudflare KV (for fast key-value memory, like recent conversation context) plus D1 (for structured stuff — commands, logs, automation runs) covers almost everything a small-to-medium bot needs, as long as you're deliberate about what goes where. KV for anything read-heavy and short-lived, D1 for anything you actually want to query later.

GitHub Actions as a free cron service
This one felt like cheating a little. Instead of paying for a server to run scheduled jobs, GitHub Actions cron triggers handle all 8 sub-agents — news briefings, trend reports, whatever needs to run daily. It's not built for this, but it works, and it's free.

What I'd tell someone trying this
Design for provider failure from day one. Don't build around one LLM API and add fallback later — build the chain first.
Separate your memory into "needs to be fast" (KV) vs "needs to be queryable" (D1) early, or you'll end up refactoring.
Free tiers are genuinely enough for a real, working product — the constraint pushes you toward better architecture, not worse.

If you want to see the code, it's open: github.com/basavarajpatil660/Ultimate-Ai
More of what I'm building: basavaraj.dev