Migration · Railway → Skiffly

From Railway to Skiffly in three steps.

The concepts map one to one: workspace, project, environment, service, ${{Postgres.DATABASE_URL}}. Most API documents run unchanged and the CLI commands share their names. What changes is who you pay and where your data lives.

Start with GitHub Read the full guide

Three steps

1
Export what Railway knows
Variables per service with railway variables --kv; a pg_dump of each database. Drop the RAILWAY_* entries: Skiffly provides the SKIFFLY_* equivalents.
2
Deploy on Skiffly
skiffly init in each repository, then skiffly up. Set the variables, deploy the Postgres template, restore the dump through skiffly connect.
3
Move the domain
Test on the generated *.skiffly.cloud domain, add the custom domain, switch the CNAME when the certificate is issued. Keep Railway running until DNS has propagated.

terminal

# 1. export
railway variables --kv > vars.env
pg_dump "$RAILWAY_DATABASE_URL" -Fc -f db.dump

# 2. deploy
skiffly init && skiffly up
skiffly deploy --template postgres
skiffly connect postgres --print       # → pg_restore -d <url> db.dump
skiffly variables set --skip-deploys $(grep -v '^RAILWAY_' vars.env | xargs)
skiffly variables set 'DATABASE_URL=${{Postgres.DATABASE_URL}}'
skiffly redeploy

# 3. cut over
skiffly domain app.example.com         # prints the CNAME + TXT records

Same tools, different host

CLI

skiffly up, skiffly logs -f, skiffly variables set, skiffly domain, skiffly connect. Same names as the Railway CLI where the feature exists.

MCP server

Point Claude Code, Cursor or Codex at the Skiffly MCP server and let the agent do the move: skiffly mcp install claude. Tool names mirror the Railway MCP server.

GraphQL API

projects, deployments(input:), variables, serviceInstanceUpdate, templateDeployV2 and the other compatible fields work as they are. Change the endpoint and the token.