> ## Documentation Index
> Fetch the complete documentation index at: https://docs.instacloud.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Migrate from InsForge

> Move an InsForge project, its database, users and files, onto InstaCloud.

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](https://discord.com/invite/MPxwj5xVvW).

## Migration steps

The worked example is an InsForge brought up with the [Docker guide](https://github.com/InsForge/InsForge/blob/main/deploy/docker-deploy.md): `deploy/setup.sh`, then `docker compose up -d`. Its `.env` holds what matters:

```ini theme={null}
JWT_SECRET=...
ENCRYPTION_KEY=...
ACCESS_API_KEY=ik_...
ACCESS_ANON_KEY=anon_...
POSTGRES_DB=insforge
```

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:

```bash theme={null}
cd ~/insforge                  # self-hosted

npx -y @insforge/cli login     # hosted
npx -y @insforge/cli link
```

Then install the skill:

```bash theme={null}
npx -y insta@latest agent setup
```

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

```bash theme={null}
insta project create insforge
```

Or click **Create Project** in the [console](https://console.instacloud.com). 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:

```bash theme={null}
docker compose stop insforge postgrest deno
```

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:

```text title="Prompt" wrap theme={null}
Migrate my InsForge to InstaCloud: the database, its users and the storage files. Carry its existing keys over without printing them. Follow the insta skill's migration runbook, and stop before I switch my app over.
```

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

```text title="Prompt" wrap theme={null}
Give me the new InsForge URL, and confirm the anon key and API key came over unchanged, without printing either value.
```

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](/deploy/overview):

```bash theme={null}
insta deploy .
```

## 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:

```text title="Prompt" wrap theme={null}
Migrate my edge functions too, and check one of them runs before I switch over.
```

## 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](/limitations/overview) covers the ones people hit most, and is worth the minute before you commit. Stuck anywhere? Come to [Discord](https://discord.com/invite/MPxwj5xVvW).