InsForge calls itself “The all-in-one, open-source backend platform for agentic coding” — a backend that a coding agent can both read and configure. Its pitch is that it provides “database, auth, storage, compute, hosting, and AI gateway to ship full-stack apps end-to-end.” Apache-2.0 licensed.
The distinguishing idea is not the feature list, which reads like any backend-as-a-service. It is the second half: the agent is a first-class client.
What “agent-native” actually means here
Two interfaces are provided: an MCP server, available self-hosted and in the cloud, which exposes operations as tools, and a CLI plus Skills, which is cloud only.
Through those, an agent can do two categories of thing:
Read state. Docs, schemas, function and bucket metadata, auth configuration and runtime logs. This is the part that matters more than it sounds. An agent writing code against a database it cannot introspect will invent column names; one that can pull the actual schema and then read the runtime logs after a failure can debug its own work.
Configure resources. Deploy edge functions, run migrations, create storage buckets, set up auth providers.
The products underneath are conventional and recognisable: authentication, Postgres, S3-compatible storage, a Model Gateway offering an OpenAI-compatible API across providers, edge functions, Compute (private preview) and site deployment. The stack is Postgres with PostgREST, Deno for edge functions, and MinIO or RustFS — or any S3-compatible store — for files.
Self-hosting it
Docker Compose v2 is required:
curl -fsSL https://raw.githubusercontent.com/InsForge/InsForge/main/deploy/setup.sh | sh -s ~/insforge
cd ~/insforge
$EDITOR .env # set API_BASE_URL and VITE_API_BASE_URL
docker compose up -dThen open http://localhost:7130 and connect the MCP server. Building from source uses docker-compose.prod.yml instead. A neat verification trick from the docs: prompt your agent to call the MCP fetch-docs tool — if that returns, the wiring is correct. Running several instances needs a distinct COMPOSE_PROJECT_NAME per directory, and distinct ports if they run concurrently.
As with any curl … | sh installer, read the script before running it on a machine you care about.
The security detail that is easy to miss
Two documented facts belong together, and they decide whether a deployment is safe:
- The MinIO and RustFS overlays “ship with default store credentials.”
- The production compose file “generates nothing,” so you must set the secrets in
.envyourself before exposing it.
In other words: nothing auto-generates your secrets, and the storage layer arrives with known defaults. A self-hosted instance that goes from docker compose up straight onto a public address is misconfigured by construction. The documentation says so clearly, which is to its credit — but it is the step most likely to be skipped in the rush to see it working.
Set your own credentials before anything is reachable from outside localhost.
Where it fits, and where it does not
The honest case for it is a developer directing an agent to build a full-stack app who is tired of the agent guessing at backend state. Giving the model schema introspection and log access closes a real feedback loop, and self-hosting keeps the data where you want it.
Two limits to note. Compute is in private preview, so plan around it rather than on it. And the CLI plus Skills interface is cloud only — self-hosters get the MCP server, which is the more important of the two, but not the full surface.
If you are evaluating it, stand up the Docker deployment with your own secrets, connect one agent via MCP, and have it introspect a schema and then read a log after a deliberate error. That exercise tells you whether the agent-native premise holds for your workflow better than any feature list will.
