How to migrate off of Railway

Migrating from Railway to Northflank involves moving your application services, configuration, databases, and persistent files, then switching production traffic to the new environment. Most applications can keep their existing code, but you may need to adjust build configuration, networking, environment variables, and database connections.

On October 21, 2026, Railway disclosed a security incident involving potential unauthorised access to customer environment variables. Railway advised customers to rotate credentials and review service logs. If you're considering a move, it's also an opportunity to review your deployment platform, credential management, and recovery procedures. You don't need to be affected by an incident to benefit from a migration. See Railway's security disclosure for its guidance.

Northflank is a managed cloud platform for deploying applications, running databases, and scaling production workloads. You can deploy without operating the underlying Kubernetes infrastructure yourself, or use bring your own cloud (BYOC) to run the platform in your own cloud account. Northflank also provides AI agent tools that can help speed up configuration and deployment work.

This guide explains how to migrate your Railway workloads to Northflank, transfer data safely, test the new environment, and switch traffic without unnecessary downtime.

Northflank's managed cloud lets you build, deploy, and scale applications without provisioning or managing the underlying Kubernetes infrastructure yourself. Connect a Git repository or deploy a container image, configure your services, and manage deployments from one platform.

You can run web applications, APIs, background workers, scheduled jobs, and supported database addons together. Northflank also provides networking, health checks, logs, metrics, and configurable scaling to help you operate production workloads.

Production readiness involves more than getting an application to build. You need to manage deployments, database availability, backups, resource allocation, monitoring, and recovery.

Northflank supports configurable autoscaling, managed database addons, backup and restore workflows, and deployment controls. You can configure resources and availability to match your workload, while preview environments help you test changes before releasing them.

Northflank also supports enterprise capabilities such as SSO, SCIM, and audit logging, depending on your plan and agreement. Security controls also include BYOC, workload isolation, network security, and envelope encryption, helping teams manage infrastructure access and reduce exposure. Deployment rollbacks and monitoring can help teams respond to failed changes and investigate incidents.

Availability and recovery depend on how you configure your application, databases, and backups. No platform can eliminate every security risk. See the Northflank security documentation for more details.

With Northflank BYOC, you can run the platform in your own supported cloud infrastructure, including AWS, Google Cloud, and Azure. Northflank manages the underlying Kubernetes infrastructure while your organisation retains control over its cloud account.

BYOC is optional. You can start with Northflank's managed cloud and switch to your own cloud infrastructure if your requirements change.

Northflank Skills give supported coding agents platform-specific knowledge, while the Northflank MCP server provides authenticated tools to interact with Northflank. You can use an AI coding agent to inspect your repository, identify Railway-specific configuration, and prepare updated service definitions. Cloud Harnesses provide isolated cloud workspaces for running coding agents, while Northflank sandboxes let you execute untrusted code in isolated environments.

These tools can reduce manual work, but you should still review configuration changes, validate migrated data, and approve production cutover yourself.

Before migrating, identify the Railway resources your application uses and the corresponding resources you'll create on Northflank.

These resources don't always have a one-to-one equivalent. Database data, persistent files, private hostnames, and scheduled tasks need explicit migration plans.

Start by documenting every service and dependency in your Railway project, including internal APIs, workers, and scheduled tasks.

For each service, record its repository, branch, build and start commands, listening port, environment variables, resource requirements, database connections, persistent files, and custom domains.

Also identify integrations that reference Railway URLs, such as OAuth callbacks, webhooks, and IP allowlists. These can break after migration even if your application builds successfully.

For databases, record the engine version, extensions, storage size, and available backups. This inventory becomes your migration checklist and helps you identify which resources need to move together.

If you're migrating in response to a security incident, follow the source provider's current security guidance and your organisation's incident response process.

Rotate credentials at their source, including database passwords, API keys, payment provider tokens, cloud credentials, and private registry credentials where necessary. Removing a variable from Railway doesn't invalidate the underlying credential.

Store replacement credentials securely and configure them in Northflank. Don't blindly copy every variable: some reference Railway-specific hostnames, generated domains, or provider-specific settings.

Separate production and development credentials, and grant each service only the access it needs.

You can use Northflank Skills with a supported coding agent to help identify Railway-specific references in your codebase and prepare updated configuration.

Create a project on Northflank's managed cloud, or in a BYOC cluster if you need to run the platform in your own cloud account. Choose a region that fits your users, database location, and latency requirements.

Connect your Git provider and create a service from the repository and branch you want to migrate. Northflank supports builds from Dockerfiles and supported buildpacks, as well as deployments from container registries.

If your application already has a Dockerfile, start with it. If Railway uses Railpack to build your application, reproduce the required build behaviour using a Dockerfile or supported buildpack. Railway-specific build settings won't automatically configure the destination service.

Deploy the same application revision that runs in production before introducing unrelated code changes. For background workers, configure the worker command rather than starting the web server. Keep scheduled jobs disabled until their dependencies are ready.

Northflank Skills and MCP can help an agent prepare service configuration and interact with Northflank during this step.

Configure the application port and ensure the process listens on the appropriate network interface, usually 0.0.0.0, so the platform can route traffic to it.

Expose public ports for applications that need internet access, and use private connectivity for internal APIs and databases where appropriate. Update connection strings, TLS settings, public URLs, OAuth callback URLs, and webhook destinations.

