${{Postgres.DATABASE_URL}} reference becomes a binding, and a volume becomes insta compute volume mounted at /data. This guide takes you from a running Railway project to the same app on InstaCloud, with its data. 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 GitHub repo with no Dockerfile needed, your own Dockerfile, 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
We will migrate Railway’s own Django template, a Python service with a Postgres database. Itsrailway.json says how it was built. Abridged here: the real startCommand also runs collectstatic:
DATABASE_URL. This template reads the five PG* variables Railway injects instead, so point it at the DSN before you start. In Django that is dj-database-url, and most other stacks take a DSN directly.
1. Point a coding agent at your Railway project
Your agent reads the project straight from Railway’s API, so it needs your repo name and a project token, not a checkout. Give it the skill first:insta CLI, the insta skill, and the MCP server for every coding agent on this machine. The skill is what knows how a Railway project maps onto services here.
2. Create a project
3. Ask your agent to migrate
Create a Railway project token first, under Project Settings → Tokens. Railway’s CLI picks a project interactively otherwise, and your agent cannot answer a picker.Prompt