Migrate from Railway to Coolify

Migrate from Railway to Coolify: what the move involves

Moving from Railway to Coolify is a rebuild of each service on Coolify, followed by a data cutover and a domain cutover. Platform engineering or DevOps teams usually own it, because the work is operating servers and re-creating build, runtime and data settings that Railway previously managed for you. Teams usually start this move after a renewal, a change in usage billing, a data residency requirement or a wish to reduce lock-in, and the decision should rest on which of those drives the change. Effort and risk scale with the number of services, the databases with persistent volumes and how many domains and cron jobs depend on the current setup.

Coolify is licensed under Apache-2.0, and its self-hosted edition is free with all features, so the license is not the cost. The recurring costs are the servers you rent or run, the backups you store, the monitoring you add and the people who patch and respond to incidents. Confirm your server sizing against Coolify's stated minimum of 2 CPU cores, 2 GB RAM and 10 GB of free disk, then size up for your real workloads. Ask your team to inventory each Railway service, its railway.json or railway.toml settings, its volumes and its custom domains before anyone provisions a server.

Each service needs a translation step. Build, start and pre-deploy commands, healthchecks and cron schedules must be re-entered in Coolify, and you choose a build pack first: Railpack, Nixpacks, Dockerfile or Docker Compose. Keep the build method identical where you can so that behavior differences are easier to trace. Databases and volumes are the highest-risk items, since Coolify's Coolify database backups guide covers scheduled dumps but you must still prove a restore works before cutting over. Plan a rehearsal, lower DNS TTLs ahead of the switch and keep Railway running until the new stack passes its checks.

Which Railway capabilities map cleanly to Coolify

This table maps each Railway capability to its Coolify equivalent and labels it clean, needs rework or gap. Read the rows as a migration checklist: clean rows move with little change, rework rows need settings translated or rebuilt, and gap rows need a plan before cutover.

Railway capability	Coolify equivalent	Migration status
Build and deploy from Git	Git-based application deploys from GitHub, GitLab, Gitea or Bitbucket, with a webhook or GitHub App for automatic deploys	Clean: connect the repository and set the branch and build pack
Railpack or Dockerfile builds	Coolify offers Nixpacks, Railpack (beta), Static, Dockerfile, Docker Compose and a prebuilt Docker Image method; Railpack is beta in Coolify	Clean for Dockerfile; needs rework for Railpack, which is beta in Coolify, so confirm the build output in your version
Start and pre-deploy commands	Start command is set in the application configuration; a separate pre-deploy step is not a direct equivalent, so run it from the start command or a Dockerfile entrypoint	Needs rework: move pre-deploy logic into the start command or a one-off job and test ordering
Healthchecks	Container health checks are configured in Coolify or the Dockerfile; confirm the exact check behavior and timing in Coolify's docs for your version	Needs rework: recreate each check and confirm how failed checks affect rollout
Cron services	Scheduled tasks run inside Coolify, typically as a scheduled command against an application; confirm how jobs run and log for your version	Needs rework: rebuild each Railway cron schedule and confirm it runs once per schedule
Environment variables	Environment variables are set per application and per environment in Coolify	Clean: copy values and mark secrets, but check build-time versus runtime variables
Private networking	Services on the same Coolify server or Docker network can reach each other; cross-server traffic depends on your network setup	Needs rework: replace Railway internal hostnames with Docker network names or private addresses
Databases	Coolify deploys PostgreSQL, MySQL, MariaDB, MongoDB, Redis, Dragonfly, KeyDB and ClickHouse as one-click services	Clean for PostgreSQL and others listed, but you must size and back up each one yourself
Database backups	Scheduled backups cover PostgreSQL, MySQL, MariaDB, MongoDB and ClickHouse; they do not cover Redis, Dragonfly or KeyDB	Gap for Redis, Dragonfly and KeyDB: plan a separate backup method before cutover
Volumes	Persistent storage is mounted through Coolify's storage settings on the host; Railway volume data does not move automatically	Needs rework: copy volume data to the new server and confirm mount paths and permissions
Custom domains and HTTPS	Traefik or Caddy runs as the proxy and handles HTTPS automatically; Custom (None) leaves routing and certificates to you	Clean for standard domains; plan DNS cutover and confirm certificate issuance on the new host
Preview environments	Preview deployments build pull or merge requests and need wildcard DNS; they are deleted when the request closes	Needs rework: set up wildcard DNS and confirm the preview URL pattern before relying on it

