The Keyroute Project — Self-Hosted AI Gateway on Supabase

A self-hostable AI API gateway that runs entirely inside your own Supabase project — one URL for OpenAI, Groq, and Gemini, with your keys never leaving your infrastructure.

Keyroute is a self-hosted AI API gateway built on Supabase Edge Functions. It lets developers route requests to multiple LLM providers — OpenAI, Groq, Gemini — through one endpoint, with API keys encrypted and stored in their own Supabase project instead of a third-party server.

Tech stack: React, TypeScript, Vite, Postgres, Deno, Edge Functions, Vercel, Supabase

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

Problem

Managing API keys for multiple AI providers (OpenAI, Groq, Gemini) across several personal projects meant hardcoding a different base URL and key into every one. Rotating a single key required hunting down every project that used it. Existing hosted "AI gateway" products solved the routing problem but required trusting a third party's servers with sensitive, billable API keys — a real risk if that company changed pricing, had an outage, or shut down.

Why I built this

I had API keys for OpenAI, Groq, and Gemini scattered across a handful of personal projects — a different base URL and key hardcoded into each one. Rotating a single key meant going back and editing every project that used it.

I looked at LiteLLM first, since it's the obvious default for this problem. It's a genuinely solid tool, but it wants a proxy server running somewhere plus a Postgres database for the admin/virtual-key features — which felt like a lot of infrastructure for what was really just a handful of personal side projects. I already had a Supabase project running for other things, so I built a small gateway that lives entirely inside it instead — no separate server to provision, no extra database to stand up.

This started as a personal fix for my own workflow, and as a way to actually learn Supabase Edge Functions and Vault properly rather than just reading about them. Along the way it turned into something worth open-sourcing, because the same annoyance — API keys scattered across projects, no good way to rotate them centrally — is a problem other people building on Supabase are probably hitting too.

Is this a self-hosted alternative to LiteLLM or Portkey?

If your stack already includes Supabase, yes — that's the specific gap this fills. LiteLLM and self-hosted Portkey both require running and maintaining a separate server process. Keyroute's gateway logic runs as a Supabase Edge Function inside a project you already have, so there's no additional server to operate. It doesn't try to match LiteLLM's breadth of features (100+ providers, budgets, virtual keys) — it does one thing: route your own keys through one URL, with zero extra infrastructure beyond Supabase itself.

Is this the same as the Keyroute travel app or keyroute.net?

No. Those are unrelated products that happen to share a similar name. This project — The Keyroute Project — is a self-hosted, open-source AI API gateway. It has no connection to any travel-booking service, wireless network project, or the commercial KeyRouter.ai LLM relay.

Does Keyroute resell or provide AI models?

No. Keyroute is a key router, not a model marketplace. It doesn't offer, resell, or take a cut of any model access — it lets you route requests to the provider keys you already own, through one endpoint, with your keys encrypted and stored in your own Supabase project rather than a third party's.

Results

A fully working one-click self-hosting flow, verified end-to-end against a genuinely fresh Supabase project: Deploy Gateway → owner account creation → real provider key added → live completion request served and logged, with zero CLI commands required and full support for both local (npm run dev) and Vercel-hosted dashboards. Open-sourced under the MIT license.

Challenges

  • Supabase's Management API blocks direct browser calls (CORS), so deploying a gateway from a one-click browser button required routing that call through a local dev-server proxy and an equivalent serverless function — both calling the same underlying logic.
  • The function-deployment endpoint required genuine multipart/form-data with correctly auto-generated boundaries, not JSON — an initial JSON-based implementation failed with "invalid multipart boundary" until this was corrected.
  • Supabase Auth rejected the synthetic email domain initially used for auto-created owner accounts as invalid; switching to the RFC 2606 reserved placeholder domain example.com resolved it in a way that's safe for any self-hoster, not tied to a specific individual.
  • A Postgres table can have a correct row-level security policy while still blocking every read, if the matching table-level GRANT is missing — RLS policies and grants are two separate requirements, and this project hit that exact bug before fixing it project-wide.

Architecture

Keyroute runs as a Supabase Edge Function (Deno runtime) deployed directly inside the user's own Supabase project — not on any third-party server. A React/Vite dashboard acts purely as a control panel for managing keys and viewing usage; it never sits in the path of an actual AI request. Provider keys are encrypted at rest via Supabase Vault (AES-256), decrypted only inside a security-definer database function, and never read back in plaintext by the application layer. Requests are routed using a label/model prefix (e.g. openai-work/gpt-4o), resolved to the correct provider and decrypted key, then forwarded directly to that provider with the response streamed straight back.

Self-hosting is a single browser button: pasting a Supabase personal access token triggers automatic database migrations, gateway function deployment, and silent owner-account provisioning — no CLI commands required. The dashboard itself can run locally via Vite or be deployed to a user's own Vercel account; either way, the gateway keeps running permanently on Supabase.