Migrate from another platform

Helicarrier can pull an existing project in from Render, Railway, or Vercel — recreating your services and their configuration — and (for Render/Railway) import your Postgres data so you land running.

Render → Helicarrier

1. In + New → Import, choose Render and paste your Render API key (used only for the import, never stored).
2. Helicarrier reads your Render workspace and maps it onto a blueprint: web services and workers, their build/start commands and env vars, Render Postgres and Key-Value stores re-provisioned as managed databases, and connection URLs rewired to references.
3. Your environment groups come across as real environment groups (reusable, attached to the same services), and any secret files — whether on a group or a service — are carried over as mounted files, so config that lived in a file (like a .env) isn’t lost.
4. Review the services (rename or drop any), then apply.

Railway → Helicarrier

Same flow with a Railway personal or team token: environments, services, build config, and connection URLs come across as a blueprint you review and apply. The token is used per-request and never persisted.

Vercel → Helicarrier

A Vercel project is a single deployment unit — a git repo plus a framework and build settings — so it maps to one Helicarrier service, not a set of them.

1. In + New → Import, choose Vercel and paste a Vercel access token (vercel.com → Account Settings → Tokens; used only for the import, never stored). It needs read access so variable values can be read decrypted.
2. Pick the team, the project, and which environment (Production / Preview / Development) to import the variables from.
3. Helicarrier reads the project and stages it as a blueprint: the connected git repo builds here — a Static service for static/SPA frameworks (Vite, CRA, Astro, …) or a Web service for SSR frameworks (Next.js, SvelteKit, Nuxt, …) — carrying the framework’s build settings and the chosen environment’s variables.
4. Review and apply.

Note

Vercel data isn’t copied. Any database or connection URLs in your variables are kept as-is, so your app keeps pointing at its current provider (Neon, Vercel Postgres, an external DB, …). Custom domains are noted so you can add them here and repoint DNS once the service is live. The project must have a connected git repository — CLI-only projects can’t be rebuilt, so deploy those from GitHub directly.

Docker Compose

If you’d rather start from a compose file, see Templates & blueprints → Deploy from docker-compose.

Bringing your data across

For PostgreSQL, you can import your existing data: give Helicarrier the source database’s connection URL and it runs a dump-and-restore into the managed database (inside the managed container, within a time budget). This is available on the managed database’s tools once it’s provisioned.

Note

Config for all engines is migrated, but data import currently covers PostgreSQL. For MySQL / Mongo / Redis, recreate the database and load your data with your usual tools after the services are up.

Next

• After import, wire any custom domains and confirm runtime logs.
• Set services that build from git — see Deploy from GitHub.