Migrating from Railway
Railway and Doable are close peers, both deploy containers, both auto-detect runtimes. The differences are pricing (Railway is usage-based, Doable is flat $0/$15/$39 per month), AI-tool integration (Doable ships an MCP server for Claude Code), and BYO server support (Doable supports them, Railway doesn't).
Migration is mechanical: most Railway projects deploy on Doable without any code changes.
Pull the variables for the service you're migrating into a local file.
railway variables --json > .env.railway.jsonDoable's `env import` reads `.env`-style files. Quick conversion:
node -e "const j=require('./.env.railway.json'); for(const k in j) console.log(k+'='+JSON.stringify(j[k]))" > .env.doableOne-time setup.
npm install -g doable-cli && doable loginDoable's runtime detection mirrors Nixpacks for Node, Python, and Docker.
doable projects createEncrypted at rest, injected at container start.
doable env import .env.doableFor Railway Postgres: `pg_dump` from Railway, restore into Neon (or Supabase, Upstash), then `doable addon attach postgres <new-url>`. Doable doesn't provision Postgres on its own infrastructure but attaches any external URL.
First deploy hits a cold cache. Subsequent deploys reuse layers.
doable deployRuntime detection: Doable picks up Node, Python, static sites, and Dockerfiles the same way Railway's Nixpacks does. If your Railway project deployed without a custom config, it'll deploy on Doable without one too.
Container shape: both run your code as a single container behind a reverse proxy with HTTPS. Background workers deploy as separate projects with no public port, same pattern on both platforms.
Env vars: encrypted at rest, injected as environment variables at container start. The mental model is identical.
Pricing: Railway is pay-as-you-go ($5/mo subscription + per-resource usage). Doable is flat ($0/$15/$39 per month). For predictable workloads, Doable usually wins; for very bursty workloads, Railway can be cheaper. Run the math on your last 3 months of Railway bills before switching.
Databases: Railway provisions Postgres / MySQL / Redis / Mongo on its own infrastructure. Doable doesn't, it attaches external providers (Neon, Supabase, Upstash, Atlas) via `addon attach`. The advantage of the Doable approach: those services run on accounts independent of your deploy platform.
AI-tool integration: Doable ships a first-class MCP server. `/deploy` works inside Claude Code, Codex, Cursor, Railway is CLI-only.
BYO servers: Doable supports them (free, unlimited). Railway requires their infrastructure.
Yes if it's a standard runtime (Node, Python, Go, Ruby, static). Doable's detector reads the same files Nixpacks does. If you've customised the build heavily with Nixpacks config, you may need to add a Dockerfile to Doable, usually a 5-line wrap.
Migrate to Neon, Supabase, or Upstash. `pg_dump` from Railway, restore to the new provider, then `doable addon attach postgres <new-url>`. Total time is usually 5–15 minutes for databases under a few GB.
For predictable workloads, almost always, Doable's flat $15/month covers 3 projects with no usage metering. For bursty short-burst workloads, Railway's pay-as-you-go model can be cheaper. Compare your last 3 Railway bills against $15 or $39.
Not yet, Doable treats each project as its own deploy. Multi-service apps deploy as multiple Doable projects sharing the same database via `addon attach`. The dashboard is simpler; the trade-off is no built-in service-graph view.
No credit card. Deploy your first project in under a minute.