Railway MCP

DESTRUCTIVE: Commits all staged changes in a Railway environment and triggers a deploy. Only use this when the user has explicitly confirmed they want to deploy.

Attach a source to an existing service: a GitHub repository (deploys on push, builds immediately) or a Docker image. This is how a service that has never deployed gets its first deployment, and how an existing service's source is switched. Provide exactly one of repo or image. By default it applies to the service in all environments; pass staged: true with an environmentId to stage the source in that one environment's pending changes instead, in which case nothing builds until the staged changes are committed with accept-deploy.

Create an S3-compatible object storage bucket in a project and provision it in an environment. Default region is sjc. Pass staged: true to stage the bucket in the environment's pending changes instead of provisioning it live — it then only becomes real when the staged changes are committed with accept-deploy.

Create a new service from a GitHub repository and trigger its first deployment. The repo must be one the authenticated user has connected via GitHub. Returns the new service; use get-status or list-deployments to follow the deploy. Before calling this tool you MUST have a GitHub repo to deploy. If the user has not provided one, do not guess — first ask them which GitHub repo to deploy (in 'owner/name' form). If they don't have a repo yet, offer to help create one: if you have tools available to create a GitHub repository (e.g. a GitHub MCP server or `gh` CLI), offer to scaffold and push one for them; otherwise point them to create a repo on GitHub and share its 'owner/name'. Only call this tool once a concrete repo has been confirmed.

Create a new Railway project

Create a new service in a project from a Docker image, or an empty service to configure later (e.g. before setting variables and attaching a source). Pass staged: true to stage the service in one environment instead of applying it live — it then only becomes real when the staged changes are committed with accept-deploy. To create a service from a GitHub repository, use create-deployment instead.

Expose a service on the public internet over a raw TCP port (e.g. make a database reachable externally). Creates a TCP proxy forwarding a public endpoint to the given application port, applied through the environment config so the service redeploys with it active. Pass staged: true to stage the proxy in the environment's pending changes instead — it is only provisioned, and only gets a public endpoint, once the staged changes are committed with accept-deploy. A service can have at most one TCP proxy.

Create a persistent volume in a project and optionally attach it to a service at a mount path. The attach and redeploy are committed together so the service comes up with the mount applied. Pass staged: true to stage the volume in one environment instead of provisioning it live.

Permanently delete an object storage bucket and its contents. By default it is removed from every environment it is provisioned in; pass an environmentId to remove it from that one environment only. Pass staged: true to stage the removal in one environment instead of applying it live. Deleting from every environment is irreversible.

Delete a project-scoped feature flag. Workspace-scoped flags cannot be deleted from project context.

Permanently delete a service: its deployments stop and are removed, along with its domains, variables and deployment triggers. Any volume attached to it is detached and kept — delete-volume removes a volume and its data. By default the service is deleted in every environment that is not a fork; pass an environmentId to delete it in that one environment only. Pass staged: true to stage the removal in one environment instead of applying it live. A service whose creation is itself still staged is taken back out of the pending changes instead. This cannot be undone.

Remove a service's TCP proxy, taking its public endpoint offline. Anything connecting through that endpoint (e.g. external database clients) loses access. Pass staged: true to stage the removal in the environment's pending changes instead — that is also how a proxy that is itself only staged gets dropped again.

Permanently delete a volume and its data. The volume is unmounted from any service it is attached to (redeploying that service). By default it is removed from every environment; pass an environmentId to remove it from that one environment only. Pass staged: true to stage the removal in one environment instead of applying it live. Deleting from every environment is irreversible.

Inventory of everything in a Railway environment — services, volumes, buckets, shared variable names — with staged changes applied. Each resource carries a `state`: live, staged-create (exists only in the pending patch), staged-delete, or live-with-staged-changes. Includes each service's source, regions, replicas, cron, volume mounts and latest deployment, and a `staged` summary of the pending patch. Pass `region` to keep only resources in that region. For per-field staged diffs use get-staged-changes; for one service's full config use describe-service; for runtime health use environment-status. If environmentId is omitted, the production environment is used.

