Migrate from Railway to AZIN

Migrating from Railway to AZIN is one of the easier platform migrations you'll do. Both platforms use Railpack for builds — the same auto-detection, the same build logic. Your code doesn't change. The difference is where it runs: Railway's infrastructure, or your own GCP account.

A typical migration — web app, PostgreSQL database, a few environment variables — takes a couple of hours. Most of that time is waiting for database restore and DNS propagation, not reconfiguring your app.

#Before you start

Gather these before touching anything in AZIN:

• A GCP account. AZIN deploys to your own Google Cloud account via GKE Autopilot. If you don't have one, create a GCP account — new accounts get $300 in credits (as of March 2026). Startups may qualify for additional credits through the Google Cloud for Startups program.
• Railway CLI installed. You'll use it to export variables and database credentials. Install with npm i -g @railway/cli or brew install railway.
• Your Railway project linked. Run railway link in your repo directory to connect the CLI to your project.
• Database connection details. Find DATABASE_PUBLIC_URL in your Railway service variables. You'll need this for pg_dump.

#Export your Railway data

Start by pulling everything out of Railway. Environment variables first, then the database.

Environment variables

Railway's CLI can list your variables, but there's no single export-to-file command. The fastest path:

# Option 1: Copy from the Railway dashboard
# Go to your service → Variables → Raw Editor → copy all
 
# Option 2: Use the CLI to print variables
railway variables
 
# Option 3: Dump to a file via the CLI
railway variables | tee .env.railway

Review the exported file. Strip out Railway-injected variables — anything prefixed with RAILWAY_ (like RAILWAY_ENVIRONMENT, RAILWAY_PROJECT_ID, RAILWAY_SERVICE_NAME). Also remove DATABASE_URL, DATABASE_PUBLIC_URL, REDIS_URL, and PGHOST/PGPORT/PGUSER/PGPASSWORD — these will be replaced by AZIN's Cloud SQL connection strings.

PostgreSQL database

Export your Railway Postgres using pg_dump. Get the public connection URL from the database service's Variables panel in the Railway dashboard.

# Using the public DATABASE_URL from Railway
pg_dump "postgresql://postgres:PASSWORD@HOST:PORT/railway" \
  -Fc --no-acl --no-owner \
  -f railway-backup.dump
 
# Or use the Railway CLI to grab the URL directly
pg_dump "$(railway variables -s Postgres | grep DATABASE_PUBLIC_URL | cut -d= -f2-)" \
  -Fc --no-acl --no-owner \
  -f railway-backup.dump

The -Fc flag creates a custom-format dump that supports parallel restore and selective table import. For databases over 1 GB, add --jobs=4 to parallelize the dump.

Redis data (if applicable)

If you're using Railway's Redis, your cache and session data will repopulate naturally after migration. Redis is ephemeral by design. If you have persistent data in Redis (rate limit counters, queues with unprocessed jobs), drain your queues before cutting over or use redis-cli --rdb to snapshot the dataset.

#Set up AZIN

Connect your GCP account

In the AZIN Console:

• Click Connect GCP
• Run the provided setup command in Google Cloud Shell
• The script provisions a service account, VPC, and GKE Autopilot cluster in your account
• First GKE Autopilot cluster is free — you pay only for pod resources

This takes a few minutes the first time. Subsequent projects reuse the same cluster.

Connect your repository

AZIN deploys from GitHub. In the Console:

• Select your GitHub org and repository
• Choose your deploy branch (typically main)
• Railpack auto-detects your language and framework — identical to what Railway does

Since both platforms run Railpack, your project is detected the same way. If Railway built it successfully, AZIN will too. package.json, requirements.txt, Gemfile, go.mod, Dockerfile — all recognized.

Restore your database

Add a Database service in the AZIN Console. This provisions a Cloud SQL PostgreSQL instance inside your GCP VPC — managed backups, encryption at rest, high availability option.

# Get the Cloud SQL connection details from the AZIN Console
# Then restore the Railway dump:
pg_restore --verbose --clean --no-acl --no-owner \
  -d "postgresql://user:password@CLOUD_SQL_IP:5432/dbname" \
  railway-backup.dump

For large databases (10 GB+), use pg_restore --jobs=4 for parallel restore. Parallel restore reduces wait time on multi-core Cloud SQL instances.