Which parts move cleanly and which need rework

Container images and Dockerfile builds usually carry over with the least change. If a service already builds from a Dockerfile, or builds with Railpack, Coolify can build the same source through its Dockerfile or Railpack build pack, so the build step is the part most likely to behave the same on both platforms. The work is in what Railway kept in configuration. Settings in railway.json or railway.toml, such as the build command, start command, pre-deploy command, healthcheck path and cron schedule, do not get read by Coolify. Each one must be re-entered by hand in the application's Coolify settings, and each should be checked against what the service actually ran on Railway, including values set only in the Railway dashboard that never reached the file. Confirm each cron job's schedule and timezone, because a missed or duplicated run is easy to miss during cutover.

Persistent volumes and database contents do not move because a Coolify redeploy only rebuilds and restarts the application. Plan a separate export and import for every Postgres, MySQL, MariaDB, MongoDB or ClickHouse database, using Coolify's backup and restore features, and copy any files stored on Railway volumes to the new server's storage before the switch. Redis, Dragonfly and KeyDB are not covered by Coolify's scheduled backups, so decide with the application owner whether cached data can be rebuilt or needs a manual copy. Coolify's guide for teams coming from managed platforms also notes that a rollback can redeploy a retained application image but does not restore databases or persistent files. Treat the rollback path as an application-only rollback, and schedule a fresh database dump immediately before domain cutover so the recovery point is known.

Which data and integrations to export and rebuild

Most of the cutover risk sits in data and integrations rather than in the build itself. Each card below covers one item that has to move or be reconnected, with the Coolify path that applies and what to confirm in your Railway project before you start.

PostgreSQL dumps and restores

Export each Railway Postgres database to a dump, then load it through Coolify's Import Backup. Coolify's documented import accepts PostgreSQL SQL dumps, custom archives, tar archives and all-database dumps, and its own scheduled backups use the pg_dump custom format. Choose the format that matches how you exported, verify row counts after restore, and confirm the export method against Railway's current database export options.

Volume contents copied by the operator

Railway volumes hold files that a rebuild from Git will not recreate, such as uploads or generated assets. Copy their contents yourself to a directory or volume on the new server and mount it into the Coolify application. Coolify's guidance for teams coming from managed platforms makes the same point: a rollback can redeploy an application image but does not restore databases or persistent files, so you need your own copy.

Environment variables and secrets re-entered

Railway variables do not move with the code. Re-enter each one in Coolify's application settings and mark secrets as such. Reference variables that point at other services, such as database connection strings, must be rewritten to the new internal hostnames. Compare the full variable list in Railway against Coolify before the first deploy, and confirm that no secret was committed to the repository during the move.

Git webhooks and deploy keys reconnected

Coolify deploys from GitHub (through a GitHub App or webhook), GitLab, Gitea and Bitbucket, so the repository connection has to be created again on the Coolify side. Remove the Railway integration from the repository so pushes do not trigger two deployments. Confirm that the account or service user that owns the connection has access to each repository, and that the branch selected for production is the one you intend to deploy.

Wildcard DNS for preview deployments

Coolify's default preview URL pattern is {{pr_id}}.{{domain}}, which requires a wildcard DNS record pointing at the server. Without it, preview deployments for pull or merge requests will not resolve. Add the wildcard record before you enable previews, and remember that Coolify deletes preview deployments when the request is closed or merged. Teams that rely on Railway's preview environments should test this path before they retire the old setup.

Redis data outside scheduled backups

Coolify's scheduled backups cover PostgreSQL, MySQL, MariaDB, MongoDB and ClickHouse, but not Redis, Dragonfly or KeyDB. If your Railway Redis holds data you need to keep, such as queues or session state, plan a separate export and restore, or decide that the data is cache and can be rebuilt. Confirm which of these cases apply to each Redis instance before cutover.

