InsForge: An Open Source Backend That Coding Agents Operate Through MCP or a CLI
The all-in-one, open-source backend platform for agentic coding. InsForge gives your coding agent database, auth, storage, compute, hosting, and AI gateway to ship full-stack apps end-to-end.
At a glance
- What is it?
- InsForge bundles Postgres, auth, S3-compatible storage, edge functions, a model gateway, compute and site deployment, then exposes them to coding agents through an MCP server or a CLI plus Skills. The interesting part is the agent-facing interface; the open questions are self-hosting cost and the maturity of the compute tier.
- Who is it for?
- Adopt InsForge if you want a coding agent to provision Postgres, auth, storage and edge functions without you writing a control plane, and you are comfortable running Docker Compose or using the hosted tier at insforge.dev. Do not adopt it if you need long-running container services in production today: the README labels Compute a private preview, so it is not a stable target.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 16, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem InsForge Targets: Backends That Agents Cannot See
A coding agent can write application code quickly and then stall on everything around it. It cannot create a Postgres table, add an auth provider, make a storage bucket, or read the runtime log that explains why a function failed, unless someone has given it a tool for each of those jobs. The usual answer is a stack of dashboards and a human in the loop, or a pile of provider-specific scripts the agent has to guess at. InsForge's pitch, stated in its README, is to give a coding agent "database, auth, storage, compute, hosting, and AI gateway to ship full-stack apps end-to-end." That is a wide claim, and the concrete part is narrower and more interesting: the agent gets two documented interfaces and a defined set of operations it can perform. The target user is a developer who already drives an agent from an editor or terminal and wants the backend to be something the agent configures rather than something the developer clicks through.
Two Agent Interfaces: MCP Server and CLI Plus Skills
The README describes exactly two ways an agent talks to InsForge. The first is an MCP Server, offered self-hosted and cloud, which "exposes InsForge's operations as tools any MCP-compatible agent can call." The second is a CLI paired with Skills, and the README marks it cloud only; the agent invokes the commands directly from the terminal. The distinction matters when you plan a deployment. If you self-host, the MCP path is the one the documentation names for agent access, and the CLI path is not listed as available there. Both interfaces are said to do the same two categories of work: read backend context and state, and configure primitives. The read side covers documentation, schemas, metadata such as deployed functions, bucket contents and auth config, plus runtime logs. The configure side covers deploying edge functions, running database migrations, creating storage buckets, setting up auth providers, and other resources. That pairing is the design bet: an agent that can both inspect the backend and change it can close its own loop, instead of writing code against a backend it has to imagine.
What Sits Behind the Agent: Seven Named Primitives
The architecture diagram in the README is a flat fan-out. AI coding agents connect to InsForge, and InsForge connects to seven boxes: Authentication, Database, Storage, Edge Functions, Model Gateway, Compute, and Deployment. The Core Products list gives each a one-line definition. Authentication covers user management, authentication and sessions. Database is Postgres. Storage is S3-compatible. Model Gateway is an OpenAI-compatible API across multiple LLM providers. Edge Functions are serverless code running on the edge. Site Deployment handles site build and deployment. Compute is described as long-running container services, and it carries a parenthetical that changes how you should read the whole list: private preview. The repository topics add pgvector, embeddings, vectors, realtime and websockets, which suggests vector search and realtime channels are part of the Postgres and websocket surface, though the README itself does not spell out those features. Treat the seven-box diagram as a statement of intent for Compute and a statement of scope for the rest.
Self-Hosting: One Setup Script and a Compose File
The self-hosted path assumes Docker with Compose v2. Setup is a single piped shell command: curl -fsSL https://raw.githubusercontent.com/InsForge/InsForge/main/deploy/setup.sh | sh -s ~/insforge. According to the README, that script fetches the files the stack reads and generates JWT_SECRET, ENCRYPTION_KEY, POSTGRES_PASSWORD, ROOT_ADMIN_PASSWORD and the two access keys into ~/insforge/.env with mode 600. It starts nothing. Re-running it refreshes the files and keeps values you have already set, only adding COMPOSE_FILE or repointing it at the checkout's compose file if it still names the development one. After that you edit .env, and the README names two keys you are expected to change: API_BASE_URL and VITE_API_BASE_URL, described as the URL browsers will use. Then docker compose up -d. Because .env sets COMPOSE_FILE, plain docker compose commands work from that directory without -f flags. That is a tidy arrangement, and it also means the generated secrets live in one file that you now own the rotation of.
Where InsForge Is the Wrong Tool
Compute is the clearest boundary. The README labels it private preview and defines it as long-running container services. If your workload needs a persistent worker, a queue consumer, or anything that outlives a request, you are building on a tier the project itself flags as not generally available. Edge Functions are the documented alternative, but serverless code running on the edge has a different execution model from a long-running container, and the README does not promise parity between the two. A second limitation is interface availability: the CLI plus Skills route is cloud only, so a self-hosted deployment that wants agent access is pointed at the MCP server. If your agent tooling does not speak MCP, the self-hosted story is thinner than the feature list suggests. Third, the README is a launch page, not an operations manual. It documents setup and the shape of the agent interfaces, but not backup, upgrade, or migration procedures. Anyone running this in production is reading the compose files and the source, not the README, to find out what happens on a version bump.
How InsForge Differs From Supabase
The obvious comparison is Supabase, which also puts Postgres, auth and S3-compatible storage behind one project. The difference is where the automation boundary sits. Supabase's documented surfaces are aimed at application developers: client libraries, a dashboard, and a SQL editor. InsForge's documented surfaces are aimed at the agent: an MCP server exposing operations as tools, and a CLI with Skills for terminal invocation. That is a real difference in approach, not a rebrand. It means InsForge's value depends on how well those tool definitions map to what an agent actually needs to do, and it means the failure mode is different too. When a Supabase call fails, a developer reads the error. When an InsForge tool call fails, the agent has to read it, and the README's emphasis on pulling runtime logs and metadata into the agent's context is precisely an attempt to make that possible. If you do not use a coding agent, that advantage largely disappears and you are left comparing two Postgres-backed platforms on features alone.
Licence, Versioning and the Cost of Staying Current
InsForge is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant. That is a permissive licence, and it also means there is no copyleft obligation if you fork the platform or embed it in a product. This is not legal advice; read the licence text and your own counsel's view before relying on it. On maintenance, the release cadence visible in the supplied material is three releases in roughly a month: v2.3.0 on 2026-08-07, v2.3.1 on 2026-08-12, and v2.3.2 on 2026-09-08. The last push to main is dated 2026-09-09. A patch release days after a feature release is normal for an active project, but it also means self-hosters should expect to pull images and re-read the compose files regularly. The setup script's re-run behaviour, which preserves values you have set and only adds or repoints COMPOSE_FILE, is the mechanism the project gives you for staying current without losing your secrets. Budget for that loop, and for reading release notes between minor versions, because the README does not describe a migration path for the database.
Editorial conclusion
Adopt InsForge if you want a coding agent to provision Postgres, auth, storage and edge functions without you writing a control plane, and you are comfortable running Docker Compose or using the hosted tier at insforge.dev. Do not adopt it if you need long-running container services in production today: the README labels Compute a private preview, so it is not a stable target. Verify first that the MCP server and the CLI plus Skills actually cover the operations your agent needs, because the README states the CLI path is cloud only while the MCP server is available self-hosted and cloud. Then read deploy/setup.sh before running it, since it writes six generated secrets into ~/insforge/.env.
Community notes