Daniel Kim

Posted on Aug 19

InsForge Teaches AI Agents to Run Your Backend. It Hasn't Learned to Keep Postgres Alive Yet.

#backend #postgres #ai #opensource

Every backend-as-a-service platform since Firebase has been designed around the same assumption: a human opens a dashboard, clicks through a schema editor, copies an API key, and wires it into an app. Supabase modernized that flow with a nicer UI and a Postgres core, but it kept the human in the loop as the operator.

InsForge, which shipped its 2.0 release on Product Hunt this month, throws that assumption out. Its dashboard is an afterthought. The primary user it's designed for is a coding agent — Claude Code, Cursor, or anything that speaks MCP — reading your backend's schema, deploying your edge functions, and running your migrations without you touching a UI at all. The company is part of Y Combinator's Spring 2026 batch, raised $1.5M in pre-seed funding, and its GitHub repo has been climbing fast enough that different write-ups from the past few weeks cite wildly different star counts — anywhere from roughly 2,000 to north of 10,000, depending on the day you looked.

That's the headline. The more interesting story is what an independent Postgres operator found when they actually opened the hood: a genuinely clever agent-facing API layer sitting on top of a database that, by the maintainer's own repo structure, is still a single Docker container with no failover, no monitoring, and no automated backup. InsForge solved the "AI agent talking to your backend" problem convincingly. It has not yet solved the "your backend stays up" problem, and that gap is worth understanding before you point an autonomous agent at it.

This isn't a niche curiosity, either. It's a direct response to a problem the "vibe coding" wave surfaced and never really solved: agents are extremely good at writing frontend code and increasingly good at writing backend logic, but the actual infrastructure underneath — the database schema, the auth config, the storage bucket policies — has stayed a human-mediated bottleneck. You'd watch an agent write a beautiful migration file and then... you'd be the one who had to open a dashboard, paste it into a SQL editor, and run it. InsForge's bet is that this handoff step is unnecessary friction, and that removing it is worth rebuilding the backend stack around.

What InsForge actually is

InsForge is an open-source (Apache-2.0), self-hostable backend platform that bundles the pieces most apps need — authentication, a relational database, file storage, serverless functions, an LLM gateway, and site deployment — and exposes all of it through interfaces built for agents rather than humans:

Database: a standard Postgres instance, accessed through PostgREST for auto-generated REST endpoints.
Authentication: user management, sessions, and auth providers.
Storage: an S3-compatible object store (bundled MinIO or RustFS by default, or bring your own — AWS S3, Wasabi, Cloudflare R2, Tencent COS, Aliyun OSS).
Edge Functions: serverless functions running on Deno.
Model Gateway: an OpenAI-compatible API that fans out to multiple LLM providers.
Compute (private preview): longer-running container services.
Site Deployment: build and deploy static/SSR frontends alongside the backend.

None of these primitives are novel — this is the same feature list Supabase, Appwrite, and Firebase have shipped for years. What's different is who's meant to operate them. The GitHub description puts it plainly: it's a platform that "gives your coding agent database, auth, storage, compute, hosting, and AI gateway to ship full-stack apps end-to-end." Not "gives you" — gives your agent. That's a small wording choice with a large architectural consequence: every design decision downstream of it, from how errors are formatted to what the setup script auto-generates, optimizes for an agent's ability to parse and act on it, not a human's ability to read it comfortably in a dashboard.

How it works

InsForge runs as five Docker containers via Docker Compose — a Postgres database, PostgREST, the InsForge application server, an auth service, and a Deno runtime for edge functions — spun up with a single setup script that generates a JWT secret, an encryption key, database credentials, and API keys into a local .env file. You can also deploy it with one click on Railway, Zeabur, or Sealos, or skip self-hosting entirely and use the managed cloud at insforge.dev.

The part that matters is the interface layer on top of those containers. Agents talk to InsForge through one of two paths:

An MCP Server (available both self-hosted and on the managed cloud) that exposes every backend operation — deploy a function, run a migration, create a storage bucket, configure an auth provider, pull runtime logs — as a tool call any MCP-compatible agent can invoke.
A CLI paired with Skills (cloud-only) that an agent can invoke directly from a terminal instead of going through MCP.

