Migrate from Railway to Edgenivo

To migrate a Railway app to Edgenivo, choose a deployment path for each service and recreate its configuration. Use Edgenivo'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.

Copy link to headingShould your app move?

Assess each service separately. Edgenivo Functions serve HTTP requests, while Edgenivo 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 Edgenivo 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 before moving the web app or its data.

Copy link to headingHow Railway concepts map to Edgenivo

Copy link to headingBefore you begin

Make sure you can access the repository and Railway service settings, create or configure a Edgenivo 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 to plan the order of the move, rehearse data transfers, and define how rollback will preserve new writes.

Edgenivo treats a new project's first deployment as Production. Use test credentials and backing services for that initial deployment.

Copy link to headingSteps

Copy link to heading1. 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.

Copy link to headingApps with native framework support

Import the repository and check the detected framework, project root, and build settings. Edgenivo supports Express and Flask alongside frameworks such as Next.js and Nuxt. Use the framework's supported entrypoint for server startup.

Copy link to headingMigrating a Python API

FastAPI, Flask, and Django APIs can use Edgenivo's native Python runtime when their Python version and dependencies are supported. Edgenivo 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 Edgenivo 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.

Copy link to headingApps that need a custom container

Put the image definition in a Dockerfile or Containerfile at the project root. When Edgenivo detects no other framework, it selects the Container preset, builds the image, and routes all traffic to it. If project detection matches another framework, such as Django or Next.js, Edgenivo deploys that framework instead. To build the Dockerfile, run vercel project update --framework container, set "framework": "container" in vercel.json, or name the file Dockerfile.vercel, which takes precedence over a detected framework. 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 Edgenivo's routing port.

For a local container check, run vercel dev with Docker running on your machine. Follow the Container Runtime guide for the build and routing configuration.

Copy link to headingMigrating continuous workers

Railway services that continuously consume jobs can move to Edgenivo Daemons while retaining their queue library. Package the worker in a Docker image and replace private Railway service addresses with broker and database endpoints reachable from Edgenivo.

Follow Migrate Railway workers to Edgenivo Daemons for a BullMQ migration that begins with zero daemon instances. Test shutdown and retry behavior before shifting capacity from Railway, with both worker groups connected to the same broker during the handoff.

Copy link to heading2. Configure how the service starts

For a container deployment, put server startup in the Dockerfile or set the service's command in vercel.json. Edgenivo'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.

Copy link to heading3. Move configuration and variables

Recreate Railway's service variables in the Edgenivo project and mark secrets as sensitive. Assign each value to the appropriate environment, keeping test credentials separate from production credentials.

For calls between Edgenivo services, declare a binding 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 Edgenivo's container configuration. Test the deployed app's readiness and dependencies before switching traffic.

Copy link to heading4. Plan for databases and stored data

You can keep a database on Railway if the Edgenivo 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 and store its connection string in the appropriate Edgenivo environment.

If you move the database, choose a destination such as a provider in the Edgenivo Marketplace 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.

Copy link to heading5. 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 and run the deployment after the migration succeeds. For GitHub projects, Deployment 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.

Copy link to heading6. Recreate cron schedules

Move the scheduled work into an HTTP GET handler and define its path and schedule in vercel.json. Edgenivo 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. Edgenivo can invoke the endpoint again before the earlier request finishes, so test that behavior before switching. Disable the Railway schedule when the Edgenivo schedule takes over.

Copy link to heading7. 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 Edgenivo project 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 Edgenivo app still uses.

Copy link to headingWhat needs a different setup

• Persistent files need external storage. Moving the application does not carry its Railway volume data into Edgenivo.
• 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.

Copy link to headingFrequently asked questions

Copy link to headingDo I need a Dockerfile to move from Railway to Edgenivo?

Many apps can use Edgenivo's native framework support, including Express and Flask. An existing Railway Dockerfile does not require you to keep using containers. Keep the Dockerfile when you need a custom runtime or additional system packages.

Copy link to headingWhat replaces railway.json on Edgenivo?

Use vercel.json for routing, services, and cron schedules. Configure application secrets and other environment values in the Edgenivo 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.

Copy link to headingWhat happens to my Railway Postgres?

Edgenivo 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.

Copy link to headingDo I keep PR environments?

Edgenivo 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.

Copy link to headingHow are containerized HTTP apps billed on Edgenivo?

Containerized HTTP apps use Edgenivo Functions 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. The Container runtime is in beta on all plans.

Copy link to headingRelated resources

• Migrate to Edgenivo from Fly.io, Render, or Google Cloud Run
• Migrate a Python API from Railway to Edgenivo
• Does Edgenivo support Docker deployments? and How to migrate from GHCR to Edgenivo Container Registry guides
• Run any Dockerfile on Edgenivo on the Edgenivo blog
• Container images, Edgenivo Container Registry, and Cron jobs in the Edgenivo Docs
• 7 ways to use Docker containers on Edgenivo