The migration sequence from inventory to decommission

This sequence moves each Railway service to Coolify in controlled stages, so every workload, database and domain has a tested target and a rollback path before Railway is switched off. Each step ends with a written artifact or a verified check that gates the next one.

Inventory every Railway service and dependency
List every service, database, volume, cron job, environment variable, custom domain and deploy setting in each Railway project, including any railway.json or railway.toml overrides for build, start and pre-deploy commands and healthchecks. Record which services depend on which databases and which DNS records point at Railway. The output is an inventory sheet with one row per resource, an owner, and a status column for later steps. Confirm the list against the Railway dashboard, since config-as-code files may not reflect values set in the UI.
Pilot one stateless service on Coolify
Choose a stateless web service with no persistent volume and deploy it to a Coolify server you control, using the same Railpack or Dockerfile build that Railway used. Translate each build, start, pre-deploy and healthcheck setting into Coolify's application configuration, and set environment variables from the inventory. Test the service on its temporary address before any domain changes. The pilot is done when the service passes its healthcheck, logs show a clean start, and a rollback to the previous image has been tried once.
Run both platforms with staging database copies
Move each remaining service to Coolify while Railway keeps serving production traffic. For each database, dump it from Railway using a format that Coolify's restore tooling accepts, load it into a Coolify PostgreSQL or MySQL instance, and point a staging copy of the service at it. Recreate scheduled jobs as Coolify scheduled tasks and disable the Railway originals so they do not run twice. Check that Redis and other stores without scheduled backups are rebuilt or repopulated as your application expects. The output is a restore test log showing row counts and a spot-check of key records matching the source.
Cut over domains with a documented rollback
Lower the TTL on the DNS records for each public domain well ahead of the change, then point them at the Coolify proxy's server address and confirm that Coolify issues valid HTTPS certificates. Freeze writes to the Railway database, take a final dump, restore it to the Coolify database, and switch the application's connection settings. Keep the Railway services running but idle for the rollback window. The output is a written rollback plan naming the DNS values to restore, the exact step that reverses the database switch, and the person authorized to trigger it.
Verify monitoring, backups and access after cutover
Confirm that the Coolify scheduled backups run on the intended cron schedule, that uploads reach your S3-compatible storage, and that retention settings match your policy. Restore the most recent backup into a separate database and run the application's smoke tests against it. Set up uptime checks, log retention and alerting that replaced what Railway provided, and document who receives alerts. Note that a Coolify rollback can redeploy an application image but does not restore databases or persistent files, so the database restore test is the recovery evidence. The output is a signed restore test record and a monitoring checklist.
Decommission Railway after a verified restore
After the agreed observation period passes without rollback, export a final copy of each Railway database and any volume data, store it in the retention location your policy requires, and confirm it can be read. Remove the Railway services, custom domains, webhooks and deploy tokens, then revoke access for users and CI integrations. Update the inventory sheet to show each resource as migrated or retired. The sequence is complete when the archived exports pass a restore check and no Railway resource remains in use.

What drives the cost and duration of the move

This table lists the factors that change how long the move takes and what it costs to run afterward, with a note on how to reduce each one. Coolify's self-hosted edition is free, so most of the recurring cost sits in servers, backups, monitoring and the staff time needed to operate them.