Both paths give the agent two categories of capability the README is explicit about: it can read backend context — documentation, live schema, metadata about deployed functions and bucket contents, and runtime logs — so it has grounding before it writes code and can verify what it built after. And it can configure primitives directly: deploying functions, running migrations, provisioning auth, without a human relaying instructions through a dashboard. The verification step in the screenshot above — "call InsForge MCP's fetch-docs tool to learn about InsForge instructions" — is the whole philosophy in one line: the agent is expected to look up how the platform works itself, the same way a new backend engineer would read the internal wiki before touching production.

The repo's own architecture diagram frames it as a single fan-out: AI coding agents talk to one thing — InsForge — and InsForge fans that out into the seven subsystems (auth, database, storage, edge functions, model gateway, compute, deployment). The point of that shape is that the agent never has to know it's coordinating seven different services with seven different APIs and seven different failure modes; it knows one MCP surface, and InsForge is responsible for translating a single "deploy this function and wire it to this table" instruction into the right calls against Deno, PostgREST, and Postgres underneath.

Getting it running is refreshingly boring for something this ambitious. A setup script pulls the compose files and generates secrets into a local .env; docker compose up -d brings up the five containers; you open localhost:7130, connect an MCP client (Cursor, in the screenshot above), and send a one-line prompt telling the agent to go read the docs. Running multiple isolated projects is just multiple directories with distinct COMPOSE_PROJECT_NAME values and non-colliding ports — no orchestration layer required. Storage defaults to the local filesystem, but swapping in bundled MinIO or an Apache-2.0-licensed alternative called RustFS is a one-line compose overlay away, and bringing your own S3-compatible bucket (AWS, Cloudflare R2, Wasabi, Tencent COS, Aliyun OSS) is a handful of environment variables. None of this is exotic system design — it's competent, unglamorous Docker Compose engineering, which is exactly what you'd want underneath something an agent is going to be poking at unsupervised.

What changed versus the Supabase model

Supabase's MCP server exists too — you can already point Claude Code or Cursor at a Supabase project through MCP. The difference InsForge is betting on isn't availability of an agent interface, it's what that interface was designed for. Supabase's surfaces (SQL editor, migration files, dashboard-driven config) were built for a human first and retrofitted with an agent-accessible layer second. InsForge inverts the build order: the semantic layer, the fetch-docs tool, and the structured tool responses are the primary product, and the dashboard is a secondary convenience.

