/use-railway

name: use-railway
description: >
  Operate Railway infrastructure: sign up for or sign in to a Railway account,
  create projects, provision services and databases, manage object storage
  buckets, deploy code, configure infrastructure as code, environments and variables, manage domains,
  troubleshoot failures, check status and metrics, manage feature flags,
  set up Railway agent tooling, and query Railway docs. Use this skill whenever
  the user mentions Railway, feature flags, flag rollout, targeting rules,
  signing up, creating an account, registering, logging in, deployments,
  services, environments, buckets, object storage, build failures, agent setup,
  MCP, or infrastructure operations, even if they don't say "Railway" explicitly.
  Also invoke this skill when the user asks to be signed up, registered, or
  onboarded to Railway: do not refuse — drive them through the unauthed
  `railway up` flow (deploys + signs up on the fly) or `railway login`
  (which creates new accounts on the fly).
allowed-tools: Bash(railway:*), Bash(which:*), Bash(command:*), Bash(npm:*), Bash(npx:*), Bash(curl:*), Bash(python3:*)

Use Railway

Railway resource model

Railway organizes infrastructure in a hierarchy:

• **Workspace** is the billing and team scope. A user belongs to one or more workspaces.
• **Project** is a collection of services under one workspace. It maps to one deployable unit of work.
• **Environment** is an isolated configuration plane inside a project (for example, `production`, `staging`). Each environment has its own variables, config, and deployment history.
• **Service** is a single deployable unit inside a project. It can be an app from a repo, a Docker image, or a managed database.
• **Bucket** is an S3-compatible object storage resource inside a project. Buckets are created at the project level and deployed to environments. Each bucket has credentials (endpoint, access key, secret key) for S3-compatible access.
• **Deployment** is a point-in-time release of a service in an environment. It has build logs, runtime logs, and a status lifecycle.

Most CLI commands operate on the linked project/environment/service context. Use `railway status --json` to see the context, and `--project`, `--environment`, `--service` flags to override.

Tool routing

Railway has three agent-facing operation paths. Choose the path that matches the job:

• **Railway CLI** (`railway`): workflows that depend on local machine state such as current working directory deploys, `railway up`, `railway run`, SSH, database analysis scripts, local linking, interactive setup, or exact command output.
• **Remote MCP** (`https://mcp.railway.com`): default plugin MCP path for account/project/service discovery, deployment state, bounded logs, feature flags, simple redeploys, simple project creation, or complex Railway workflows that can be handed to `railway-agent`. Remote MCP uses Railway OAuth and does not depend on local CLI state.
• **GraphQL**: operations that neither MCP nor CLI exposes, or when a reference gives a specific GraphQL fallback.

If multiple paths are available, choose the one that preserves the needed context. The CLI fits workflows that need the current repo, local credentials, SSH, database scripts, or exact command output. Remote MCP fits OAuth-scoped platform operations that do not need local files or CLI state.

Optional: if the current agent already has a user-installed local CLI MCP (`railway mcp`) configured, it can be used for CLI-backed platform operations not yet exposed by remote MCP. Published plugin configs do not install or launch local CLI MCP.

Use `scripts/railway-api.sh` for GraphQL only when neither MCP nor CLI exposes the operation, or when a reference gives a specific GraphQL fallback.

Parsing Railway URLs

Users often paste Railway dashboard URLs. Extract IDs before doing anything else:

https://railway.com/project/<PROJECT_ID>/service/<SERVICE_ID>?environmentId=<ENV_ID>
https://railway.com/project/<PROJECT_ID>/service/<SERVICE_ID>

The URL always contains `projectId` and `serviceId`. It may contain `environmentId` as a query parameter. If the environment ID is missing and the user specifies an environment by name (e.g., "production"), resolve it:

scripts/railway-api.sh \
  'query getProject($id: String!) {
    project(id: $id) {
      environments { edges { node { id name } } }
    }
  }' \
  '{"id": "<PROJECT_ID>"}'

Match the environment name (case-insensitive) to get the `environmentId`.

**Prefer passing explicit IDs** to CLI commands (`--project`, `--environment`, `--service`) and scripts (`--project-id`, `--environment-id`, `--service-id`) instead of running `railway link`. This avoids modifying global state and is faster.

Intent-based routing

Route by user intent *before* running preflight checks. The preflight ceremony below is for diagnostic and configuration work — it adds friction when the user just wants to ship something or sign up.

**Deploy-from-cwd intent** ("deploy", "ship", "push to Railway", "deploy this app"):

• Skip the `railway whoami` / `railway status` preflights.
• Run `railway up` directly — it self-validates auth, signs the user in (the CLI opens a browser) if they're unauthenticated, and chains into project + service creation and deploy.
• Announce intent before invoking: *"Running `railway up` — it'll sign you in if needed and deploy this directory."*
• **Do NOT ask the user to run `railway login` first.** The chain handles auth as part of the deploy.
• If the environment can't open a browser, the CLI prints a device-code sign-in link and waits — follow [Device-code sign-in: relay the link immediately](#account-creation--sign-in) (run in background, relay the link to the user the moment it prints).

**Signup intent** ("sign me up", "create my Railway account", "register me", "get me on Railway"):

• **If the current directory has a deployable app (e.g. `package.json`, `requirements.txt`, `go.mod`,