The Railway MCP for teams that automate deploys
Connect Railway once and your projects, environments, services, deployments, variables, domains, and volumes become building blocks for visual automations and AI agent workflows. 68 nodes over Railway's GraphQL API, including a catch-all node for any other operation in the schema.
What the Railway MCP connector does
The Railway connector for Mattering Automations covers the operations Railway publishes on its public API: list and create projects, manage environments including ephemeral preview environments, create and configure services, trigger deploys, redeploys, rollbacks, restarts, and cancellations, read build, runtime, and HTTP logs, set and read environment variables, attach Railway and custom domains, and manage volumes and volume backups. That is 68 nodes in total: 28 read nodes and 40 action nodes.
Railway has no REST API. Its public API is a single GraphQL endpoint at backboard.railway.com/graphql/v2, the same API that powers the Railway dashboard, so every node here is a named GraphQL operation with a fixed document behind it. You fill in ordinary canvas fields such as a project id or a service id, the node maps them onto the operation's variables, and you never have to write GraphQL to use the typed nodes.
Each capability is a node on the Automations canvas, and every node speaks MCP, the open protocol for connecting AI assistants to tools. Claude, ChatGPT, and any MCP-capable assistant can use them, and they also power Matter, the platform's built-in AI assistant. Describe the deployment workflow you want in plain language and it gets built on the canvas in front of you, where you can see every step and change it.
Past the typed nodes there is an advanced escape hatch: Railway: Custom GraphQL Request runs any Railway GraphQL operation with your own document and variables. Railway supports schema introspection, so anything in the schema stays reachable without waiting on a connector update.
One connection, three surfaces
- Visual automations. Drag Railway nodes onto the canvas and wire them to triggers, conditions, and other apps.
- AI agents, yours or ours. These nodes speak MCP, the open protocol, so Claude, ChatGPT, and any MCP-capable assistant can use them, and Matter, the agent built into the platform, uses them natively.
- The whole platform. Combine with native tasks, projects, and other connectors, no middleware in between.
Every Railway node, ready to drop on the canvas
68 nodes, generated from the connector itself so this list always matches what ships. Expand a category to browse.
Read and query nodes 28
Railway: Check Custom Domain Availability
Check whether a hostname can be attached to a Railway service before creating it.
Railway: Get Build Logs
Read the build-phase logs for a deployment. The first place to look when a deploy fails to build.
Railway: Get Current User
Get the Railway account the API token belongs to (id, name, email). The cheapest auth/connectivity probe.
Railway: Get Custom Domain Status
Poll a custom domain's DNS propagation and TLS certificate status.
Railway: Get Deployment
Get one deployment's status, URLs, build metadata, and whether it can be redeployed or rolled back.
Railway: Get Deployment Logs
Read the runtime (application) logs for a deployment.
Railway: Get Deployment Variables
Read the fully rendered variable set a service deployment actually receives (shared + service variables, references resolved). WARNING: values are secrets.
Railway: Get Environment
Get one environment with each service instance in it and that instance's latest deployment status.
Railway: Get Environment Logs
Read aggregated logs across every service in an environment, optionally filtered.
Railway: Get HTTP Logs
Read the edge HTTP request log for a deployment (method, path, status, duration, source IP).
Railway: Get Project
Get one project with its services and environments. The usual way to resolve service ids and environment ids from a project id.
Railway: Get Service
Get a service's project-level record (name, icon, owning project).
Railway: Get Service Instance
Get a service's per-environment settings (start/build command, region, replicas, restart policy) plus its latest deployment.
Railway: Get Service Resource Limits
Get the CPU/memory limits configured for a service instance. Returns a JSON blob.
Railway: Get Staged Changes
Read the staged (uncommitted) configuration changes on an environment. Returns a JSON blob.
Railway: Get Variables
Read environment variables as a flat name/value JSON object. Omit service_id for shared (environment-level) variables. WARNING: values are secrets. Do not log or forward the output.
Railway: Get Volume Instance
Get a volume instance's mount path, current size, and state. The node to poll for disk-usage alerting.
Railway: Get Workspace
Get one workspace with its members and their roles.
Railway: List Deployments
List deployments for a project, optionally narrowed to one service/environment. Set first=1 with successful_only=true to get the current live deployment.
Railway: List Domains
List a service's Railway-provided domains and custom domains, including custom-domain DNS verification records.
Railway: List Environments
List a project's environments. Set is_ephemeral=false to exclude PR/preview environments.
Railway: List Project Members
List the members of a project with their roles.
Railway: List Project Volumes
List the persistent volumes attached to a project.
Railway: List Projects
List projects the token can see. Optionally scope to one workspace. Relay shape: results are under data.projects.edges[].node.
Railway: List TCP Proxies
List the TCP proxies exposing a service instance (used for databases and other non-HTTP services).
Railway: List Volume Backup Schedules
List the automatic backup schedules configured on a volume instance.
Railway: List Volume Backups
List the backups taken of a volume instance.
Railway: List Workspaces
List the workspaces (personal + team) the token can access. Workspace ids scope Railway: List Projects and project creation.
Action nodes 40
Railway: Add Custom Domain
Attach a custom domain to a service. Returns the DNS records that must be created before Railway will serve traffic.
Railway: Cancel Deployment
Cancel a deployment that is still building or deploying.
Railway: Commit Staged Changes
Apply an environment's staged configuration changes, triggering redeploys where needed.
Railway: Connect Service to Repo
Connect a service to a GitHub repo (or a Docker image) as its deploy source.
Railway: Create Environment
Create an environment in a project, optionally cloned from an existing environment.
Railway: Create Project
Create a new Railway project.
Railway: Create Railway Domain
Generate a Railway-managed *.up.railway.app domain for a service instance.
Railway: Create Service
Create a service in a project from a GitHub repo or a Docker image.
Railway: Create Volume
Create a persistent volume and mount it into a service.
Railway: Create Volume Backup
Take an on-demand backup of a volume instance.
Railway: Custom GraphQL Request
Send any GraphQL query or mutation to Railway's API with your own variables. Covers every operation not individually typed (introspect the schema at railway.com/graphiql).
Railway: Delete Custom Domain
Detach a custom domain from its service. Traffic to that hostname stops being served.
Railway: Delete Environment
Delete an environment and every service instance, variable, and volume instance in it. Destructive.
Railway: Delete Project
Permanently delete a project and everything in it. Destructive and irreversible.
Railway: Delete Railway Domain
Remove a Railway-managed service domain.
Railway: Delete Service
Delete a service from its project. Destructive and irreversible.
Railway: Delete Variable
Delete a single environment variable.
Railway: Delete Volume
Delete a volume and all data stored on it. Destructive and irreversible.
Railway: Delete Volume Backup
Delete a volume backup. Destructive and irreversible.
Railway: Deploy Service
Trigger a new deployment of a service in an environment, optionally pinned to a specific commit SHA. Returns the new deployment id.
Railway: Disconnect Service Source
Disconnect a service from its GitHub repo / image source.
Railway: Lock Volume Backup
Lock a backup so retention policy will not expire it.
Railway: Redeploy Deployment
Redeploy a specific past deployment by id.
Railway: Redeploy Service
Redeploy a service instance's current deployment (same code, fresh container).
Railway: Remove Deployment
Remove a deployment record and its resources. Destructive.
Railway: Rename Environment
Rename an environment.
Railway: Rename Volume
Rename a volume.
Railway: Restart Deployment
Restart a running deployment's containers without rebuilding.
Railway: Restore Volume Backup
Restore a volume instance from one of its backups. Overwrites current volume data.
Railway: Rollback Deployment
Roll the service back to this deployment. Use with Railway: List Deployments (successful_only) to pick the last known-good build.
Railway: Set Variable
Create or update a single environment variable. Omit service_id to set a shared environment variable. Triggers a redeploy unless skip_deploys is true.
Railway: Set Variables (Bulk)
Create or update many variables in one call from a flat JSON object. Set replace=true to make the supplied set authoritative (removes anything not listed).
Railway: Stop Deployment
Stop a running deployment. The service goes offline until it is redeployed.
Railway: Transfer Project
Transfer a project to another workspace.
Railway: Trigger Environment Deploy
Fire an environment's deploy triggers. The API equivalent of pressing Deploy in the Railway dashboard.
Railway: Update Custom Domain
Change the container port a custom domain routes to.
Railway: Update Project
Update a project's name, description, visibility, or PR-deploy setting.
Railway: Update Service
Rename a service or change its icon.
Railway: Update Service Settings
Update a service's per-environment settings: start/build command, root directory, healthcheck, region, replicas, restart policy, cron schedule, Dockerfile path.
Railway: Update Volume Mount Path
Change the path a volume is mounted at inside the container. Triggers a redeploy of the attached service.
Connecting Railway takes one credential
Railway authenticates with an account or workspace API token, sent as an Authorization Bearer header. Create one on your Railway account tokens page at railway.com/account/tokens. An account token reaches every resource your account can see across workspaces; a workspace token stays scoped to a single workspace. Railway project tokens are sent in a different header and are not supported by this connector.
In Railway, open railway.com/account/tokens and create a token. Leave it unscoped for an account token, or select a workspace to scope it to that workspace.
Copy the token and keep it somewhere safe until you have pasted it into Mattering.
In Mattering Automations, open Connectors, click Add Connector, and choose Railway.
Create a new credential, paste the token, and save. Credentials are stored encrypted in Google Secret Manager and never appear in workflow logs.
Connect the connector, then drop Railway: Get Current User onto a canvas and run it. It takes no arguments and returns the account the token belongs to, which confirms the credential works. All 68 Railway nodes are now in your palette.
Common uses for the Railway MCP
Ship a deploy from a workflow or a chat message
Trigger a deployment on a schedule, after a release checklist closes, or on an agent's instruction. Railway: Deploy Service can pin the deploy to a specific commit SHA, and Railway: Trigger Environment Deploy fires an environment's deploy triggers the way pressing deploy in the dashboard does.
Roll back automatically when a deploy fails
Poll the latest deployment, branch on its status, and call Railway: Rollback Deployment against the last known-good build. Railway: List Deployments with successful_only finds that build, so the recovery path does not depend on anyone being awake.
Triage incidents with logs already attached
Pull build, runtime, HTTP, or environment-wide logs the moment something fails, hand them to an AI step for a summary, and post the result to a task or a channel so the person who picks it up starts with the evidence rather than a link.
Spin preview environments up and down
Create an environment cloned from production when a branch or ticket opens, set its variables, deploy the service, and delete the environment when the work merges, so review environments stop outliving the work they were built for.
Roll environment variables out across environments
Set one variable with Railway: Set Variable or push a whole set with Railway: Set Variables (Bulk), scoped to a service or shared across an environment, with the option to skip the automatic redeploy until every value is in place.
Watch volumes and keep backups honest
Poll a volume instance for its current size and raise an alert before a disk fills, take an on-demand backup before a risky migration, and lock the backups you want retention policy to leave alone.
Example: A failed deploy rolls itself back and opens a task
Built on the Automations canvas in a few minutes, or described in plain language to Matter and built for you.
Trigger: a schedule runs every few minutes, or a release workflow finishes its previous step.
Railway: List Deployments returns the most recent deployment for the service and environment.
Railway: Get Deployment reads its status, and a condition node branches when the deployment failed.
Railway: Get Build Logs pulls the build output so the failure reason travels with the alert.
Railway: Rollback Deployment restores the last successful deployment, found by running Railway: List Deployments with successful_only.
Mattering Productivity: a task is created with the service name, the failed deployment id, and the log excerpt, so the fix has an owner instead of a Slack thread.
Railway MCP questions, answered
Can an AI agent deploy, redeploy, or roll back a Railway service?
Yes. Railway: Deploy Service triggers a new deployment, optionally pinned to a commit SHA, and Railway: Redeploy Service, Railway: Restart Deployment, Railway: Rollback Deployment, and Railway: Cancel Deployment cover the rest of the deployment lifecycle. Matter and any MCP-connected assistant can call them, and so can a scheduled or event-driven workflow on the canvas. Deploys consume real compute on your Railway plan, so it is worth putting a condition or an approval step in front of the ones that matter.
Does this work with Claude, ChatGPT, or other AI assistants?
Yes. Mattering exposes these nodes over MCP, an open protocol for connecting AI assistants to tools, so any MCP-capable assistant, including Claude and ChatGPT, can connect to your workspace and work with Railway through them. Matter, the assistant built into the platform, uses the same nodes natively.
Railway's API is GraphQL. Do I need to know GraphQL to use these nodes?
No. Each of the 67 typed nodes carries a fixed GraphQL document and maps your canvas fields onto that operation's variables, so you fill in a project id or a service id exactly as you would for any other connector. GraphQL only becomes visible if you choose Railway: Custom GraphQL Request, the advanced node that takes a document and variables of your own.
Which Railway token does the connector need, and do project tokens work?
It needs an account token or a workspace token, created at railway.com/account/tokens and sent as an Authorization Bearer header. Railway project tokens are not supported: Railway expects those in a different header, Project-Access-Token, so pasting one into the credential will fail authentication. Use an account token for access across your workspaces, or a workspace token to keep an automation scoped to one workspace.
Can it read build and runtime logs when a deploy breaks?
Yes. Railway: Get Build Logs reads the build phase, Railway: Get Deployment Logs reads the running application, Railway: Get HTTP Logs reads the edge request log with method, path, status, and duration, and Railway: Get Environment Logs aggregates across every service in an environment. Those outputs feed straight into an AI step, a task, or a message in the same workflow.
Is it safe to read Railway environment variables in an automation?
Read them deliberately. Railway: Get Variables and Railway: Get Deployment Variables return real values, which means database URLs and API keys in plain text. Use them only where the workflow genuinely needs a value, and do not wire their output straight into a logging, message, or notification node. When you set a variable with Railway: Set Variable, reference a stored credential rather than pasting a secret into the workflow.
Does the connector report Railway usage or cost?
Not today. Railway documents that resource usage metrics exist, but it does not publish the GraphQL operation for querying them, so no usage or cost node was built rather than guessing at one. If you find the operation through schema introspection, Railway: Custom GraphQL Request can run it in the meantime.
What happens to my workflow when a Railway operation fails?
GraphQL returns HTTP 200 even when an operation fails, putting the problem in an errors array instead of the status code. The connector reads that array, fails the step, and surfaces the message on the node output, so a bad id or a permission problem stops the run where you would expect it to rather than passing an empty result down the canvas.
Put Railway to work inside your workspace
Connect once, then use every node in visual automations and AI agent workflows across the Mattering platform.
All product names, logos, and brands are property of their respective owners and are used for identification purposes only. Use of these names, logos, and brands does not imply endorsement or affiliation. Railway is a product of its respective owner; Mattering is an independent platform.