Accept-deploy
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.
ActionTry it
Integrate Railway MCP
with your AI CRM
Create, inspect, deploy, and manage Railway projects, services, environments, variables, and deployments through Railway's hosted MCP server.
Explore Triggers and Actions
Connect-service-source
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.
ActionTry it
Create-bucket
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.
ActionTry it
Create-deployment
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.
ActionTry it
Create-project
Create a new Railway project
ActionTry it
Create-service
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.
ActionTry it
Create-tcp-proxy
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.
ActionTry it
Create-volume
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.
ActionTry it
Delete-bucket
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.
ActionTry it
Delete-feature-flag
Delete a project-scoped feature flag. Workspace-scoped flags cannot be deleted from project context.
ActionTry it
Delete-service
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.
ActionTry it
Delete-tcp-proxy
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.
ActionTry it
Delete-volume
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.
ActionTry it
Describe-environment
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.
ActionTry it
Describe-service
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.
ActionTry it
Domain-status
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.
ActionTry it
Environment-status
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.
ActionTry it
Fetch-docs
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.
ActionTry it
Generate-domain
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.
ActionTry it
Get-deployment-diagnosis
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.
ActionTry it
Get-feature-flag
Get a Railway feature flag (Signal) by name for a project or its parent workspace scope.
ActionTry it
Get-logs
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']).
ActionTry it
Get-service-config
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.
ActionTry it
Get-service-metrics
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.
ActionTry it
Get-staged-changes
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.
ActionTry it
Get-status
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.
ActionTry it
Http-error-rate
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.
ActionTry it
Http-requests
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.
ActionTry it
Http-response-time
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.
ActionTry it
List-deployments
List recent deployments for a Railway project, optionally filtered by environment, service, or status. Returns the most recent first.
ActionTry it
List-domains
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.
ActionTry it
List-feature-flags
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.
ActionTry it
List-projects
List all Railway projects accessible to the authenticated user
ActionTry it
List-services
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.
ActionTry it
List-tcp-proxies
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.
ActionTry it
List-variables
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.
ActionTry it
List-workspaces
List the Railway workspaces the current user belongs to. Use a workspace ID with create-project to choose where a project is created.
ActionTry it
Railway-agent
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.
ActionTry it
Redeploy
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.
ActionTry it
Restart-service
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.
ActionTry it
Search-docs
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.
ActionTry it
Set-feature-flag
Create a project-scoped feature flag or update its default value. Use list-feature-flags and get-feature-flag to inspect existing flags first.
ActionTry it
Set-variables
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.
ActionTry it
Update-service
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.
ActionTry it
Update-volume
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.
ActionTry it
Whoami
Get the current authenticated Railway user's profile information
ActionTry it
How the Railway MCP integration works
The Railway MCP integration connects your Dench AI CRM directly to Railway MCP, so agents can read and act on your Railway MCP data as part of everyday work — answering questions in chat, keeping your CRM in sync, and running automations without anyone copying data between tools.
46 actions are available for agents to invoke on your behalf. Every call runs through Railway MCP's own authorization, scoped to the account you connect.
Set up Railway MCP in Dench
- 1
Sign in to your Dench workspace and open Integrations.
- 2
Find Railway MCP and click Connect — you'll authorize access through Railway MCP's own sign-in flow. No API keys or code required.
- 3
Ask an agent to use Railway MCP in chat, or call it from an automation.
- 4
Manage or disconnect the connection any time from workspace settings.
Frequently asked questions
How does the Railway MCP integration work with Dench?
The Dench Railway MCP integration connects your AI CRM to Railway MCP, so AI agents can work with your Railway MCP data as part of chats, automations, and CRM workflows. You connect your account once, and every agent in your workspace can use it — governed by your workspace permissions.
What actions can AI agents perform with Railway MCP via Dench?
The Railway MCP integration currently exposes 46 actions, including Accept-deploy, Connect-service-source, Create-bucket, Create-deployment, Create-project, and Create-service. Agents invoke them on your behalf from chat or from automations.
Do I need to write code to connect Railway MCP to Dench?
No. You connect Railway MCP from your Dench workspace using Railway MCP's own sign-in and authorization flow — no API keys to copy, no glue code to maintain.
Is the Railway MCP integration secure?
Connections are authorized through Railway MCP's own authentication flow, and Dench stores only the authorization needed to act on your behalf. You can review and disconnect the Railway MCP connection from your workspace settings at any time.