Overview
InsForge is an open-source backend platform built for coding agents rather than for humans clicking through a dashboard. It bundles the pieces an app normally needs — a Postgres database, user authentication and sessions, S3-compatible file storage, serverless edge functions, container compute and site deployment — behind one self-hosted Docker Compose stack, plus a Model Gateway that exposes an OpenAI-compatible API across several LLM providers.
Agents reach the platform through one of two interfaces. The MCP server, available self-hosted and in the cloud, exposes InsForge's operations as tools any MCP-compatible agent can call. The cloud service also ships a CLI paired with Skills that agents invoke from the terminal. Either way the agent can read backend context — documentation, schemas, deployed-function metadata, bucket contents, auth configuration and runtime logs — and then configure the primitives directly: run database migrations, deploy edge functions, create buckets, wire up auth providers.
That read-then-configure loop is the point. Because the agent can inspect what it built and read the logs when something breaks, it can debug its own backend instead of handing the developer a stack trace. The project is Apache-2.0 and runs entirely on your own machine if you want it to; a hosted tier at insforge.dev covers the CLI, Skills and the private-preview Compute service.
What it does
- Postgres database with agent-run migrations, plus S3-compatible storage and an optional S3 gateway at /storage/v1/s3
- Built-in authentication: user management, sessions and pluggable auth providers
- Edge Functions for serverless code, Compute (private preview) for long-running container services, and site build + deployment
- Model Gateway — one OpenAI-compatible API across multiple LLM providers
- MCP server (self-hosted and cloud) exposing every backend operation as an agent tool, plus a cloud CLI with Skills
- Agent-readable context: docs, schemas, resource metadata and runtime logs, so the agent can verify and debug what it deployed
- Multi-project self-hosting — one directory and one COMPOSE_PROJECT_NAME per instance, each with its own containers, volumes and secrets
Getting started
The fastest path is the hosted service at insforge.dev. To self-host you need Docker with Compose v2; the commands below are the README's quickstart.
Generate the stack files and secrets
The setup script fetches what the stack reads and writes JWT_SECRET, ENCRYPTION_KEY, POSTGRES_PASSWORD, ROOT_ADMIN_PASSWORD and the two access keys into a mode-600 .env. It starts nothing.
curl -fsSL https://raw.githubusercontent.com/InsForge/InsForge/main/deploy/setup.sh | sh -s ~/insforgeSet the browser-facing URLs and bring it up
Edit API_BASE_URL and VITE_API_BASE_URL — these are the URLs browsers will use. The generated .env sets COMPOSE_FILE, so plain docker compose commands work from that directory.
cd ~/insforge
$EDITOR .env
docker compose up -dConnect your agent to the InsForge MCP server
Open the dashboard at http://localhost:7130 and follow the steps it shows to register the MCP server with your coding agent.
open http://localhost:7130Verify the connection from the agent
Send this prompt to the agent; a working MCP connection returns the InsForge instructions.
I'm using InsForge as my backend platform, call InsForge MCP's fetch-docs tool to learn about InsForge instructions.Run a second project without a port clash
Give each project its own directory, COMPOSE_PROJECT_NAME and ports — two directories sharing a project name share containers.
curl -fsSL https://raw.githubusercontent.com/InsForge/InsForge/main/deploy/setup.sh | sh -s ~/project2
# in ~/project2/.env:
# COMPOSE_PROJECT_NAME=project2
# POSTGRES_PORT=5442
# APP_PORT=7230
cd ~/project2 && docker compose up -dCommands and code are distilled from the project's own documentation — always check the official repo for the latest.
When to use it
- Give a coding agent a real backend to ship against instead of mocking auth, storage and a database
- Self-host the whole stack — database, auth, storage, functions and the model gateway — on one machine you control
- Let the agent read runtime logs and schemas so it can debug the backend it just deployed
- Run several isolated app backends side by side, one Compose project per app
How InsForge compares
InsForge alongside other open-source ai sdlc automation tools AI/TLDR tracks, ranked by GitHub stars.
| Tool | Stars | What it does |
|---|---|---|
| Multica | ★ 50.4k | Self-hostable workspace where coding agents are assigned issues like teammates: 26 agent CLIs, runtimes you own, a replayable execution log per run, and review gates before anything ships. |
| GPT-Pilot | ★ 33.7k | Autonomous AI developer that breaks down an app description into tasks, writes and runs code incrementally, and asks clarifying questions to produce a working production application. |
| oh-my-codex (OMX) | ★ 33.2k | A workflow layer for the OpenAI Codex CLI that adds agent teams, git-worktree isolation, hooks and HUDs behind a set of canonical plan, code-review and QA commands. |
| Vibe Kanban | ★ 28.1k | Vibe Kanban lets you plan tasks on a kanban board, run coding agents like Claude Code and Codex in isolated workspaces, then review their diffs and ship pull requests. |
| Beads | ★ 27.3k | A Dolt-backed dependency-graph issue tracker for coding agents: hash IDs avoid multi-agent collisions, `bd ready` surfaces unblocked work, and `bd remember` keeps durable project memory. |
| Archon | ★ 23.5k | A workflow engine for AI coding agents: describe plan, implement, validate, review and PR phases as YAML, and every run repeats them in its own git worktree. |
| Keploy | ★ 18.5k | An API testing tool that records real traffic with eBPF — including database and queue calls — and replays it as deterministic tests and data mocks, with no SDK to import and no code changes. |
| InsForge | ★ 13k | An all-in-one backend — Postgres, auth, storage, edge functions and a model gateway — that a coding agent operates over MCP |