InsForge's own benchmark, MCPMark, tries to put a number on that difference. Running 21 real-world backend tasks, the company reports InsForge completing them roughly 1.6x faster than Supabase's MCP server, using about 30% fewer tokens, with a 47.6% task-pass rate versus 28.6% for Supabase. A more recent v2 run against Claude Sonnet 4.6 reportedly widened that further — 28% higher accuracy while using 2.4x fewer tokens. Take those numbers for what they are: a vendor measuring itself against a competitor using its own benchmark suite, not a neutral third-party eval. The direction of the result (a platform purpose-built for agent tool-calling outperforms one that wasn't) is plausible on its face; the magnitude deserves the standard skepticism any self-reported benchmark earns.

It's worth sitting with why that direction is plausible, though, rather than just discounting the whole thing as marketing math. When an agent hits Supabase through its MCP server today, it's usually navigating APIs and error formats designed for a human debugging in a browser — verbose Postgres error strings, dashboard-oriented pagination, config surfaces that assume a person reading a settings page. Every one of those design choices costs an agent extra reasoning tokens to parse and extra turns to recover from when something goes wrong. InsForge's tool responses and its fetch-docs entry point are shaped for exactly the failure mode agents hit most: not knowing what's already there. Whether that's worth a full 1.6x in a controlled, vendor-run benchmark is a separate question from whether the underlying mechanism is real — it plausibly is.

Why this should matter to developers

Cost: self-hosting is free and Apache-2.0 licensed — genuinely open source, not open-core with the useful parts gated. The managed cloud has a free tier with unspecified limits and paid tiers the team hasn't published in detail yet, which makes it hard to budget against today if you're evaluating the hosted option for anything beyond a prototype.

DX: the actual pitch is fewer round trips. Instead of an agent guessing at your schema, hallucinating a column that doesn't exist, or asking you to paste error output back into the chat, it can query the live schema and pull structured logs itself. If you've watched a coding agent burn a turn re-deriving context it already had access to a minute ago, this is a direct answer to that specific waste.

Lock-in: low, on paper — Apache-2.0, self-hostable, standard Postgres underneath. You're not locked into a proprietary query language the way you are with Convex's document model.

Security: the setup script auto-generates JWT secrets and encryption keys per instance rather than shipping default credentials, which is the right default. But the bigger security question isn't credential hygiene, it's blast radius — an agent with standing MCP access to deploy functions and run migrations is a new kind of privileged actor in your stack, and InsForge's docs don't yet say much about scoping that access down (per-project keys exist, but fine-grained permissions within a project are thin).

Maintainability: this is where the story gets less flattering, and it's covered in detail below.

Put those together and the value proposition is narrower than "AI-native backend" makes it sound. It's not that InsForge does something Postgres and PostgREST couldn't already do — it's that it removes a specific, recurring tax: the seconds-to-minutes an agent spends re-establishing context about a backend it configured five minutes ago in a previous turn, multiplied across every session, every schema change, every deploy. If your workflow already has an agent iterating on a backend dozens of times a day, that tax adds up. If a human is going to open a dashboard and review every migration before it ships anyway, most of InsForge's differentiation disappears and you're left comparing it to Supabase on ordinary BaaS terms — where Supabase's five-year head start on tooling and community still counts for a lot.

Practical use cases

Agent-driven prototyping: you're vibe-coding an MVP with Claude Code or Cursor and don't want to hand-configure Postgres, auth, and storage before the agent can even start building features.
Hackathons and internal tools: fast, disposable backends where "an agent can spin this up and tear it down without me babysitting it" is the actual requirement, not a nice-to-have.
Per-branch ephemeral backends: since setup is scriptable and instances are cheap to spin up with distinct ports and project names, it's plausible to give an agent a fresh backend per feature branch or PR and have it self-provision what it needs.
Teams without a dedicated backend engineer: the semantic layer is explicitly trying to let a frontend-leaning team let their coding agent handle backend configuration that would otherwise require someone who knows Postgres migrations and auth flows.
Multi-tenant demo environments: because whole instances are cheap to declare and isolate by directory and port range, it's a reasonable fit for spinning up an isolated backend per customer demo or per sales-eval sandbox, then tearing it down without leaving orphaned config in a shared project.
Agent evaluation harnesses: if you're building or testing your own coding agent and need a realistic, disposable backend target for it to operate against — closer to a real Postgres-backed app than a mocked API — a fresh InsForge instance is a cheaper target to stand up than a full Supabase project per test run.

What it's a weaker fit for is anything where "the agent configured it and it looked right" isn't a sufficient bar — which, per the AI-generated-code security research this year, is a real and common failure mode. A 2026 grey-literature review of vibe coding practice found that developers using AI-first workflows frequently skip testing, accept model output without modification, and delegate verification back to the same tools that generated the code in the first place. InsForge's MCP layer makes an agent's backend changes easier to make; it doesn't, by itself, make them easier to review. That's still a human's job, and nothing about "the agent read the docs first" changes that.

What the launch page doesn't tell you

The most substantive independent look at InsForge so far comes from Vonng, the maintainer of Pigsty, an open-source "batteries-included" Postgres distribution used for production RDS-alternative deployments. Vonng's read, after going through the InsForge stack directly: it's a thin, well-designed agent-oriented operating layer sitting on top of an ordinary Postgres instance — and that Postgres instance is exactly where the platform is weakest.

Specifically: the bundled database is a single-node Docker container with no high availability, no monitoring, and no automated backup configured out of the box. By contrast, Vonng's own Pigsty bundles Patroni for HA failover, VictoriaMetrics for monitoring, pgBackRest for automated backups, and connection pooling and load balancing — the operational scaffolding a production Postgres deployment actually needs and that InsForge's Docker Compose setup doesn't include. Documentation on self-hosted HA, backup, and hardening is, in Vonng's words, still thin. And the bundled Postgres version lags the ecosystem — InsForge ships PG15 while Pigsty has already moved to PG18.

None of this means InsForge is broken. It means InsForge solved a different problem than "run a production database," and the launch materials don't draw that line clearly. The interesting coda: Vonng liked the agent-facing layer enough to fold InsForge into Pigsty's own toolbox — pairing InsForge's MCP interface with Pigsty's actual database operations story is a reasonable way to get both halves right, but it's not what you get by default from InsForge alone.

Two more gaps worth flagging: Compute is still marked private preview in the README, so the "long-running container services" piece of the pitch isn't generally available yet. And the "maturity of the semantic layer" — how well the agent-facing abstractions hold up outside the happy path InsForge's own docs walk through — is still an open question with a project this young; a handful of independent write-ups note the vision is compelling without yet claiming it's been stress-tested at scale.

It's also worth noting what Vonng's critique implies about the managed cloud offering versus the self-hosted one, even though the public docs don't spell it out directly: a hosted platform has every incentive to run its own production Postgres behind something more resilient than a bare Docker container — connection pooling, replicas, real backups — even if the open-source repo you'd clone doesn't ship that by default. If that's true, the gap Vonng identified may be specifically a self-hosting gap rather than a platform-wide one. But that's an inference, not a confirmed fact; InsForge hasn't published details on what infrastructure sits behind the managed tier, and until they do, treating the self-hosted repo's architecture as representative of what you'd get on insforge.dev is the more conservative — and currently the only verifiable — assumption.

How it stacks up

Platform	Primary operator	Data model	Self-host story	Where it's strong
InsForge	AI agent (MCP/CLI-first)	Postgres + PostgREST	Docker Compose, 5 containers, no HA out of the box	Agent tool-calling, schema/log introspection
Supabase	Human (dashboard-first, agent bolted on)	Postgres + PostgREST	Mature, widely deployed	Ecosystem maturity, ops tooling, community
Convex	Human, TypeScript-function-first	Custom reactive document store	Cloud-only for the reactive engine	Real-time reactivity, no SQL to manage
Firebase	Human, mobile-first	Firestore (NoSQL)	Not self-hostable	Mobile SDKs, Google ecosystem
Appwrite	Human, BaaS-first	Multiple (SQL options available)	Docker Compose, more mature ops story	Self-host flexibility
PocketBase	Human, single-binary simplicity	SQLite	Single Go binary	Personal projects, low-ops prototypes

The honest summary: InsForge is the only platform in this table built agent-first from day one, and it's the least operationally mature of the group. That's not a contradiction — it's a young project that chose to solve the interface problem before the ops problem, which is a defensible sequencing decision for a two-month-old 2.0 release, but it does mean "agent-native" and "production-ready" are currently two different claims about this product.

A few of these comparisons deserve unpacking rather than a table cell. Convex is the most architecturally distinct alternative here — it's not a Postgres-with-extras play at all, it's a reactive document database where you write server-side TypeScript functions and clients get live updates automatically, no polling or webhooks required. That buys real-time UX for free, but it means Convex and InsForge aren't really substitutes for each other; you'd pick Convex because you want the reactivity model, and you'd pick InsForge (or Supabase) because you want SQL and relational guarantees. Appwrite sits closer to InsForge on the self-hosting axis — Docker Compose, open source, willing to give you infrastructure ownership — but Appwrite's agent story is still the retrofitted kind: solid product for a human operator, MCP support layered on afterward rather than designed in from the start. PocketBase is the odd one out precisely because it doesn't compete on this axis at all; a single Go binary with SQLite underneath is a different tool for a different job (personal projects, prototypes, anything that doesn't need to survive a second server), and comparing it to InsForge is really comparing two different definitions of "simple."