Driver	Why it changes cost or effort	How to keep it down
Number of services	Each Railway service needs its own Coolify application, build settings, environment variables and healthcheck to be recreated and tested, so the count sets the bulk of the migration work.	Inventory every service in the Railway project first, retire unused ones, and group related services so they can be cut over in batches.
Databases and data size	Dump, transfer, restore and verify time grow with database size, and each database needs its own backup schedule on the new server.	Measure size and write volume before scheduling, use a dump window for small databases, and confirm restore time in a rehearsal copy.
Volumes and persistent files	Railway volumes do not move automatically, so each mounted file set must be copied and mapped to a path on the Coolify host. Coolify's rollback guidance notes that it does not restore persistent files.	List every volume and its mount path, copy them with checksums, and keep a dated backup of each before cutover.
Cron jobs and scheduled tasks	Railway cron services must be recreated as scheduled commands or separate jobs, and duplicate runs can occur if both platforms execute them during overlap.	Disable each cron on Railway at cutover, confirm the Coolify schedule runs once, and record the expected output for each job.
Preview environments	Preview builds need wildcard DNS, a Git provider connection and per-request certificates, and each open preview consumes server resources.	Adopt previews only for teams that use them today, and confirm the wildcard DNS and Git integration before enabling them.
Custom build and pre-deploy steps	Build commands that Railway ran through railway.json or railway.toml must be translated into Coolify build and start settings, and Railpack or Dockerfile differences can change the image.	Pin the build method, compare the image output side by side, and keep the existing Dockerfile where one exists.
Team access and approvals	Every Coolify user, API token and Git connection must be set up and reviewed, and access that was tied to Railway accounts has to be re-established.	Map current Railway members to roles, limit API tokens to the minimum needed, and record who approved each cutover.
Server and on-call time	Servers are rented or owned by the client, and patching, disk growth, failed deploys and incidents become the operator's work. Coolify Cloud at $5 per month for 2 servers plus $3 per additional server (Coolify pricing page), with a 20% discount for annual billing, is an optional managed control plane that does not replace server operations.	Size servers from measured load, automate backups and alerts, and decide in advance who is paged, then ask any partner for the scope of support in writing.

How the move differs by size and starting point

A single web service with one PostgreSQL database is the most direct case. The work centers on one build, one set of environment variables, one database dump and one domain cutover. Because there are few moving parts, most of the effort goes into verifying the database copy and confirming that the application starts cleanly on Coolify's proxy and build path. Illustrative example: a small Node.js API with a Railway-managed PostgreSQL instance can usually be rebuilt from its existing repository in a single Coolify application, with the database created as a separate Coolify resource.

Build method: Confirm whether Railpack or your Dockerfile matches what Railway built, since Coolify offers Nixpacks, Railpack (beta), Dockerfile and Docker Compose build packs.
Database dump: Take a pg_dump from Railway before the cutover window and restore it into the Coolify-managed PostgreSQL, then compare row counts.
Environment variables: Copy variables, but check for references to Railway-internal hostnames that must change.
Domain cutover: Lower DNS TTL in advance, then point the domain at the Coolify server once health checks pass.
Rollback path: Keep the Railway service running until the new database has taken writes and been verified.

Before starting, confirm the PostgreSQL major version you need and whether the application tolerates a short write freeze during the final dump.

A Railway project with several services, persistent volumes and cron jobs needs an inventory before any rebuild. Each service carries its own build, start and pre-deploy commands, healthcheck paths and schedules, and each volume holds state that a rebuild will not recreate. Illustrative example: a project with a web app, a background worker, a Redis service, a file volume and a nightly cron job would need each component mapped and ordered before cutover. Here the sequence emphasis shifts from the database alone to dependency order and state transfer.

Config translation: Read each railway.json or railway.toml entry and record its build, start, pre-deploy and healthcheck values.
Volume data: Copy persistent volume contents to a Coolify-managed path or storage location and verify file counts and checksums.
Cron jobs: Recreate scheduled tasks as scheduled commands, and make sure only one instance runs them after cutover.
Service order: Bring up databases and caches first, then workers, then web services that depend on them.
Redis and cache state: Coolify's scheduled backups do not cover Redis, so decide whether cache data can be discarded.

Confirm with the team which services are stateless, which volumes hold data that cannot be regenerated, and which cron jobs must not run twice during the parallel period.

What usually goes wrong and how to prevent it

Most failed Railway to Coolify moves fail in the same few places: data, files, DNS, secrets and scheduled work. Each risk below has a concrete check to run before cutover, and most of them come down to treating the Railway copy as the only working copy until the new one is proven.

Database restored without a tested backup