Everything about one service in an environment: its config with staged changes applied (source, build, deploy, networking, volume mounts), the per-field staged changes pending on it, mounted volumes, live domains and TCP proxies, and the latest deployment. `state` says whether the service is live, staged-create, staged-delete, or live-with-staged-changes. Variable names are listed but values are not — use list-variables for values. If environmentId is omitted, the production environment is used.

Get detailed status for one domain on a service, by hostname, URL, or domain ID: required DNS records and whether they currently match, ownership verification, certificate status, and any certificate error. Use list-domains first if you do not know which domains exist. If environmentId is omitted, the production environment is used.

Health overview of every service in an environment in one call: current LIVE (settled) deployment state, replica status, recent failures, unresolved warnings/criticals, and cron execution results. Does not include uncommitted staged patch work. By default only services with issues are returned — pass includeSuccessful to see everything. For error details, follow up with get-logs on the deployment IDs returned here.

Fetch the full markdown content of a Railway documentation page by URL or slug (e.g. 'https://docs.railway.com/quick-start' or 'reference/variables'). Use search-docs first to find the right page.

Expose a service publicly. Without `domain`, generates a Railway *.up.railway.app service domain (if the service already has domains, they are returned instead of creating another). With `domain`, attaches a custom domain you own and returns the DNS records the user must create for it to verify. If environmentId is omitted, the production environment is used.

Get the AI-generated diagnosis for a failed deployment: root cause category, analysis, and suggested fixes, along with deployment context (service config, source repo, branch, commit, PR, failure stage and error). Diagnoses run automatically when a deployment fails — if one isn't available yet, fall back to get-logs to inspect the failure directly.

Get a Railway feature flag (Signal) by name for a project or its parent workspace scope.

Get logs from Railway for a deployment — covers deploy (runtime), build, and http (proxy request) contexts. Pass a specific deploymentId, or pass serviceId + environmentId to resolve the latest deployment. Use `types` to choose which streams to return (default: ['deploy']).

Prefer describe-service: it applies the staged diff onto the live config for you and adds mounted volumes, domains, TCP proxies and the latest deployment. Get a service's configuration in an environment: source (repo/image), build settings, deploy settings (start command, healthcheck, replicas, cron, restart policy), networking, and volume mounts. `config` is what is live; `staged` holds the not-yet-deployed changes as a diff against it, or null when nothing is staged. A service created with `staged: true` has an empty `config` until accept-deploy commits it. Variable names are listed but values are not included — use list-variables for values. If environmentId is omitted, the production environment is used.

Get resource usage metrics (CPU, memory, disk, network) for a service, summarized as current/average/min/max over a time window. Defaults to CPU_USAGE and MEMORY_USAGE_GB over the last hour. If environmentId is omitted, the production environment is used.

Show the changes staged in a Railway environment that accept-deploy would commit: per resource (service, volume, bucket, group) the action — create, delete, update — and each changed field with its live and staged value. Variable values and registry credentials are redacted to names. Also reports whether the patch is destructive and whether a commit is already applying. Review this before calling accept-deploy. If environmentId is omitted, the production environment is used.

Prefer describe-environment: it also lists services that exist only in the staged patch, unattached volumes, and each resource's staged state. Get the deployment status of a Railway project environment. Returns project + environment metadata, whether the environment has undeployed staged changes, the environment's buckets, and for each live service its latest deployment status, replica count, cron schedule, and attached volumes. If environmentId is omitted, the project's `production` environment is used when present, otherwise the oldest environment.

Get the HTTP error rate for a service over time — the share of requests answered with a 5xx. Use this for reliability and to locate error spikes. 4xx responses are reported separately and are not counted in the rate, since a 404 or a rejected payload is usually the caller's doing. Defaults to the last hour. If environmentId is omitted, the production environment is used.