Who should actually use this

Try it now if you're prototyping with an AI coding agent as your primary development interface, running hackathon or internal-tool projects where downtime is an annoyance rather than an incident, or you're curious what backend development looks like when the agent — not you — is expected to read the docs first.

Wait if you need a production database with real failover and backup guarantees today. Either self-host InsForge behind something like Pigsty for the Postgres operations layer, run it on the managed cloud and get concrete answers from the InsForge team about what HA/backup story the hosted tier actually provides (the public docs don't spell this out yet), or stick with Supabase's more battle-tested ops tooling until InsForge's does.

Ignore it if your team isn't using AI coding agents as the primary way code and infrastructure get written — the entire value proposition is agent-first operation, and a human clicking through the dashboard gets a worse experience here than on Supabase or Appwrite, which were built for that workflow from the start.

Product Hunt is full of "AI-native" rebrands of existing categories that don't actually change the underlying mechanics. InsForge is a rarer thing: a platform that changes who the primary user is and rebuilds the interface around that change consistently. Whether that's enough to matter depends entirely on whether you trust an agent to be the one reading your database logs at 3 AM — and right now, per the most careful independent look at it, that's still a single Docker container's job.

If your CI pipeline let an agent provision and tear down a full Postgres-backed backend on every pull request, what's your actual blast radius the first time its semantic layer misreads a migration — and who's actually on call for that?

Sources:

DEV Community