Deploy and Host InsForge on Railway

InsForge is the all-in-one, open-source backend platform for agentic coding. It gives a coding agent a database, auth, storage, edge functions, hosting and an AI gateway, and exposes all of it through an MCP server so the agent can operate the backend the way a backend engineer would.

This template deploys the full self-hosted stack. Nothing in it calls back to a managed InsForge service.

About Hosting InsForge

InsForge is four services, not one: the backend and dashboard, a Postgres database carrying the extensions its row-level security depends on, PostgREST generating a REST API from your schema, and a Deno runtime executing edge functions. They talk to each other over the private network; only the backend gets a public domain.

Postgres and the function runtime are built from the InsForge repository at deploy time rather than pulled as prebuilt images, so their configuration and function host always match the release rather than drifting behind it.

Self-hosting it means running those four services, keeping their credentials in step, and giving the database and the file store somewhere durable to live. This template does all of that: two volumes, private hostnames wired between the services, and every credential generated at deploy.

Why Deploy InsForge on Railway?

The stack is a set of services that have to find each other and agree on three secrets. Railway gives each service a private hostname, generates the secrets once at deploy, and lets the other services reference them, so nothing has to be copied by hand and no credential is shared with any other deployment.

Volumes keep the database and uploaded files across redeploys, and the backend's health check gates traffic until migrations have finished.

Common Use Cases

Giving a coding agent a real backend it can operate through MCP — creating tables, deploying functions, configuring auth — instead of a mock.
Self-hosting a full backend for an app whose data cannot sit on someone else's managed service.
Standing up a disposable backend per project or per branch, then deleting it.

Dependencies for InsForge Hosting

A Railway account on a paid plan. Four services and two volumes are more than the free trial covers.
Nothing else. There is no external database, cache or object store to bring — though object storage can be pointed at S3, MinIO, R2 or any S3-compatible endpoint by setting the S3_* variables on the insforge service.

Deployment Dependencies

After deploying

Open the insforge service's domain.
Sign in with ROOT_ADMIN_USERNAME and ROOT_ADMIN_PASSWORD, both variables on the insforge service. The password is generated for your deployment. Change the username to your own email address.
Follow the dashboard to connect your coding agent to the MCP server.

The first deploy takes a few minutes, and postgrest and insforge restart once or twice while Postgres initializes. That is expected.

ENCRYPTION_KEY is what stored secrets are encrypted with. Rotating it makes every secret already in the database impossible to decrypt.