Get HTTP request counts for a service, bucketed over time and split by response status class (2xx/3xx/4xx/5xx). Use this for traffic volume and the mix of successful versus failing responses. Defaults to the last hour. If environmentId is omitted, the production environment is used.

Get HTTP latency percentiles (p50, p90, p95, p99) for a service, bucketed over time, in milliseconds. Use this for performance and to find slow requests. Defaults to the last hour. If environmentId is omitted, the production environment is used.

List recent deployments for a Railway project, optionally filtered by environment, service, or status. Returns the most recent first.

List all domains (Railway-generated service domains and custom domains) for a service in an environment. If environmentId is omitted, the production environment is used.

List Railway feature flags (Signals) for a project and optionally the parent workspace. Project flags are editable with admin access; workspace flags are read-only from project context.

List all Railway projects accessible to the authenticated user

List the ids and names of all services and environments in a Railway project. Prefer describe-environment for what is actually in an environment: it includes volumes, buckets, deployments and staged changes.

List the TCP proxies exposing a service over the public internet on a raw TCP port (e.g. a database's public endpoint). Returns the public endpoint (host:port) and the application port each proxy forwards to.

List all environment variables for a service, fully rendered (reference variables like ${{Postgres.DATABASE_URL}} are resolved). With a Railway session or API token, values are returned in plaintext and may contain secrets. Connected OAuth apps receive variable names only. Sealed variables are always listed by name with no value — they are set, but nobody can read them back, so never recreate one. If environmentId is omitted, the production environment is used.

List the Railway workspaces the current user belongs to. Use a workspace ID with create-project to choose where a project is created.

Send a message to Railway's AI agent for complex infrastructure operations. The agent can inspect services, diagnose issues, and take actions on your behalf.

Re-run the most recent deployment of a service in a given environment, reusing that deployment's existing build. Only works on a service that has already deployed in that environment — check with list-deployments if you are unsure. This does NOT give a service its first deployment: if it has never deployed, nothing here can deploy it — use the Railway CLI (`railway up --project <id> --environment <id> --service <id>`), or attach a GitHub repo to the service in the dashboard. create-deployment would build a separate new service from a GitHub repo rather than deploying this one.

Restart a service's running deployment in place — the containers restart without rebuilding the image, and no new deployment is created (use redeploy for a fresh build copy). Restarting causes brief downtime; do NOT restart database services (Postgres, MySQL, Redis, MongoDB) or services with attached volumes unless the user explicitly asked, as it can interrupt in-flight queries and transactions.

Search the Railway documentation (docs.railway.com) for features, configuration, guides, and tutorials. Returns matching sections with URLs — use fetch-docs to read a full page.

Create a project-scoped feature flag or update its default value. Use list-feature-flags and get-feature-flag to inspect existing flags first.

Set one or more environment variables on a service (or environment-wide shared variables when serviceId is omitted). Existing variables with the same name are overwritten; others are left unchanged. Reference syntax like ${{Postgres.DATABASE_URL}} is supported. Affected services are redeployed unless skipDeploys is true. Pass staged: true to stage the variables in the environment's pending changes instead of setting them live — nothing is written or redeployed until the staged changes are committed with accept-deploy.

Update a service's configuration: build/start/pre-deploy commands, healthcheck, sleep mode, root directory, cron schedule, Dockerfile path, restart policy, config file path, and watch patterns. Only the fields you pass are changed. Changes apply on the service's next deployment (use redeploy to apply immediately). Pass staged: true to stage the update in one environment's pending changes instead of writing it to the service — it then applies when the staged changes are committed with accept-deploy. Scaling (replicas/regions) and source changes are not handled by this tool.

Update a volume's name and/or mount path. A mount path change redeploys the affected service so the new mount takes effect. Only the fields you pass are changed. Pass staged: true with an environmentId to stage the mount change in that environment's pending changes instead of applying it live; the volume's name is not environment-scoped and cannot be staged.

Get the current authenticated Railway user's profile information