Every "Supabase for AI agents" pitch on Product Hunt this year has made roughly the same promise: point your coding agent at us instead of a human-facing dashboard, and it'll provision your backend without getting lost in a UI it wasn't trained on. Most of them are thin MCP wrappers around an existing BaaS. InsForge is the one that decided to rebuild the whole stack — Postgres, auth, storage, edge functions, an AI model gateway, and now a self-hosted compute layer — around the assumption that the primary "user" clicking through your infrastructure is not a person at all.
That's a genuinely different design constraint, and it shows in places that the launch copy doesn't spend much time on: the shape of its permission model, what its own GitHub issues reveal about drift between docs and reality, and what happens when your agent-provisioned backend outlives the agent that provisioned it.
What happened
InsForge had a quiet start — an alpha in March 2026 — before its public Product Hunt launch and a Y Combinator batch placement put it in front of a wider audience. Since then the project has kept a release cadence that looks more like a CI-fed SaaS than a typical open-source repo: version 2.2.9 shipped self-hosted S3 backends with bundled MinIO/RustFS overlays on July 28; 2.3.0 added scheduled database backups for self-hosters and a migration dry-run inspector on August 7; 2.3.1 landed a self-hosted Docker driver for custom containers and better observability on August 12. Three shipped releases in under three weeks is the kind of pace you usually see right after a funding round, and InsForge's YC page confirms that's exactly the phase it's in.
The repo itself is Apache 2.0, sits at roughly 12.7k GitHub stars and 1.1k forks, and is built as a TypeScript/Deno monorepo (Next.js dashboard, Deno edge runtime, Postgres with pgvector, Turbo for the build graph). None of that is exotic. What's unusual is the framing: the README doesn't describe a product for developers who "want AI features." It describes infrastructure whose primary API surface is an MCP server — an agent walks up, reads your schema, provisions a table, wires an OAuth provider, deploys an edge function, and never opens a browser.
For readers who haven't been tracking it, the Model Context Protocol (MCP) is the emerging open standard for how an LLM-based agent discovers and calls tools exposed by an external system — think of it as a typed, discoverable RPC layer that replaces "the agent reads your REST docs and guesses" with "the agent lists your tools and calls them with validated arguments." A growing number of infrastructure vendors now ship an MCP server as a bolt-on integration alongside their existing REST/GraphQL API. InsForge's bet is that treating MCP as the primary interface, with REST and the dashboard as secondary views onto the same state, changes what the product optimizes for at every layer — error messages, tool granularity, and default permissions all get designed for a caller that can't ask a clarifying question in a Slack channel.
What it actually does
Strip away the "agent-native" branding and InsForge is a Backend-as-a-Service with seven components: Postgres (with vector support baked in), authentication, S3-compatible storage, an OpenAI-compatible model gateway that lets you swap LLM providers without rewriting client code, Deno-based edge functions, a private-preview "Compute" tier for long-running containers, and static site hosting. That's the same primitive list as Supabase or Firebase — the difference InsForge is betting on is entirely in the operating surface.
Where Supabase's ergonomics are optimized for a person clicking through a dashboard (with a CLI and API as a secondary path), InsForge inverts that: the MCP server and CLI are the primary interface, and the dashboard is closer to an observability console you check after the agent has already done the work. Concretely, that means:
- Structured context instead of docs. An agent calling InsForge's MCP tools gets schema, RLS policy state, function logs, and deployment metadata back as structured data, not prose it has to parse out of a web page.
- Secrets stay server-side. According to the project's documentation, API keys and service secrets are never handed to the calling agent — the agent issues commands, InsForge executes them, and only scoped, presigned URLs or tokens come back for things like file access.
- Self-hosting is a first-class deployment target, not an afterthought. You can run the entire stack locally via Docker Compose, or one-click it onto Railway, Zeabur, or Sealos, with a choice of storage backend (MinIO, RustFS, or any S3-compatible provider).
The pitch in one line, paraphrased from InsForge's own comparison pages: Supabase and Firebase were built for humans who happen to use AI tools; InsForge was built for AI tools that happen to need a human to sanity-check them occasionally.
How it works: the MCP-first architecture
The interesting engineering decision isn't the database — it's what sits in front of it. InsForge exposes two parallel interfaces onto the same backend: a Remote MCP Server (OAuth 2.0 with PKCE, dynamic client registration, token-scoped per-project access) for hosted/cloud use, and a local MCP server plus CLI/Skills bundle for agents working against a self-hosted instance. Either way, the agent's action surface is a fixed set of tools — create table, run migration, deploy function, configure auth provider, attach storage bucket — rather than free-form SQL or shell access to the host.
That constraint is the actual security model. It's a narrower blast radius than "give the agent a Postgres connection string and a service-role key," which is still how a lot of AI-assisted Supabase workflows operate today. Access control is enforced with row-level security (RLS) policies at the database layer, same as Supabase, and InsForge's own materials acknowledge that this is the exact spot where agents historically produce "confident, plausible, wrong" policies — over-permissive rules that pass a smoke test and fail an audit. Putting the provisioning behind typed MCP tools instead of raw SQL reduces the surface area for that failure mode, but doesn't eliminate it; a wrong insert-policy call through the MCP tool is still a wrong policy.
The edge function runtime is Deno, chosen presumably for its sandboxing and TypeScript-native execution model, and it's already shown the downside of depending on someone else's edge platform: issue #1947 in the repo tracks edge function failures after "Deno Deploy Classic" was sunset, with redeployment blocked as a result. That's not an InsForge bug in the traditional sense — it's a reminder that "agent-native infrastructure" still inherits every dependency-chain risk that ordinary infrastructure has, and an agent isn't going to notice an upstream platform sunset notice on your behalf.
What changed versus the incumbents
Supabase, Firebase, Neon, and PocketBase all now have MCP servers or AI-agent integrations bolted on — that part of the landscape moved fast in 2025–2026. What InsForge changed is the direction of the design: instead of adding an MCP adapter to a dashboard-first product, it built the product with the MCP surface as the default control plane and the dashboard as the fallback. In practice that shows up as:
- Fewer manual steps per provisioning task. Independent comparison write-ups covering InsForge against Supabase report that an agent can create tables, configure OAuth, set up storage, and deploy a working app through the CLI/MCP path without touching an admin UI — the human-facing dashboard becomes optional rather than the primary workflow.
- A model gateway as a first-party primitive. Bundling an OpenAI-compatible multi-provider LLM gateway directly into the backend (rather than requiring a separate service like OpenRouter) is not something Supabase or Firebase ship out of the box.
- Self-hosting parity with the hosted product. The self-hosted Docker Compose path gets the same backups, S3 backend options, and observability tooling as the cloud tier — a deliberate choice, since an agent that provisions against a self-hosted instance during development and later needs to migrate to production benefits from those environments looking identical.
What didn't change: the fundamental trust question. Whether the operator holding the keys to your database is a person or an autonomous agent, you're still betting on the operator's judgment. InsForge narrows the interface an agent can misuse; it doesn't remove the agent from the loop, and it can't promise the agent won't misuse the narrower interface anyway.
Why developers should actually care
Cost. The free tier — 50,000 monthly active users, 500 MB database, 5 GB bandwidth, 1 GB file storage — is generous for a side project or an agent-driven prototype you're not sure will survive contact with real users. Paid tiers start around $25/month for 100,000 MAUs and 8 GB of database, per pricing InsForge publishes; self-hosting removes the MAU/storage ceiling entirely at the cost of running your own Postgres and Deno runtime. If you're already paying for compute to run agent workloads, self-hosting the backend next to them isn't a large incremental cost.
Latency and DX. The claimed advantage — fewer round-trips because the agent isn't screen-scraping a dashboard or guessing at REST semantics — is plausible given the architecture, though I haven't seen a controlled benchmark against, say, a well-configured Supabase MCP integration. What is verifiable is the release velocity: three feature-shipping releases in the two and a half weeks before this piece, which for a project at this stage says more about DX trajectory than any single benchmark would.
Lock-in. This is where InsForge is genuinely stronger than most "AI-native" launches: Apache 2.0 license, Postgres underneath (not a proprietary datastore), S3-compatible storage with a choice of backend, and a documented self-hosting path with deployment parity. If InsForge the company disappears, the software doesn't — that's a meaningfully different risk profile than betting on a closed hosted-only platform.
Security. This is the part the launch page glosses over and the part technical readers should sit with longest. Handing an autonomous agent the ability to provision auth providers, write RLS policies, and deploy edge functions is a larger blast radius than handing it a linter to run. InsForge's mitigations — secrets never exposed to the agent, presigned URLs, OAuth-scoped MCP tokens — are the right categories of defense. But issue #1925 in the project's own tracker, at the time of writing, flags that InsForge's documentation was still teaching a pattern that produces world-readable database dumps. That's not a smoking gun — it's exactly the kind of thing that gets caught and fixed in a fast-moving open-source project — but it's a concrete illustration of the general risk: security guidance drifts out of sync with a codebase shipping three releases a month, and an agent following stale docs won't know the difference.
Maintainability. Issue #1918 reports documentation-parity violations across 48 items relative to the main branch. For a human-operated backend, doc drift is an annoyance. For an agent-operated one, it's closer to a correctness bug: the agent's mental model of the system comes largely from the docs and the MCP tool schemas, and if those two things disagree with what the code actually does, the agent will confidently do the wrong thing with the same fluency it does the right thing.
Practical use cases
- Prototyping with an agent driving the whole stack. "Build me a full-stack app with auth and a Postgres-backed API" is the workflow InsForge is explicitly optimized for — Cursor, Claude Code, or any MCP-compatible agent can go from an empty project to a deployed backend without a human touching the dashboard.
- Teams standardizing agent-driven backend provisioning across many small internal tools. The self-hosted path with deployment parity matters here — you can let agents provision against a shared self-hosted InsForge instance for internal tools without paying per-project hosted fees.
- Multi-provider LLM apps that don't want a separate gateway service. The built-in OpenAI-compatible model gateway removes one moving part compared to wiring OpenRouter or a custom proxy alongside a separate BaaS.
- Projects that want a credible exit from vendor lock-in from day one. Because self-hosting isn't a downgrade path, teams anxious about depending on a very young, VC-backed infra company have a real mitigation available, not just a promise.
-
Agent-memory-backed applications. With
pgvectorbuilt into the default Postgres instance and a memory API surfaced through the same MCP tools, apps that need semantic recall (support bots, coding assistants with project memory, retrieval-augmented internal tools) get the vector store and the relational store from one provisioning step instead of stitching a separate vector database into the stack. - Evaluating "how far can an agent get unsupervised" as an engineering exercise. Because the entire provisioning surface is scriptable through the CLI and MCP tools, InsForge is a reasonable sandbox for teams specifically trying to measure how much of a backend build an agent can complete correctly without a human reviewing each step — useful data whether or not you end up adopting the platform itself.
Limitations the launch page doesn't dwell on
- "Compute" — long-running containers — is still private preview. If your use case needs more than edge functions (a background worker, a queue consumer, a stateful service), the feature that would cover it isn't generally available yet. That's a real gap for anything beyond request/response workloads — a cron-style job, a WebSocket server, or a queue consumer doesn't fit cleanly into "edge function," and until Compute graduates, teams with that shape of workload either bolt on a separate service or wait.
- Documentation lags the code. The 48-item parity gap and the stale security guidance aren't unusual for a fast-shipping open-source project, but they matter more here than in a typical repo, because the docs double as the agent's operating manual.
- RLS policy correctness is still an unsolved, not a solved, problem. InsForge narrows how an agent talks to the database; it does not verify that the policies an agent writes are the policies you actually wanted.
- Young company, aggressive pace. Three releases in under three weeks is great for momentum and mildly concerning for stability — API surfaces this fresh out of a YC batch tend to move, and "agent-native" projects racing against a wave of competitors sometimes ship deprecating changes to internal APIs faster than mature platforms would.
- Ecosystem size. Supabase's community, template library, and integration surface are an order of magnitude larger. If your agent (or you, debugging its output) needs a Stack Overflow answer at 2 a.m., InsForge's smaller community is a real, if narrowing, gap.
Competitive comparison
Against Supabase: same Postgres foundation, similar primitive list, but Supabase is optimized for a human in a dashboard with an MCP integration layered on, while InsForge is optimized the other way around. Supabase wins on ecosystem maturity and community size; InsForge's argument is a narrower, more agent-legible operating surface and a first-party model gateway.
Against Firebase: not a close comparison technically — Firebase is NoSQL and Google-managed with no meaningful self-hosting story, InsForge is Postgres and self-hostable under a permissive license. The comparison matters mainly for teams currently on Firebase who want SQL and portability without giving up managed hosting as an option.
Against PocketBase: PocketBase remains the leaner, single-binary, genuinely zero-limit self-hosted option if you don't need agent-specific tooling — it's arguably still the better default for a solo developer who wants boring, well-understood infrastructure. InsForge adds the MCP surface, the model gateway, and managed cloud hosting PocketBase doesn't offer, at the cost of more moving parts.
Against generic MCP wrappers around existing BaaS providers: this is the comparison InsForge should be most worried about long-term. If Supabase's own MCP integration closes the ergonomics gap, InsForge's differentiation shrinks to "purpose-built from scratch" versus "bolted on," and that's a much harder sell once both are mature.
An independent read
InsForge is solving a real problem — the mismatch between BaaS dashboards designed for human attention and agents that need structured, typed, low-ambiguity interfaces — and it's solving it with sound engineering choices: MCP-native tools instead of raw credentials, RLS for enforcement, self-hosting with real parity instead of as a marketing checkbox, and a license that doesn't leave adopters stranded if the company falters. The velocity is real and the architecture is coherent.
What tempers the enthusiasm is exactly what you'd expect from a project this young moving this fast: the documentation that agents depend on for correct behavior is measurably behind the code, and at least one tracked issue shows that gap producing actively bad security advice, not just missing docs. That's not disqualifying — it's a signal to treat InsForge as infrastructure you monitor closely for the next few months, not infrastructure you hand off to an agent and stop watching. The "agent-native" framing raises the stakes on documentation accuracy in a way that human-operated platforms don't face as acutely, and it's fair to hold InsForge to that higher bar precisely because that's the bar it set for itself.
Who should try it, adopt it, wait, or ignore it
Try it if you're already running agent-driven prototyping workflows (Claude Code, Cursor, or similar against a fresh project) and are tired of your agent fumbling through a Supabase dashboard or writing brittle raw-SQL migrations. The free tier and Docker Compose path make evaluation cheap.
Adopt it for internal tools and side projects where you value the self-hosting story and Postgres foundation, and where the "Compute" preview gap doesn't block you — i.e., edge functions and scheduled jobs cover your needs.
Wait if you need long-running stateful compute today, or if you're risk-averse about API stability and want to see a few more months of release notes before building production workloads on top.
Ignore it if your team is already deep into Supabase or Firebase with a working AI-integration story, or if "agent provisions my backend" isn't a workflow you actually want — InsForge's whole value proposition assumes you're comfortable with that premise, and if you're not, none of its architectural advantages will matter to you.
What's your actual tolerance for letting an agent write RLS policies unsupervised — do you review every policy an agent generates before it ships, or has your team already crossed the line into trusting the agent's output the way you'd trust a senior engineer's PR?
Sources:
Top comments (0)