.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
Railway built a really pleasant deploy experience, then changed the pricing model in ways that surprised a lot of people. The old Hobby plan got killed, the new usage-based metered model with the $5 minimum and per-resource billing made bills jump for anyone running more than a couple of services and the recent pricing tweaks pushed teams to look at alternatives. If the new pricing is "fair" is its own debate. The math is what the math is.
Coolify is the closest like-for-like swap on a flat-rate VPS. Same Git push to deploy, same one-click Postgres and Redis, same automatic SSL and custom domain support, same template-based service architecture. The bill becomes the cost of the underlying VPS and that's it.
This guide covers a Railway-to-Coolify migration end to end. The mental model maps cleanly because both products use Nixpacks under the hood, so most of your Dockerfile-free deploys port over without changes. Written against Coolify v4.0.0.
How Railway concepts map to Coolify
Railway's structure is project → environment → service. Coolify's structure is project → resource. The translation is mostly mechanical.
A Railway project becomes a Coolify project. A Railway service (the thing that runs your app) becomes a Coolify resource of type Application. A Railway plugin (Postgres, Redis, MySQL) becomes a Coolify resource of type Database. Railway's environments (production, staging) translate to either separate Coolify projects or separate branches deployed as separate apps within one project, depending on how isolated you want them.
Railway templates that bundled multiple services into one project (like the n8n template or the Strapi+Postgres template) translate to multiple Coolify resources in the same project, optionally orchestrated together via Docker Compose if they need to start in a specific order.
Variables transfer cleanly. Railway's ${{Postgres.DATABASE_URL}} reference syntax doesn't carry over (Coolify doesn't have a built-in variable templating system), but the underlying URL itself does. You'll set DATABASE_URL directly in Coolify pointing at the internal hostname of your new Postgres resource.
Step 1, snapshot your Railway project before you touch anything
Don't shut down anything yet. While Railway is still serving traffic, capture the artifacts you'll need.
Take a database backup
If you're using Railway Postgres, the official path is the Railway CLI:
railway login
railway link
railway run pg_dump $DATABASE_URL --no-owner --no-acl -F c -f railway.dumpThe -F c flag produces a custom-format dump (compressed, restorable with pg_restore). Keep this file, you'll restore it after spinning up Coolify Postgres. For larger databases, run this on a fast network connection because the dump downloads through your Railway tunnel.
If you have multiple databases (separate Postgres for staging and production or a Postgres plus a separate analytics Postgres), repeat for each. Note the Postgres version of each one (railway run psql $DATABASE_URL -c "SELECT version();"), you'll match it on the Coolify side.
For Redis, you usually don't need to migrate. Redis is mostly cache and your app will repopulate it. If you have queue jobs or session data you actually need, run BGSAVE on Railway's Redis, retrieve the dump file or replay the data through your application code on the new instance.
Pull environment variables for each service
From the Railway CLI:
railway variables --service your-service-name > railway-env.txtRepeat for each service. Open the resulting files and review. You'll have things like DATABASE_URL, REDIS_URL, your application secrets and any third-party API keys. Strip the Railway-managed ones (DATABASE_URL and REDIS_URL will be regenerated), keep everything else.
Note your custom domains
Railway's custom domain UI shows the current DNS record (CNAME pointing to a Railway-generated hostname). For the cutover you'll change this to an A record pointing at your VPS IP, so capture the current setup so you have a rollback target.
Identify your build settings
Railway uses Nixpacks by default (same as Coolify), so most of your services don't need any custom build configuration on the Coolify side. If you have a nixpacks.toml at your repo root, Coolify will pick it up the same way Railway does. If you're using a custom Dockerfile (Railway's Dockerfile builder), Coolify supports that path too with no changes.
Check Railway's settings for any custom start command, custom build command or root directory (for monorepos). These settings become the equivalent fields in Coolify's application General tab.
Step 2, set up Coolify and connect your Git source
If you're starting from scratch, the LumaDock Coolify VPS ships with Coolify v4.0.0 already running. Provision the VPS, the dashboard is reachable on port 8000, follow the getting started guide for the initial admin setup and securing the dashboard.
Connect your Git provider. Click Sources in the left sidebar, click Add, pick GitHub App for GitHub repos (or GitLab/Gitea/Bitbucket for those). Authorize and install on the org or account that owns your repo.
Create a project (use the same name as your Railway project for sanity) and inside the project we'll add resources one by one in the same order Railway provisioned them.
Step 3, recreate databases first
Spin up databases before applications, because the application's DATABASE_URL needs to reference the database that already exists.
Inside your project click Add a new resource, pick Database, pick the database type that matches Railway. PostgreSQL, MySQL, Redis, MongoDB are all available as one-clicks. Match the version (Railway's defaults are usually current, so Postgres 16 maps to Postgres 16). Accept the auto-generated credentials, click Start.
Note the resource name Coolify shows you. This becomes the internal hostname for connections, something like postgres-database-abc123.
Restore your dump. SCP the dump file onto your VPS, then run pg_restore from a temporary container on the Coolify Docker network:
scp railway.dump root@your-vps-ip:/tmp/
# Then SSH to the VPS:
docker run --rm -it \
--network coolify \
-v /tmp/railway.dump:/tmp/railway.dump \
postgres:16 \
pg_restore -h postgres-database-abc123 -U your-db-user -d your-db-name --no-owner --no-acl /tmp/railway.dumpSubstitute the hostname, user, database name and version with whatever Coolify generated for you. The --no-owner and --no-acl flags strip Railway-specific role information that doesn't apply on your new Postgres.
Sanity check the restore by counting rows on a known table. If the numbers match Railway, you're good.
Step 4, recreate each service as a Coolify application
For each Railway service, create a corresponding Coolify resource. Inside your project, click Add a new resource, pick Private Repository (with GitHub App), select your repo and branch.
For monorepo services where Railway had a "root directory" set, use Coolify's Base Directory field in the application's General tab. Set it to the subdirectory of your repo where the service lives (something like ./apps/web) and Coolify will run the build from there.
If your Railway service had a custom build command or start command, set those in the same General tab. Otherwise leave them blank and let Nixpacks auto-detect.
Now add environment variables. Open the Environment Variables tab, click Bulk Edit, paste the contents of your railway-env.txt for this service. Before saving, replace DATABASE_URL with the new internal URL pointing at your Coolify Postgres (format: postgresql://user:password@postgres-database-abc123:5432/dbname), do the same for REDIS_URL and audit the build vs runtime checkboxes on each line. Multi-line values should be runtime-only (uncheck Is build variable) to avoid Dockerfile parser issues.
Save. Repeat for each service. By the end you should have one Coolify resource per Railway service, each with its env vars correctly mapped.
Step 5, deploy and verify
Click Deploy on the first service. Watch the build logs in the Deployments tab. The first build is slowest, subsequent builds use the Docker layer cache.
If you get a build OOM (typically Next.js or other JS-heavy apps), add NODE_OPTIONS=--max-old-space-size=3072 as a build variable. The heap memory fix guide has the full breakdown.
Once the build succeeds, the container starts and Coolify's Traefik picks it up. Hit the default Coolify subdomain (visible in the application's General tab) and verify the app responds. Test the parts that depend on environment variables (database connections, third-party APIs, auth flows). Test background workers if you have them.
Repeat for each service in the project until they're all green.
Step 6, recreate Railway-specific behaviors
A few things Railway does for you that you'll set up explicitly on Coolify.
Cron jobs
If you used Railway's cron service, those become Coolify Scheduled Tasks inside the relevant application. Find the Scheduled Tasks section in the application's settings, add each cron with the same expression and command. Coolify wakes up the container at the scheduled time and runs the command.
Internal networking between services
On Railway, services in the same project could call each other using the internal hostname. The same is true on Coolify. The internal hostname is the resource name (the one Coolify shows in the application's General tab) and services reach each other on whatever port the target listens on, all without going through the public internet.
If you used Railway's private networking specifically (the RAILWAY_PRIVATE_DOMAIN variable), replace it with the internal hostname of the target Coolify service.
Volumes and persistent storage
Railway volumes become Coolify Storages in the application's settings. Add a persistent storage entry, give it a mount path inside the container (matching what Railway used) and a name. Coolify creates a Docker volume on the host and mounts it into the container. Data persists across deploys and container restarts.
For volume migration, if you had data on a Railway volume that you need to keep, the simplest path is to tar the data on the Railway side, transfer it to your VPS and untar into the new Coolify volume location on the host (usually under /var/lib/docker/volumes/).
Step 7, cut over DNS
In Coolify, go to your main service's Domains tab and add your real domain. Save. Now go to your DNS provider and replace the CNAME pointing at Railway with an A record pointing at your VPS IP. Lower the TTL to 60 or 300 seconds at least 24 hours before the cutover for fast propagation.
Coolify's Traefik issues a Let's Encrypt certificate within a minute or two of DNS resolving to your VPS. Watch the application's Logs tab for the ACME challenge result.
Keep Railway running for a week post-cutover as a fallback. You don't pay much for the overlap (Railway charges for actual usage) and it gives you a clean rollback if something explodes on the Coolify side that you can't fix in 30 minutes.
Step 8, verify you got everything
Before declaring victory, walk through this checklist with the new Coolify deploy as production:
- All services from the Railway project are running on Coolify (web, workers, schedulers, internal APIs)
- Database queries return correct data (count rows, spot-check recent records)
- Background jobs are processing (queue length stays flat or drops, not climbing)
- Cron jobs have run at least once (check logs after the first scheduled time)
- Custom domain serves over HTTPS with a valid Let's Encrypt cert
- Webhooks from external services hit the new URL (Stripe, GitHub, anything you wired up)
- Email sending still works (Mailgun, Postmark, SendGrid all just need the API key, but verify)
- OAuth providers point at the new domain (Google, GitHub, anything with an authorized redirect URL)
- Coolify backups are configured for your Postgres (the backups guide covers this)
If anything in that list fails, fix it before deleting the Railway project. The Railway side is your safety net.
Honest comparison post-migration
What you keep, the Git push deploy workflow, automatic SSL, easy database provisioning, scheduled tasks, custom domains, internal service-to-service networking. Coolify covers all of this and the patterns are basically the same.
What you give up, Railway's polish around the dashboard (Coolify's UI is functional but rougher), Railway's regional deploys (Coolify is one VPS, one location, you'd run multiple Coolify instances and put a global load balancer in front for multi-region), the metered model that scales to zero (Coolify is always-on so you pay flat regardless of traffic, which is good for steady traffic and bad for very bursty workloads).
What you gain, predictable monthly billing, no per-resource pricing weirdness, full root access to the underlying machine, the ability to host as many side projects as the VPS will hold without paying more.
For most teams running steady production traffic the math is good. For experimental side projects with intermittent traffic, Railway's metered model can actually be cheaper, so the "right" answer depends on usage shape.
If you're moving multiple services and need monitoring on the new setup, the Prometheus and Grafana on VPS guide covers a self-hosted monitoring stack you can run alongside Coolify. The Node.js production security guide covers the server hardening defaults that aren't on by default.