A dump that was never restored is not a backup. Coolify's scheduled PostgreSQL backups use the pg_dump custom format, but a Railway database is not protected by Coolify until you have configured and verified the job. Before cutover, take a manual dump, restore it into a scratch Coolify database, and run the application's read paths against it. Check row counts for the tables that matter most.

Persistent files lost during redeploy

Railway volumes do not move with the code. Coolify's own guide for teams coming from managed platforms notes that a rollback can redeploy an application image but does not restore databases or persistent files. List every mounted path on the Railway service, copy those directories out, and mount equivalent storage in Coolify before the first deploy. Then redeploy once and confirm the files survive a restart.

DNS cutover without a rollback window

Changing a domain's record and deleting the Railway service on the same day removes your fallback. Lower the TTL on the existing record ahead of time, point the domain at the Coolify proxy, and keep the Railway service running and reachable until the new stack has served real traffic. Confirm that the Traefik or Caddy proxy issues the certificate for each domain before you change any record that users depend on.

Secrets left behind or mis-copied

Environment variables are the most common silent failure. Export the full variable list from Railway, compare it name by name with the Coolify application settings, and mark build-time and runtime variables correctly, since a variable needed only at build can be missing at start. Remove Railway tokens and deploy keys from the new environment, rotate any credential that was shown in logs or copied through chat, and record who holds each secret.

Cron jobs running twice during parallel run

While both platforms are live, a scheduled job on each side can send duplicate emails, charge customers twice or write the same rows. Disable every cron schedule on Railway before enabling it in Coolify, and confirm the first scheduled run fires on the new side only. Write down which platform owns each job so that a later rollback does not re-enable the old schedule by accident.

Redis data assumed to be backed up

Coolify's scheduled backups cover PostgreSQL, MySQL, MariaDB, MongoDB and ClickHouse, but not Redis, Dragonfly or KeyDB. Teams that use Redis for queues, sessions or cache often assume the same protection applies. Decide per instance whether the data is disposable cache or must survive, and if it must survive, add a tested persistence and copy job of your own. Confirm this with the Coolify docs for your installed version.

Proxy and TLS left at defaults

Coolify runs one coolify-proxy container per server, with Traefik by default or Caddy as the alternative, and the Custom (None) option leaves routing and certificates to you. Accepting defaults without review can expose a dashboard port, miss a redirect from HTTP to HTTPS, or leave a wildcard domain without a certificate. Review the proxy configuration, confirm the security headers and redirects your application expects, and test each domain from outside your network.

Questions teams ask before moving from Railway to Coolify

How much effort and time does moving from Railway to Coolify take?

The effort depends mostly on how many services, databases and domains you run, and on how many build settings you must translate by hand. Each service needs its build, start, pre-deploy and healthcheck settings recreated in Coolify, and each database needs a dump, a restore and a connection string change. Teams with a few services and a single database usually have a smaller job than teams with many interdependent services, cron jobs and volumes. Ask DeployOpen or your own engineers to inventory every Railway service, variable and volume before agreeing a scope, because that inventory sets the timeline more than any other factor.

Can our in-house team move from Railway to Coolify without outside help?

A team that already runs Docker and Linux servers can often do the move in-house, because Coolify deploys from a Git repository, a Dockerfile, a Docker Compose file or a prebuilt image. The harder parts are server hardening, backups, restore testing and cutover planning, which need someone who owns production operations after the switch. If your team has no one who runs Linux servers day to day, a fixed-scope engagement can cover the build, migration and handover while your staff learn the platform. Whichever route you choose, confirm who will hold on-call duty for the new servers.

What do we need to provide before the migration work starts?

You need access to the Railway project, the Git repositories for each service, the environment variable lists, and the database credentials. You also need servers that meet Coolify's minimum requirements, which are at least 2 CPU cores, 2 GB RAM and 10 GB of free disk, on a supported 64-bit Linux distribution. Confirm your DNS provider access, because cutover depends on changing records. Finally, agree on a maintenance window and a rollback owner. Coolify's guide for teams coming from managed platforms notes that a rollback can redeploy an application image but does not restore databases or persistent files, so your backup plan must be written down before cutover.

Is Coolify free to self-host, and what recurring costs remain?

