Migrate from Railway to Laravel Cloud
On Railway, a Laravel app runs as four services you wire together: web, worker, cron, and database. Laravel Cloud runs it as one application, with queues, the scheduler, and autoscaling built in. This guide walks you through moving your Laravel application from Railway to Cloud.
Why migrate from Railway to Laravel Cloud?
One application, not four services: Railway splits your Laravel app into web, worker, cron, and database services, each with its own scripts and variables. On Cloud, your app, queues, and scheduler live in one place.
Autoscaling on real traffic: Cloud adds and removes replicas based on live traffic, CPU, and memory, on Growth and above. On Railway, you set replica counts by hand.
Managed queues: Queue workers scale up when jobs pile up and scale to zero when the queue is empty on Flex compute. You get a jobs dashboard and failed-job retries, with no worker service to size.
Scheduler included, no Cron service: One toggle runs Laravel's scheduler every minute on your app compute. There's no run-cron.sh script or extra service to maintain.
Jobs finish during deploys: Managed queue workers get up to 90 seconds (Flex) or one hour (Pro) to finish the current job before a new release takes over.
Full-stack scale to zero: Compute, databases, and cache sleep when idle and wake together in under 500 ms.
Standard Laravel apps can migrate in as little as 30 minutes.
For a full side-by-side, see Laravel Cloud vs. Railway.
“All feedback I have is positive! We move our production apps to Laravel Cloud as it is safe and very comfortable. Laravel framework became the first choice for new projects and Laravel Cloud is one of the reasons.”
Marcin Kw
Developer
Prerequisites
- Access to your Railway project and its database service
- Git repository connected to a supported provider (GitHub, GitLab, Bitbucket)
- Database credentials for your Railway Postgres or MySQL database
- The Railway CLI, if you want to export variables or volume files from the command line
- DNS management access for your domain
- A Laravel Cloud account
Railway to Laravel Cloud: Migration steps
Set up Laravel Cloud account
Create your Cloud account and set up your organization. Have questions? Check our Laravel Cloud Quickstart documentation.
Create your new application
- From your Laravel Cloud dashboard, click + New application.
- Connect your Git provider (GitHub, GitLab, or Bitbucket).
- Select your repository and branch.
- Configure your environment settings:
- Choose PHP version from the list of supported versions.
- Set environment variables (see Prepare to migrate for what to copy and what to leave behind).
- Add any secrets your application needs.
Provision your new infrastructure
Create the resources your application needs:
Laravel MySQL or Serverless Postgres database
- In your environment's infrastructure canvas, Add a database.
- Choose MySQL or Serverless Postgres (match your Railway database). AWS RDS databases for MySQL and Postgres are also available on Laravel Private Cloud.
- Select compute size based on your needs.
- Enable a public endpoint for migration (you can disable it after).
- Laravel Cloud automatically configures Laravel environment variables.
KV store for cache and session storage
- Add Redis-compatible Laravel Valkey to your infrastructure canvas. Fully managed AWS ElastiCache caches (both Valkey and Redis OSS) are also available in Laravel Private Cloud.
- Laravel Cloud automatically configures your environment variables.
Object storage (S3-compatible)
- Add object storage if you use file uploads, a Railway volume, or a Railway Storage Bucket.
- Install the package Laravel needs to use it: composer require league/flysystem-aws-s3-v3.
- Cloud injects FILESYSTEM_DISK and the bucket credentials for you.
Queues and scheduler
- Click Add compute, then Managed queue. This replaces your Railway Worker service.
- Click your App cluster in the infrastructure canvas and turn on the Scheduler toggle. This replaces your Railway Cron service.
You've now set up a new Laravel Cloud account and provisioned all necessary infrastructure. You can now migrate your Railway application to Laravel Cloud.
Prepare to migrate
- Log into your Railway account.
- Get your Railway database credentials:
- Open your database service → Variables. Copy DATABASE_PUBLIC_URL (Postgres) or MYSQL_PUBLIC_URL (MySQL).
- If you don't see a public URL, go to the database service → Settings → Networking and add public access. Railway creates a TCP proxy and fills in the variable.
- Export your app's environment variables:
- Run railway variables list --kv -s <your-app-service> to print them as KEY=VALUE lines.
- Copy your app-specific values (API keys, mail settings, APP_KEY, and so on) into Cloud.
- Leave these behind: DB_URL, DATABASE_URL, REDIS_URL, any ${{Service.VAR}} reference, and any RAILWAY_* variable. Cloud injects its own database and cache credentials, and a leftover DB_URL would point your app back at Railway.
- Don't copy QUEUE_CONNECTION=database. Cloud sets QUEUE_CONNECTION=cloud for managed queues, and custom variables take priority over injected ones. If you use Horizon, keep your Redis queue settings instead (see the Code changes required section).
- Keep DB_CONNECTION (pgsql or mysql). Cloud doesn't list it among the variables it injects, and newer Laravel apps fall back to SQLite without it.
- If SESSION_DRIVER or CACHE_STORE is set to file, change it to database or redis. Cloud's filesystem resets on every deploy.
Migrate your database
With your new Laravel Cloud database provisioned and public endpoint enabled:
Finding your Laravel Cloud database credentials:
- Cloud dashboard → Environment → Database → View credentials
- Credentials are also injected as environment variables
Check your versions first. Run SELECT version(); on your Railway database. New Railway databases run Postgres 18 and MySQL 9. Laravel Cloud runs Postgres 17 and 18, and MySQL 8.4. Use a pg_dump client at least as new as your Postgres server.
For Postgres
Export from Railway
Railway bills TCP proxy traffic as network egress. If you dump a large database often, Railway recommends a tunnel instead: run railway connect postgres --tunnel-only, then point pg_dump at localhost and the port the CLI prints.
Import to Laravel Cloud
# From your local machine
pg_restore \
--clean \
--no-owner \
--no-acl \
--if-exists \
--dbname="postgresql://cloud-db-username:cloud-db-password@cloud-db-host:cloud-db-port/cloud-db-database" \
"dump-file.bak"For MySQL
Export from Railway
# From your local machine
mysqldump \
--host="railway-db-host" \
--port="railway-db-port" \
--user="railway-db-username" \
--password="railway-db-password" \
--single-transaction \
--set-gtid-purged=OFF \
--routines \
--triggers \
--events \
"railway-db-database" > "dump-file.sql"Find the host, port, user, password, and database name in your MYSQL_PUBLIC_URL.
Import to Laravel Cloud
# From your local machine
mysql \
--host="cloud-db-host" \
--port="cloud-db-port" \
--user="cloud-db-username" \
--password="cloud-db-password" \
"cloud-db-database" < "dump-file.sql"On smaller Laravel Cloud MySQL instances, add --skip-extended-insert to the export to reduce memory use during import. For large databases, see the Laravel MySQL import notes.
Move your files (if you use a volume or bucket)
Cloud's filesystem resets on every deploy, so uploads belong in object storage.
- Railway volume: download the files with railway volume files download <remote-path> <local-path>, then upload them to your Cloud bucket.
- Railway Storage Bucket: both are S3-compatible, so you can copy objects bucket to bucket.
See Migrating object storage to Laravel Cloud for tools and commands.
At this point, you are ready to deploy your application to Laravel Cloud by hitting the Deploy button. Follow the next steps to test whether everything is working correctly.
Test your Laravel Cloud deployment
Before switching DNS:
- Deploy your application: Click the Deploy button in Laravel Cloud.
- Verify deployment: Check the deployment logs for any errors.
- Test using Laravel Cloud URL: Every environment gets a .laravel.cloud URL.
- Run smoke tests: Verify critical functionality works.
- Check background jobs: Ensure queues are processing correctly.
- Check scheduled tasks: Confirm your scheduled commands run on time.
Switch DNS to Laravel Cloud
Once verified, point your domain to Laravel Cloud:
- In the Laravel Cloud dashboard, go to Domains and add your custom domain.
- Laravel Cloud will provide DNS records (A/CNAME).
- Update your DNS provider with the new records. Replace Railway's CNAME, and remove the TXT verification record Railway asked you to add.
- SSL certificates are automatically provisioned and renewed.
Avoid downtime: Before you change your A or CNAME record, add the pre-verification TXT records that Cloud shows. This issues your SSL certificate before traffic moves. See custom domains.
Disable public database endpoint (optional)
After migration is complete and stable:
- Disable the public endpoint on your Laravel Cloud database for security.
- Your application will continue to access it via private network.
End your Railway subscription
Once you've successfully deployed and tested your application, delete the Railway services you no longer need. Delete volumes and buckets too. According to a reply on Railway's community forum, they keep billing for storage even while stopped.
Common migration scenarios
Scenario 1: Standard Laravel app
Railway setup: App + Worker + Cron + Postgres services
Laravel Cloud setup: One application with Postgres + managed queues + the Scheduler toggle
Estimated migration time: 30-60 minutes
Scenario 2: API-only application
Railway setup: App service + MySQL or Postgres + Redis
Laravel Cloud setup: MySQL or Postgres database + Valkey
Estimated migration time: 20-40 minutes
Scenario 3: Multi-environment setup
Railway setup: Production + staging environments in one project
Laravel Cloud setup: Create separate environments in the same application
Estimated migration time: 45-90 minutes per environment
Scenario 4: App with uploads on a volume
Railway setup: App service with a volume mounted for storage/app
Laravel Cloud setup: Object storage, with files copied over before cutover
Estimated migration time: 45-90 minutes, plus file transfer time
Code changes required
Minimal changes needed
Most Laravel applications need only small changes to move from Railway to Laravel Cloud. Most of the work is deleting Railway-specific files.
Remove Railway-specific files
You can delete the scripts from Railway's Laravel guide:
- railway/init-app.sh (pre-deploy: migrations and caching)
- railway/run-worker.sh (Worker start command)
- railway/run-cron.sh (Cron start command)
Also remove railway.json or railway.toml if your project has one.
Move your build and deploy steps
Put the work your Railway scripts did into your environment's Deployments settings:
# Build commands
composer install --no-dev
npm ci --audit false
npm run build
php artisan optimize# Deploy commands
php artisan migrate --forceDon't carry over optimize:clear from init-app.sh. Laravel Cloud recommends against it, along with queue:restart and storage:link.
Queue configuration
Managed queues need Laravel 11.55.0, 12.63.0, 13.19.0, or newer and the AWS SDK package:
composer require aws/aws-sdk-phpLaravel Cloud sets QUEUE_CONNECTION=cloud, so jobs you used to push to the database queue go to the managed queue. Let your Railway worker finish any pending jobs before you switch DNS.
Using Horizon? Managed queues don't support Horizon. Instead, keep your Redis connection and run php artisan horizon as a background process on your App cluster or a worker cluster. Don't add horizon:terminate to your deploy commands. Cloud handles it.
Scheduler configuration
On Railway, the Cron service runs your scheduler on a single instance, so each task fires once. On Laravel Cloud, your scheduler can run across multiple replicas when your app scales, meaning it could fire on every one of them.
Before you deploy, review your routes/console.php (or app/Console/Kernel.php) and add ->onOneServer() to any task that should only run once per schedule, such as reports, cleanup jobs, or anything that writes to your database or sends notifications.
use Illuminate\Support\Facades\Schedule;
Schedule::command('reports:generate')
->daily()
->onOneServer();This uses your cache to coordinate between instances, so make sure you have a KV store provisioned. For more details, see the Laravel scheduler documentation.
Storage configuration
If you stored uploads on a Railway volume, switch to Cloud object storage. Cloud's filesystem is ephemeral, and each replica has its own.
composer require league/flysystem-aws-s3-v3Use --with-all-dependencies if Composer reports a conflict. Cloud injects the bucket credentials and FILESYSTEM_DISK for you. If your bucket is public, copy AWS_URL from the bucket settings page into your environment variables, since Cloud doesn't inject it. Don't set visibility: 'public' in your disk config.
The same applies to sessions and cache: if they use the file driver, switch to database or redis.
Rollback plan
Before migrating production:
- Keep Railway running until Laravel Cloud is fully validated.
- Parallel run: Test Laravel Cloud with real traffic using the Cloud URL.
- Database sync: If needed, you can sync databases before final cutover.
- DNS rollback: Keep old DNS records documented for quick rollback.
Post-migration validation
After successful migration:
1. Configure autoscaling
Set appropriate min/max replicas based on your traffic patterns.
2. Enable scale to zero
For staging and low traffic environments so you pay nothing when they are idle.
3. Check managed queues
Use the jobs dashboard to watch job volume, duration, and failed jobs.
4. Monitor performance
Use Laravel Cloud's built-in metrics to optimize compute resources.
5. Review costs
Compare your Laravel Cloud usage costs to previous Railway bills.
Your Railway to Laravel Cloud migration is now complete!
Migrating from Railway to Laravel Cloud turns four services into one application, with queues, the scheduler, and autoscaling handled for you.
With zero-config environments, autoscaling, and a straightforward infrastructure model, most applications can be migrated in under an hour.
By following the steps in this guide, you can transition smoothly and start taking advantage of Laravel Cloud.
Why migrate from Railway to Laravel Cloud?
“We ran our own Kubernetes cluster. That was a full-time job for two people. It really took a lot of your energy. It's great to have people who are absolute experts on this.”
Alex Millar
Co-founder at GovAI
Frequently asked questions
Most applications can be migrated in under an hour. Complex apps may take 2-4 hours.
No. Keep Railway running while you set up Laravel Cloud, then switch DNS when ready.
Very little. You can delete Railway's scripts and config files, add the AWS SDK package for managed queues, and add ->onOneServer() to scheduled tasks that should run once. See the Code changes required section.
You don't need them. Managed queues replace the Worker service, and the Scheduler toggle replaces the Cron service. The scheduler runs every minute, with no script or extra service to maintain.
Laravel's scheduler runs on Cloud without any infrastructure setup, but there's one behavior change to know about. On Railway, the Cron service runs the scheduler on a single instance. On Cloud, if your app scales to multiple replicas, the scheduler runs on each one by default. Add ->onOneServer() to any task that should only fire once per schedule to prevent duplicate runs.
Run railway variables list --kv to export them, then add your app-specific values in your environment's settings on Laravel Cloud. Cloud automatically injects credentials for any attached resources (database, cache, object storage), so leave out DB_URL, DATABASE_URL, REDIS_URL, Railway reference variables like ${{Postgres.DATABASE_URL}}, and QUEUE_CONNECTION. Keep DB_CONNECTION. Redeploy after saving.
Download them with railway volume files download and upload them to Laravel Cloud object storage. Cloud's filesystem resets on each deploy, so uploads need to live in object storage.
Yes. Laravel Cloud also runs Node.js, Bun, and Deno apps (Next.js, Nuxt, Express, Hono), Python (Django, FastAPI, Flask), Ruby on Rails, Go, and Rust. The database export, file transfer, and DNS steps in this guide work the same way. Build commands, environment variables, and background jobs differ by framework, so follow the deploy guide for your runtime. Managed queues and the Scheduler toggle are built for Laravel and Symfony. Other apps run background jobs and scheduled tasks on worker clusters.
Delete your Railway services, volumes, and buckets once migration is complete and validated. Volumes and buckets keep billing for storage while stopped, so delete them to stop all charges.