Set environment variables

In the AZIN Console, navigate to your service's Variables panel. Paste your cleaned-up variables from .env.railway (minus the Railway-specific ones you stripped earlier).

Variables you'll update:

• DATABASE_URL — AZIN auto-injects this when you connect a Database service, but verify it points to your Cloud SQL instance
• REDIS_URL — updated if you added a Memorystore (Redis) Cache service
• PORT — Railpack handles this automatically, same as on Railway
• RAILWAY_* — delete all of these

Variables that transfer unchanged: SECRET_KEY, API_KEY, third-party service tokens (Stripe, SendGrid, Sentry, etc.), NODE_ENV, ALLOWED_HOSTS, and anything your application code reads directly.

#What changes between Railway and AZIN

Your code stays the same. The deployment model is nearly identical. But the infrastructure underneath is different, and that changes a few things.

The biggest practical difference: Railway manages your infrastructure on their Metal platform across 4 regions. AZIN deploys to GKE Autopilot inside your own GCP account. You get every GCP region, your own VPC, and direct access to Google's managed services. Cloud credits (like GCP for Startups) apply directly to your bill.

#DNS and custom domains

Add your custom domain in the AZIN Console under your Web Service settings. AZIN provisions a TLS certificate automatically.

Cutover strategy:

• Lower your DNS TTL to 60 seconds, 24-48 hours before migration
• Deploy and verify your app on AZIN's preview URL first
• Update DNS records to point to the AZIN-provided endpoint
• Monitor for 24 hours, then raise TTL back to your normal value

If something breaks after the switch, revert DNS to Railway. With a 60-second TTL, rollback takes about a minute.

#Running both in parallel

Don't do a hard cutover. The safer path: run Railway and AZIN simultaneously for a few days.

Deploy your app on AZIN, verify everything works against the preview URL, then switch DNS. Keep Railway running at Hobby tier ($5/mo, as of March 2026) for a week as a fallback. Your Railway database continues accepting connections even after you redirect traffic — useful if you need to roll back.

Once you're confident the AZIN deployment is stable:

# Remove your Railway project when ready
railway down
# Or scale to zero in the dashboard first, then delete after your comfort period

Railway doesn't charge for stopped services, but the project still counts against your service limits. Delete it when you're done.

#Common migration gotchas

Railway Functions

If you use Railway Functions (serverless endpoints on Bun runtime), these don't have a direct equivalent on AZIN. Convert them to a standard Web Service or Worker. In most cases this means wrapping the function handler in a lightweight HTTP server — Express, Fastify, or Flask depending on your stack.

Mono-repo root directories

Railway lets you set a root directory per service for mono-repos. AZIN handles this through the Console's service configuration — set the build context directory when configuring each service. Railpack detects the framework from whatever directory you point it at.

Private networking between services

Railway uses internal DNS (service-name.railway.internal) for service-to-service communication. On AZIN, services in the same project communicate through Kubernetes internal DNS within your GKE cluster. Update any hardcoded Railway internal URLs to use the AZIN service discovery pattern shown in the Console.

System dependencies

If Railpack auto-detection doesn't cover a system-level dependency your app needs (ImageMagick, FFmpeg, Chromium for Puppeteer), switch to a custom Dockerfile. AZIN supports any valid Dockerfile via BuildKit.

#Frequently asked questions

#Related pages

• AZIN vs Railway — Feature-by-feature comparison of both platforms
• Railway Alternative — Why developers switch from Railway to AZIN
• Best Railway Alternatives in 2026 — 6 platforms compared on pricing, DX, and BYOC
• What Is BYOC? — Why deploying to your own cloud account matters
• Deploy Docker with AZIN — Custom Dockerfile deployment for complex stacks
• Deploy Node.js with AZIN — Node.js deployment guide (common Railway stack)
• Host PostgreSQL with AZIN — Cloud SQL setup and database configuration

Information on this page was last verified on March 5, 2026 using Railway's public documentation and pricing pages. If anything is inaccurate, contact us and we'll correct it.

Railway is a registered trademark of Railway Corp. All product names and trademarks are the property of their respective owners. AZIN is not affiliated with or endorsed by the companies mentioned on this page.