Railway private domains won't automatically resolve from Northflank. Replace Railway-specific hostnames with the corresponding Northflank service addresses or configured external endpoints.

Also check whether your framework embeds environment variables at build time. Changing a runtime variable won't necessarily update an API URL already included in a compiled frontend, so you may need to rebuild the application.

Before moving on, verify that each service can reach its dependencies and that secrets are available only to the workloads that need them.

Database migration is one of the most important parts of moving off Railway. Choose a strategy based on database size, write activity, and acceptable downtime.

Create a compatible database on Northflank or configure your application to use an external database. Match the source engine version where practical and verify that required extensions, permissions, and settings are supported.

Perform a trial export and import before the final cutover. For PostgreSQL, you can use tools such as pg_dump and pg_restore, depending on the dump format and your migration workflow.

Check tables, row counts, indexes, constraints, permissions, and application queries. Test the restored database using the actual application, not just the database client.

Follow the migration guide for your database engine before starting. See the PostgreSQL migration guide or the MongoDB migration guide.

For a smaller database with an acceptable maintenance window:

1. Stop application writes and pause workers that modify the database.
2. Export the final source database.
3. Restore it into the destination database.
4. Validate the restored data.
5. Start the Northflank application with the destination connection string.

For a larger or continuously active database, investigate replication-based migration if the source and destination support a compatible approach. Stop writes briefly for the final switch and ensure replication has caught up.

A dump taken while the source continues accepting writes won't include changes made after its snapshot. Plan explicitly for that gap.

Database exports won't automatically include files stored in Railway volumes. Identify uploaded files, generated assets, and other persistent data, then transfer them separately into the appropriate destination storage.

For Redis, determine whether it holds disposable cache data, sessions, or durable queue state. A cache can often be rebuilt, while sessions and queued jobs may need an explicit migration or invalidation strategy.

Before switching production traffic, test the destination using a temporary Northflank endpoint or staging domain.

Verify authentication, database reads and writes, file uploads, background jobs, scheduled tasks, webhooks, and external API integrations. Test error handling and behaviour under representative load.

Use sandbox integrations where possible to avoid triggering real payments or processing production events during testing. Northflank sandboxes can also provide isolated environments for executing untrusted code when that's part of your application's workflow.

Configure appropriate health checks and confirm that logs and monitoring will expose errors during cutover. A successful build alone doesn't establish that your application is ready for production.

Once the application and data have been validated, prepare the production cutover.

Configure your custom domain on Northflank and follow the platform's domain verification and TLS setup instructions. If you control DNS, lower the TTL in advance and allow the previous TTL to expire before switching.

For a migration that requires a maintenance window:

1. Pause writes, workers, and scheduled jobs on Railway.
2. Complete the final database and file transfer.
3. Validate the destination data.
4. Start the Northflank application with the new credentials and endpoints.
5. Change DNS or your existing traffic-routing configuration.
6. Enable workers and scheduled jobs on Northflank.
7. Monitor errors, latency, database connections, and queue processing.

Some clients may continue using cached DNS records after the change. Ensure the old deployment doesn't continue accepting writes to an outdated database.

Define your rollback procedure before switching traffic. Once the destination database accepts new writes, sending traffic back to the old deployment can cause data loss if the old database hasn't received those changes. Application rollback and database rollback are separate operations.

Monitor the application through a representative workload cycle. Check delayed webhooks, scheduled tasks, queue processing, and background jobs as well as immediate user traffic.

Verify that backups run successfully and test restoring one into a separate environment. Configure database replication, application replicas, scaling limits, and alerts according to your availability requirements.

Once the new environment is operating correctly, remove unused Railway services, volumes, credentials, and integrations. Retain migration backups according to your data retention policy.

Finally, compare costs using equivalent configurations. Include application compute, database replicas, storage, backups, builds, and network traffic. Compare the resources required to meet the same performance and availability targets, not just the headline price.

The application builds but won't start. Check the startup command, runtime version, required system packages, and listening port. If Railway handled the build automatically, verify that your new build configuration reproduces the required behaviour.

The application can't connect to the database. Verify the connection string, hostname, port, credentials, TLS settings, and network access. Railway private hostnames won't automatically work from Northflank.

Uploaded files are missing. Persistent files aren't necessarily included in a database dump or application image. Transfer them separately before switching traffic.

Scheduled jobs run twice. Disable the old schedules before enabling their replacements, and consider whether jobs need idempotency safeguards.

Rollback would lose recent data. If the destination has accepted writes, the original database may be out of date. Plan for database consistency before cutover rather than assuming that reverting DNS restores the previous state.

Usually, yes. Standard applications can often keep their existing code. The main changes involve build configuration, environment variables, networking, storage, and database connections. Code that depends on Railway-specific variables or endpoints may need updating.

It depends on your application and data architecture. Stateless services are generally easier to move with overlapping deployments. Stateful applications may require replication or a maintenance window to avoid losing writes. DNS changes alone don't provide a zero-downtime database migration.

Yes. Northflank Skills give supported coding agents platform-specific guidance, while MCP lets them interact with Northflank. Agents can help prepare configuration, deploy services, and troubleshoot issues. Review their changes and validate the migration before production cutover.

Northflank supports production deployments, managed database addons, autoscaling, observability, backups, and configurable infrastructure. Availability and recovery depend on how your services and databases are configured. You can start on managed cloud and use BYOC if you need to run the platform in your own cloud account.