deploy-to-railwaylisted

# Deploy a project to Railway (live, auto-deploying, secure) This is a **companion to the official `railway:use-railway` skill** — load that too; it owns the CLI/MCP mechanics (auth, `railway up`, logs, the GraphQL fallback). THIS skill is the opinionated end-to-end playbook + the gotcha list that the generic skill doesn't have. When they disagree, the generic skill wins on a command's exact flags; this skill wins on the *sequence and the traps*. ## The model (read once) - **Workspace** → billing scope. **Project** → one app + its DB(s). **Service** → one deployable (app, DB, or bucket). **Environment** → `production` etc. - Railway gives every service a **private** address (`<svc>.railway.internal`) and, on request, a **public** domain. Services in the same project reach each other over the private network — keep databases private. - **Reference variables** `${{ OtherService.VAR }}` are how you share credentials/values between services. Same-service self-refs work too: `${{ MY_OWN_VAR }}`. ## Decide the service topology FIRST | Project shape | Services to create | |---|---| | **Full-stack framework** (Next.js, Remix, SvelteKit, Rails, Django+templates) | **ONE** app service. The framework serves UI *and* API from one process. Do NOT split it — two services for one codebase is wrong and leaves a dead/broken half. | | **Truly separate FE + BE** (React/Vue SPA + a separate Node/Python/Go API) | **TWO** services from the same or two repos. FE gets the public domai