Coolify is licensed under Apache-2.0, and its pricing page describes the self-hosted edition as free forever with all features and no limitations or restrictions. The recurring costs are the servers you rent, the storage and bandwidth for backups, the DNS and domain fees, and the staff time for patching, monitoring and incident response. Coolify Cloud is a separate, paid option: it costs $5 per month for 2 connected servers plus $3 per month for each additional server, with a 20% discount for annual billing, but you still bring your own servers. Ask for a quote that lists each of these components separately so you can compare it with your current Railway bill.

How do we move PostgreSQL databases with pg_dump and keep backups running?

Export each database from Railway with pg_dump, restore it into the PostgreSQL instance Coolify deploys, then point the application at the new connection string. Coolify's PostgreSQL backups use the pg_dump custom format, can upload to S3-compatible storage, and run on cron schedules with retention by count, days or size. Its Import Backup feature accepts SQL dumps, custom archives, tar archives and all-database dumps. Test a restore on a separate server before you retire the Railway database, and confirm the PostgreSQL major version you choose, because PostgreSQL 14 is supported until November 12, 2026 and 18 until November 14, 2030, according to the PostgreSQL versioning policy.

How do domains and HTTPS move when we cut over from Railway?

Coolify runs one coolify-proxy container on each server, with Traefik as the default and Caddy as the alternative, and both obtain and renew HTTPS certificates automatically. For cutover, add each domain to the application in Coolify, lower the DNS TTL in advance, then change the record to the new server once the application passes its healthcheck. If you choose the Custom (None) proxy option, your team must handle routing and certificates itself. Keep the Railway service running until traffic has moved and the new certificates are confirmed, and confirm with your DNS and certificate team that no records or redirects were missed.

Do preview deployments from Railway transfer to Coolify?

Preview deployments do not transfer automatically, because they are a feature of each platform's configuration. Coolify builds pull or merge requests from GitHub (through a GitHub App or webhook), GitLab, Gitea and Bitbucket at a default {{pr_id}}.{{domain}} URL, and it deletes them when the request is closed or merged. That URL pattern needs wildcard DNS and a certificate that covers it, so plan that record before you enable previews. Confirm with your team which Railway preview environments they use today, and check whether each one needs its own database, since Coolify does not copy Railway environments for you.

What support is available during and after the move?

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted platforms inside your own infrastructure. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope. Coolify itself has community documentation and a GitHub repository, and its v4.0.0 release notes describe a v5 aimed at scalability while v4 stays supported. Ask any provider which response times, escalation paths and backup restore tests are included in writing.

How DeployOpen scopes and runs the Railway to Coolify move

DeployOpen is a Chainscore Labs company. We plan, implement, harden, back up, upgrade, document and support self-hosted open-source platforms inside your own infrastructure, whether that is your cloud accounts, your data center or an air-gapped network. For a Railway to Coolify move, that means the Coolify host, its proxy, the application builds, the database instances and the cutover plan all run on servers you control. We do not host the result on our own systems, and we do not issue audit reports or certifications for it. Independent auditors and certification bodies do that work, and we prepare the controls and evidence they will ask for.

Most engagements are fixed-scope. Before work starts, we agree the scope in writing, including which Railway services, databases and volumes are in the move, which cron jobs and pre-deploy commands must be reproduced, the deliverables for each and the timeline. The written scope is also the basis for the quote. DeployOpen does not publish a price list, so the quote follows from the scope rather than a standard rate card. Ask for line items that separate the Coolify host setup, the per-service translation work, the database backup and restore tests, the domain cutover and the handover documentation, so you can see which parts are one-time and which recur.

Once the move is complete, operating the platform is a separate decision. Patching the Coolify host, upgrading Coolify itself, reviewing backup restore tests, monitoring and responding to incidents can be handled by your own team or covered by an ongoing support or upgrade retainer that DeployOpen offers. Confirm in writing who owns each of these items after cutover, and what happens to database backups and restore evidence if the retainer ends. Those answers matter more to your renewal decision than the first deployment.

Migrate from Railway to Coolify