--- title: How to migrate from Railway to Vercel description: Migrate an app from Railway to Vercel. Choose a deployment path, configure services, plan for stored data, and test before switching production traffic. url: "https://vercel.com/kb/guide/migrate-railway-to-vercel" published: 2026-10-22 last_updated: 2026-10-22 authors: Ben Sabic related_resources: - title: "How should you plan a migration off Railway?" url: "https://vercel.com/i/railway-migration-checklist" description: "Plan a Railway migration around service dependencies, data transfers, testing, and rollback. Decide what moves first before switching production traffic." - title: "4 Railway alternatives for web apps, APIs, and workers" url: "https://vercel.com/i/railway-alternatives" description: "Compare Railway alternatives by workload. Evaluate Vercel, Render, Fly.io, and self-hosted Coolify for your application, workers, and stored data." - title: "Migrate a Python API from Railway to Vercel" url: "https://vercel.com/kb/guide/migrate-a-python-api-from-railway-to-vercel" description: "Move a FastAPI, Flask, or Django API from Railway to Vercel Functions. Replace railway.json start commands, volumes, Celery workers, and cron services." - title: "Running Docker on Vercel" url: "https://vercel.com/kb/guide/docker" description: "Learn how to run Docker on Vercel by deploying OCI container images as Vercel Functions, storing them in Vercel Container Registry (VCR), and running containers in Vercel Sandbox." - title: "The Complete Guide to Vercel Services" url: "https://vercel.com/kb/guide/vercel-services" description: "Vercel Services let you deploy multiple frontends and backends in one project on a shared domain. Learn how to define services in vercel.json, route requests by path prefix, and connect services with generated environment variables." install_vercel_plugin: npx plugins add vercel/vercel-plugin --- To migrate a Railway app to Vercel, choose a deployment path for each service and recreate its configuration. Use Vercel's framework integration when it supports your app, or a container deployment when you need a custom image. Plan separately for databases, stored files, and background processes. Moving the web app does not require moving every backing service, but the new deployment must be able to reach the services it keeps. ## Should your app move? Assess each service separately. Vercel Functions serve HTTP requests, while [Vercel Daemons](https://vercel.com/docs/daemons) run continuous background processes. Check how the app handles state and work before choosing either path: - Does it store data between requests or restarts? Keep sessions, uploads, and other persistent data in a backing service that the Vercel deployment can reach. - Can the HTTP service handle instances scaling down when idle? Functions scale with traffic, so any instance must be able to handle the next request. - Does the service continuously pull jobs from a queue or workflow engine? Consider Daemons, which is in Public Beta with production-only execution and configured instance counts. If you are still choosing a destination, compare [Railway alternatives by application need](https://vercel.com/i/railway-alternatives) before moving the web app or its data. ## How Railway concepts map to Vercel | Railway | Vercel | | ------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | | `railway.json` / `railway.toml` | `vercel.json` | | Railpack or Nixpacks builder | Native framework integration where supported | | `builder: DOCKERFILE` with `dockerfilePath` | Native integration or a custom container | | `startCommand` | Framework entrypoint, image startup, or [`command`](https://vercel.com/docs/services/config-reference#command) | | Injected `PORT` variable | Container routing uses project `PORT`, default 80 | | `railway up` | `git push` or `vercel deploy` | | PR environments | Preview deployments with separate test resources | | Service and reference variables | Environment variables and explicit service bindings | | Multiple services | Services with public routes defined by rewrites | | App sleeping | Container Functions scale in after 5 idle minutes in Production or 30 seconds in Preview | | Continuous workers | Daemons, subject to Public Beta limits | | Cron schedules | HTTP schedules in `vercel.json` | | Volumes | External storage for persistent data | | `preDeployCommand` | CI migration required before production release | ## Before you begin Make sure you can access the repository and Railway service settings, create or configure a Vercel project, and update the domain's DNS records. Record each service's build and start commands, environment variables, and dependencies. Include scheduled jobs and workers in that inventory. Use the [Railway migration checklist](https://vercel.com/i/railway-migration-checklist) to plan the order of the move, rehearse data transfers, and define how rollback will preserve new writes. Vercel treats a new project's [first deployment as Production](https://vercel.com/docs/deployments/environments#first-deployment). Use test credentials and backing services for that initial deployment. ## Steps ### 1\. Pick your build path Choose the HTTP app's deployment path from its runtime requirements. An app built with Railpack or Nixpacks may use native framework support, and an existing Dockerfile does not prevent that choice. For continuous-worker configuration, follow the [Daemons quickstart](https://vercel.com/docs/daemons#quick-start). #### Apps with native framework support Import the repository and check the detected framework, project root, and build settings. Vercel supports [Express](https://vercel.com/docs/frameworks/backend/express) and [Flask](https://vercel.com/docs/frameworks/backend/flask) alongside frameworks such as Next.js and Nuxt. Use the framework's supported entrypoint for server startup. #### Migrating a Python API FastAPI, Flask, and Django APIs can use [Vercel's native Python runtime](https://vercel.com/docs/functions/runtimes/python) when their Python version and dependencies are supported. Vercel installs the declared packages and loads the application's entrypoint, so you don't need Railway's `deploy.startCommand` or `PORT` for a native Python deployment. Follow [Migrate a Python API from Railway to Vercel](https://vercel.com/kb/guide/migrate-a-python-api-from-railway-to-vercel) for Python version pins, dependency files, framework entrypoints, and database checks. If your API needs system packages outside the native runtime, use the custom container path below. #### Apps that need a custom container Copy the image definition to `Dockerfile.vercel` at the project root. Vercel detects the file and builds the image for deployment. If you configure a different Dockerfile path through a service, its `entrypoint` is relative to that service's `root`. Container traffic uses port 80 by default. Set the project's `PORT` environment variable when the server listens elsewhere, and make the server read that value. An `ENV PORT` instruction in the Dockerfile alone does not change Vercel's routing port. For a local container check, run `vercel dev` with Docker running on your machine. Follow the [Container Runtime guide](https://vercel.com/docs/functions/runtimes/container) for the build and routing configuration. ### 2\. Configure how the service starts For a container deployment, put server startup in the Dockerfile or set the service's [`command`](https://vercel.com/docs/services/config-reference#command) in `vercel.json`. Vercel's override replaces the image's `CMD`. Railway's Docker `startCommand` replaces `ENTRYPOINT`, so check both image instructions when transferring an override. Move database migrations or other release setup out of startup and into the pipeline in step five. Apps using native framework support should follow that framework's entrypoint requirements. ### 3\. Move configuration and variables Recreate Railway's service variables in the Vercel project and mark secrets as sensitive. Assign each value to the appropriate environment, keeping test credentials separate from production credentials. For calls between Vercel services, declare a [binding](https://vercel.com/docs/services/bindings) on the calling service. The binding names the target and the environment variable that receives its URL. Review Railway reference variables individually because shared secrets and other values still need their own configuration. Railway's `restartPolicyType`, `healthcheckTimeout`, and `healthcheckPath` do not transfer into Vercel's container configuration. Test the deployed app's readiness and dependencies before switching traffic. ### 4\. Plan for databases and stored data You can keep a database on Railway if the Vercel app can reach it through an external endpoint. Railway's private service addresses only work inside the Railway environment. For PostgreSQL, configure the [external connection](https://docs.railway.com/databases/postgresql#connecting-externally) and store its connection string in the appropriate Vercel environment. If you move the database, choose a destination such as a provider in the [Vercel Marketplace](https://vercel.com/marketplace/category/database) and test a backup restore before cutover. Use tooling for that database engine. For example, `pg_dump` exports PostgreSQL data, but the export does not include writes made after its snapshot. Plan how to capture those later writes before changing the production connection string. Depending on the database and downtime requirements, this may mean pausing writes for a final transfer or using replication. Keep the original database available until you have verified the transfer and settled the rollback plan. Move files that currently depend on a Railway volume to persistent storage appropriate to the data. Store uploads in object storage and keep session state in a shared database or cache so replacement instances can access it. ### 5\. Make release depend on successful migrations Move Railway's `preDeployCommand` into a release pipeline that runs the migration and stops on failure. Production deployment or promotion must wait for that result, including any release setup removed from startup in step 2. If CI owns deployment, disable automatic [Git deployments](https://vercel.com/docs/project-configuration/git-configuration) and run the deployment after the migration succeeds. For GitHub projects, [Deployment Checks](https://vercel.com/docs/deployment-checks#github-checks) can hold production domain assignment until the required checks succeed. Keep schema changes compatible with the app still serving traffic and the version you would restore during rollback. Remove obsolete schema only after those versions no longer need it. ### 6\. Recreate cron schedules Move the scheduled work into an HTTP `GET` handler and define its path and schedule in `vercel.json`. Vercel Cron Jobs invoke the Production deployment, so test the handler directly before enabling its schedule. Each invocation must finish within the applicable function duration limit. Set `CRON_SECRET` and validate the bearer token in the request's `Authorization` header against that secret before doing work. Make repeated invocations safe and use a shared lock if runs must not overlap. Railway skips a schedule while its previous run is active. Vercel can invoke the endpoint again before the earlier request finishes, so test that behavior before switching. Disable the Railway schedule when the Vercel schedule takes over. ### 7\. Verify and cut over After the first deployment, create a Preview deployment through the Git integration or CI pipeline configured in step five. Use isolated test credentials and backing services to test complete user flows, including writes and authentication, plus uploads or service-to-service calls the app uses. Replace the initial test values with the intended Production configuration, then create and verify a fresh deployment. [Add the domain to the Vercel project](https://vercel.com/docs/domains/working-with-domains/add-a-domain) and use the DNS records shown for that project when you are ready to cut over. Update callback URLs or webhook destinations if their URLs change. Coordinate the database transition from step four and the scheduled-job handoff from step six. If workers also move, arrange for the intended worker group to own the jobs during the transition. Monitor runtime logs and test production user flows after switching traffic. Keep Railway available until the new deployment is stable, with a rollback plan that preserves writes made after cutover. Retain any Railway databases or services the Vercel app still uses. ## What needs a different setup - Persistent files need external storage. Moving the application does not carry its Railway volume data into Vercel. - Daemons supports continuous workers in Production. The Public Beta uses configured instance counts without autoscaling. - Railway's `preDeployCommand` becomes an explicit release dependency. Failed migrations must prevent production release. - Railway's `healthcheckPath` does not transfer into container configuration. Decide which readiness checks must pass before promoting the deployment. - Secure Compute and Static IPs do not support custom container images. Check egress allowlists on backing services before choosing custom containers. ## Frequently asked questions ### Do I need a Dockerfile to move from Railway to Vercel? Many apps can use Vercel's native framework support, including Express and Flask. An existing Railway Dockerfile does not require you to keep using containers. Choose `Dockerfile.vercel` for a custom runtime or additional system packages. ### What replaces railway.json on Vercel? Use `vercel.json` for routing, services, and cron schedules. Configure application secrets and other environment values in the Vercel project. Build and startup settings depend on the framework or container path you choose. For custom containers, project `PORT` controls routing, while Railway's restart-policy and health-check fields do not transfer. ### What happens to my Railway Postgres? Vercel can connect to Railway Postgres through its external endpoint. If you move to another provider, test the restore and account for writes made after the export before changing the production connection string. ### Do I keep PR environments? Vercel provides Preview deployments for branches other than the production branch after the project's initial deployment. Each has its own URL. Configure the Preview environment with test credentials and backing services to preserve the isolation your app needs. ### How are containerized HTTP apps billed on Vercel? Containerized HTTP apps use [Vercel Functions pricing](https://vercel.com/docs/functions/usage-and-pricing). Fluid compute usage includes Active CPU, Provisioned Memory, and Invocations. CPU billing pauses while code waits for I/O, but memory remains billable while requests are in progress. Estimate these resources alongside your plan and backing-service costs. ## Related resources - Migrate to Vercel from [Fly.io](https://vercel.com/kb/guide/migrate-fly-io-to-vercel), [Render](https://vercel.com/kb/guide/migrate-render-to-vercel), or [Google Cloud Run](https://vercel.com/kb/guide/migrate-cloud-run-to-vercel) - [Migrate a Python API from Railway to Vercel](https://vercel.com/kb/guide/migrate-a-python-api-from-railway-to-vercel) - [Does Vercel support Docker deployments?](https://vercel.com/kb/guide/does-vercel-support-docker-deployments) and [How to migrate from GHCR to Vercel Container Registry](https://vercel.com/kb/guide/migrate-ghcr-to-vcr) guides - [Run any Dockerfile on Vercel](https://vercel.com/blog/dockerfile-on-vercel) on the Vercel blog - [Container images](https://vercel.com/docs/functions/container-images), [Vercel Container Registry](https://vercel.com/docs/container-registry), and [Cron jobs](https://vercel.com/docs/cron-jobs) in the Vercel Docs - [7 ways to use Docker containers on Vercel](https://vercel.com/i/7-ways-to-use-docker-containers-on-vercel) ## Related Resources - [How should you plan a migration off Railway?](https://vercel.com/i/railway-migration-checklist): Plan a Railway migration around service dependencies, data transfers, testing, and rollback. Decide what moves first before switching production traffic. - [4 Railway alternatives for web apps, APIs, and workers](https://vercel.com/i/railway-alternatives): Compare Railway alternatives by workload. Evaluate Vercel, Render, Fly.io, and self-hosted Coolify for your application, workers, and stored data. - [Migrate a Python API from Railway to Vercel](https://vercel.com/kb/guide/migrate-a-python-api-from-railway-to-vercel): Move a FastAPI, Flask, or Django API from Railway to Vercel Functions. Replace railway.json start commands, volumes, Celery workers, and cron services. - [Running Docker on Vercel](https://vercel.com/kb/guide/docker): Learn how to run Docker on Vercel by deploying OCI container images as Vercel Functions, storing them in Vercel Container Registry (VCR), and running containers in Vercel Sandbox. - [The Complete Guide to Vercel Services](https://vercel.com/kb/guide/vercel-services): Vercel Services let you deploy multiple frontends and backends in one project on a shared domain. Learn how to define services in vercel.json, route requests by path prefix, and connect services with generated environment variables. ## More Vercel Services guides - [How to migrate from Google Cloud Run to Vercel](/kb/guide/migrate-cloud-run-to-vercel): Move a Cloud Run service or worker to Vercel. Compare runtimes, preserve Google Cloud access, and plan jobs, validation, and production cutover. - [How to use Vercel Container Registry](/kb/guide/how-to-use-vercel-container-registry): Push, store, and pull OCI container images with Vercel Container Registry, then deploy them to Vercel Functions and Vercel Sandbox. - [How to migrate from Fly.io to Vercel](/kb/guide/migrate-fly-io-to-vercel): Move an app from Fly.io to Vercel. Map configuration, choose Functions or Daemons, plan persistent storage, and verify the production cutover.