Skip to main content
Your InsForge backend and its PostgREST run on InstaCloud unchanged, from the same images, as two compute services. The database becomes a managed postgres service, and the files move to a storage service. Your app keeps its keys, your users keep their sessions and their passwords, and only the baseUrl in your code changes. Your coding agent does most of it. InstaCloud offers:
  • Postgres with real branching. A branch opens as a copy-on-write clone holding all of the parent’s data, at its own connection string, so a feature or an agent task can run migrations nowhere near production.
  • Built for coding agents. A CLI and an MCP server your agent drives directly, with an approval gate on the actions that matter.
  • Flexible deployments. A local directory, a GitHub repo, or an image from any registry.
  • Managed services alongside. Postgres, Redis, MySQL, MongoDB, and object storage in one project.
  • Real support. An active community on Discord.

​
Migration steps

The worked example is an InsForge brought up with the Docker guide: deploy/setup.sh, then docker compose up -d. Its .env holds what matters:
A hosted project has no .env. The same values live in its secret store, minus ENCRYPTION_KEY, which it does not have because it runs on JWT_SECRET for both. Your agent pipes each one from @insforge/cli straight into InstaCloud, never to your terminal.

​
1. Point a coding agent at your InsForge

Work where your agent can read the project. Self-hosted, that is the directory setup.sh created, whose .env and deploy/ folder the migration reads. Hosted, any directory you link:
Then install the skill:
That installs the insta CLI, the insta skill, and the MCP server for every coding agent on this machine. The skill is what knows how an InsForge stack maps onto services here.

​
2. Create a project

Or click Create Project in the console. A new project starts empty.

​
3. Ask your agent to migrate

Files and database are two halves of one state, so nothing may write to either while they are copied. Self-hosted, stop the writers and leave Postgres running for the copy:
That stops InsForge, not your app, so stop anything else on the machine that writes through it. If InsForge runs elsewhere, bring its .env, deploy/ folder and storage-data volume here first. A hosted project cannot be stopped at all. Freeze writes in your app, keep the window short, and have your agent check your schedules first, since pg_cron keeps firing inside the database either way and a project whose schedules write application rows cannot be copied cleanly. Then hand over:
Prompt
It will ask you to approve anything that touches production, and it moves the files before the database, because the list of files lives in the database.

​
4. Switch your app over

Prompt
Change baseUrl in your createClient call to that URL. Nothing else in it changes. Leave the old InsForge stopped rather than deleted, so you can go back to it. Your app is separate from the migration. Stopping InsForge did not stop it, so stop it yourself before you cut over. Bringing it here afterwards is optional, and with a Dockerfile it is one command:

​
Edge functions

They come over. Your function code lives in the database, so it arrives with everything else, and your agent stands the Deno host up as one more compute service and points the backend at it. Ask for it in step 3, so your functions are already running when your app arrives:
Prompt

​
What does not come over

Coming from a hosted project, more stays behind, all of it what InsForge ran on your behalf. Analytics answers 501 here and keeps its history in InsForge’s own PostHog, and your usage and billing record stays with the old account. The AI gateway and the web scraper ran on InsForge’s credentials, so both need yours. And social login moves onto your own OAuth app. Google and GitHub, the two InsForge sets up by default, key identities on an id that is the same whichever app asks, so those users keep their accounts. Apple scopes that id to the developer team, so check it before you move: its users would arrive as new accounts. Your schedules are not among them: they run in pg_cron inside your database and came over with the dump.

​
Limitations

A few things are not here yet. Limitations covers the ones people hit most, and is worth the minute before you commit. Stuck anywhere? Come to Discord.