railway-environment
Handles environment variables, build settings, and deployment operations for Railway services.
Install
mkdir -p .claude/skills/railway-environment && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/7703" && unzip -o skill.zip -d .claude/skills/railway-environment && rm skill.zipInstalls to .claude/skills/railway-environment
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Query, stage, and apply configuration changes for Railway environments. Use for ANY variable or env var operations, service configuration (source, build settings, deploy settings), lifecycle (delete service), and applying changes. Prefer over railway-status skill for any configuration or variable queries.Key capabilities
- →Query environment configuration
- →Stage environment changes
- →Apply configuration changes
- →Manage environment variables
- →Configure service build settings
How it works
It uses GraphQL queries and mutations to interact with the Railway API for managing environment variables, build settings, and deployment lifecycles.
Inputs & outputs
When to use railway-environment
- →Updating environment variables
- →Changing deployment build settings
- →Duplicating environments
- →Configuring service health checks
About this skill
Environment Configuration
Query, stage, and apply configuration changes for Railway environments.
Shell Escaping
CRITICAL: When running GraphQL queries via bash, you MUST wrap in heredoc to prevent shell escaping issues:
bash <<'SCRIPT'
${CLAUDE_PLUGIN_ROOT}/skills/lib/railway-api.sh 'query ...' '{"var": "value"}'
SCRIPT
Without the heredoc wrapper, multi-line commands break and exclamation marks in GraphQL non-null types get escaped, causing query failures.
When to Use
- User wants to create a new environment
- User wants to duplicate an environment (e.g., "copy production to staging")
- User wants to switch to a different environment
- User asks about current build/deploy settings, variables, replicas, health checks, domains
- User asks to change service source (Docker image, branch, commit, root directory)
- User wants to connect a service to a GitHub repo
- User wants to deploy from a GitHub repo (create empty service first via railway-new skill, then use this)
- User asks to change build or start command
- User wants to add/update/delete environment variables
- User wants to change replica count or configure health checks
- User asks to delete a service, volume, or bucket
- User says "apply changes", "commit changes", "deploy changes"
- Auto-fixing build errors detected in logs
Create Environment
Create a new environment in the linked project:
railway environment new <name>
Duplicate an existing environment:
railway environment new staging --duplicate production
With service-specific variables:
railway environment new staging --duplicate production --service-variable api PORT=3001
Switch Environment
Link a different environment to the current directory:
railway environment <name>
Or by ID:
railway environment <environment-id>
Get Context
railway status --json
Extract:
project.id- for service lookupenvironment.id- for the mutationsservice.id- default service if user doesn't specify one
Resolve Service ID
If user specifies a service by name, query project services:
query projectServices($projectId: String!) {
project(id: $projectId) {
services {
edges {
node {
id
name
}
}
}
}
}
Match the service name (case-insensitive) to get the service ID.
Query Configuration
Fetch current environment configuration and staged changes.
query environmentConfig($environmentId: String!) {
environment(id: $environmentId) {
id
config(decryptVariables: false)
serviceInstances {
edges {
node {
id
serviceId
}
}
}
}
environmentStagedChanges(environmentId: $environmentId) {
id
patch(decryptVariables: false)
}
}
Example:
bash <<'SCRIPT'
${CLAUDE_PLUGIN_ROOT}/skills/lib/railway-api.sh \
'query envConfig($envId: String!) {
environment(id: $envId) { id config(decryptVariables: false) }
environmentStagedChanges(environmentId: $envId) { id patch(decryptVariables: false) }
}' \
'{"envId": "ENV_ID"}'
SCRIPT
Response Structure
The config field contains current configuration:
{
"services": {
"<serviceId>": {
"source": { "repo": "...", "branch": "main" },
"build": { "buildCommand": "npm run build", "builder": "NIXPACKS" },
"deploy": {
"startCommand": "npm start",
"multiRegionConfig": { "us-west2": { "numReplicas": 1 } }
},
"variables": { "NODE_ENV": { "value": "production" } },
"networking": { "serviceDomains": {}, "customDomains": {} }
}
},
"sharedVariables": { "DATABASE_URL": { "value": "..." } }
}
The patch field in environmentStagedChanges contains pending changes. The effective configuration is the base config merged with the staged patch.
For complete field reference, see reference/environment-config.md.
For variable syntax and service wiring patterns, see reference/variables.md.
Get Rendered Variables
The GraphQL queries above return unrendered variables - template syntax like ${{shared.DOMAIN}} is preserved. This is correct for management/editing.
To see rendered (resolved) values as they appear at runtime:
# Current linked service
railway variables --json
# Specific service
railway variables --service <service-name> --json
When to use:
- Debugging connection issues (see actual URLs/ports)
- Verifying variable resolution is correct
- Viewing Railway-injected values (RAILWAY_*)
Stage Changes
Stage configuration changes via the environmentStageChanges mutation. Use merge: true to automatically merge with existing staged changes.
mutation stageEnvironmentChanges(
$environmentId: String!
$input: EnvironmentConfig!
$merge: Boolean
) {
environmentStageChanges(
environmentId: $environmentId
input: $input
merge: $merge
) {
id
}
}
Important: Always use variables (not inline input) because service IDs are UUIDs which can't be used as unquoted GraphQL object keys.
Example:
bash <<'SCRIPT'
${CLAUDE_PLUGIN_ROOT}/skills/lib/railway-api.sh \
'mutation stageChanges($environmentId: String!, $input: EnvironmentConfig!, $merge: Boolean) {
environmentStageChanges(environmentId: $environmentId, input: $input, merge: $merge) { id }
}' \
'{"environmentId": "ENV_ID", "input": {"services": {"SERVICE_ID": {"build": {"buildCommand": "npm run build"}}}}, "merge": true}'
SCRIPT
Delete Service
Use isDeleted: true:
bash <<'SCRIPT'
${CLAUDE_PLUGIN_ROOT}/skills/lib/railway-api.sh \
'mutation stageChanges($environmentId: String!, $input: EnvironmentConfig!, $merge: Boolean) {
environmentStageChanges(environmentId: $environmentId, input: $input, merge: $merge) { id }
}' \
'{"environmentId": "ENV_ID", "input": {"services": {"SERVICE_ID": {"isDeleted": true}}}, "merge": true}'
SCRIPT
Stage and Apply Immediately
For single changes that should deploy right away, use environmentPatchCommit to stage and apply in one call.
mutation environmentPatchCommit(
$environmentId: String!
$patch: EnvironmentConfig
$commitMessage: String
) {
environmentPatchCommit(
environmentId: $environmentId
patch: $patch
commitMessage: $commitMessage
)
}
Example:
bash <<'SCRIPT'
${CLAUDE_PLUGIN_ROOT}/skills/lib/railway-api.sh \
'mutation patchCommit($environmentId: String!, $patch: EnvironmentConfig, $commitMessage: String) {
environmentPatchCommit(environmentId: $environmentId, patch: $patch, commitMessage: $commitMessage)
}' \
'{"environmentId": "ENV_ID", "patch": {"services": {"SERVICE_ID": {"variables": {"API_KEY": {"value": "secret"}}}}}, "commitMessage": "add API_KEY"}'
SCRIPT
When to use: Single change, no need to batch, user wants immediate deployment.
When NOT to use: Multiple related changes to batch, or user says "stage only" / "don't deploy yet".
Apply Staged Changes
Commit staged changes and trigger deployments.
Note: There is no railway apply CLI command. Use the mutation below or direct users to the web UI.
Apply Mutation
Mutation name: environmentPatchCommitStaged
mutation environmentPatchCommitStaged(
$environmentId: String!
$message: String
$skipDeploys: Boolean
) {
environmentPatchCommitStaged(
environmentId: $environmentId
commitMessage: $message
skipDeploys: $skipDeploys
)
}
Example:
bash <<'SCRIPT'
${CLAUDE_PLUGIN_ROOT}/skills/lib/railway-api.sh \
'mutation commitStaged($environmentId: String!, $message: String) {
environmentPatchCommitStaged(environmentId: $environmentId, commitMessage: $message)
}' \
'{"environmentId": "ENV_ID", "message": "add API_KEY variable"}'
SCRIPT
Parameters
| Field | Type | Default | Description |
|---|---|---|---|
environmentId | String! | - | Environment ID from status |
message | String | null | Short description of changes |
skipDeploys | Boolean | false | Skip deploys (only if user explicitly asks) |
Commit Message
Keep very short - one sentence max. Examples:
- "set build command to fix npm error"
- "add API_KEY variable"
- "increase replicas to 3"
Leave empty if no meaningful description.
Default Behavior
Always deploy unless user explicitly asks to skip. Only set skipDeploys: true if user says "apply without deploying", "commit but don't deploy", or "skip deploys".
Returns a workflow ID (string) on success.
Auto-Apply Behavior
By default, apply changes immediately.
Flow
Single change: Use environmentPatchCommit to stage and apply in one call.
Multiple changes or batching: Use environmentStageChanges with merge: true for each change, then environmentPatchCommitStaged to apply.
When NOT to Auto-Apply
- User explicitly says "stage only", "don't deploy yet", or similar
- User is making multiple related changes that should deploy together
When you don't auto-apply, tell the user:
Changes staged. Apply them at: https://railway.com/project/{projectId} Or ask me to apply them.
Get projectId from railway status --json → project.id
Error Handling
Service Not Found
Service "foo" not found in project. Available services: api, web, worker
No Staged Changes
No patch to apply
There are no staged changes to commit. Stage changes first.
Invalid Configuration
Common issues:
buildCommandandstartCommandcannot be identicalbuildCommandonly valid with NIXPACKS builderdockerfilePathonly valid with DOCKERFILE builder
No Permission
Content truncated.
When not to use it
- →Non-Railway project management
Prerequisites
Limitations
- →Requires valid Railway permissions
- →Requires linked project
How it compares
It provides a structured, API-driven approach to environment management compared to manual dashboard configuration.
Compared to similar skills
railway-environment side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| railway-environment (this skill) | 1 | 7mo | Review | Intermediate |
| cloudflare-manager | 25 | 9mo | Review | Intermediate |
| railway-cli-management | 9 | 8mo | Review | Intermediate |
| azure-functions | 10 | 5mo | Review | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by davila7
View all by davila7 →You might also like
cloudflare-manager
qdhenry
Comprehensive Cloudflare account management for deploying Workers, KV Storage, R2, Pages, DNS, and Routes. Use when deploying cloudflare services, managing worker containers, configuring KV/R2 storage, or setting up DNS/routing. Requires CLOUDFLARE_API_KEY in .env and Bun runtime with dependencies installed.
railway-cli-management
CaptainCrouton89
Deploy, manage services, view logs, and configure Railway infrastructure. Use when deploying to Railway, managing environment variables, viewing deployment logs, scaling services, or managing volumes.
azure-functions
aj-geddes
Create serverless functions on Azure with triggers, bindings, authentication, and monitoring. Use for event-driven computing without managing infrastructure.
nuxthub-migration
onmax
Use when migrating NuxtHub projects or when user mentions NuxtHub Admin sunset, GitHub Actions deployment removal, self-hosting NuxtHub, or upgrading to v1/nightly. Covers v0.9.X self-hosting (stable) and v1/nightly multi-cloud (experimental, database/blob not ready).
deployment-pipeline-design
wshobson
Design multi-stage CI/CD pipelines with approval gates, security checks, and deployment orchestration. Use when architecting deployment workflows, setting up continuous delivery, or implementing GitOps practices.
terraform-module-library
wshobson
Build reusable Terraform modules for AWS, Azure, and GCP infrastructure following infrastructure-as-code best practices. Use when creating infrastructure modules, standardizing cloud provisioning, or implementing reusable IaC components.