environment_skill

This skill helps you inspect and manage Railway environment configuration, including variables, build and deploy settings, and service connections.
  • Shell
  • Official

79

GitHub Stars

1

Bundled Files

2 months ago

Catalog Refreshed

4 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill railwayapp/railway-skills --skill environment

  • SKILL.md11.2 KB

Overview

This skill manages Railway environment configuration: inspect current config, stage and apply changes, and modify variables, build/deploy settings, and service wiring. It supports querying rendered or raw variables, duplicating or switching environments, and committing staged changes for immediate or deferred deployment. Use it to programmatically control environment-level settings and service-scale parameters.

How this skill works

The skill queries Railway for project and environment context (railway status --json) then fetches full environment config and any staged patch via GraphQL. It stages changes with environmentStageChanges (mergeable) and can commit immediately with environmentPatchCommit or apply all staged changes with environmentPatchCommitStaged. For runtime values it uses the CLI variables command to return rendered variables.

When to use it

  • User asks “what's the config”, “show configuration”, or “what variables are set”
  • Add, update, or delete environment or service variables
  • Change service source (image, repo, branch, root dir) or build/start commands
  • Create, duplicate, or switch environments; connect a GitHub repo
  • Change replica counts, health checks, or delete a service/volume/bucket
  • Stage multiple changes and then apply or apply a single change immediately

Best practices

  • Always run railway status --json first to get project and environment IDs
  • When running GraphQL via bash, wrap API calls in a heredoc to avoid shell escaping problems
  • Use variables in GraphQL mutations (not inline object keys) because service IDs are UUIDs
  • Use merge: true when staging incremental changes to avoid overwriting staged patches
  • Default behavior is to deploy on commit; only set skipDeploys when user explicitly requests it

Example use cases

  • Show full environment configuration including per-service variables and shared variables
  • Add an API key to a specific service and commit immediately to deploy
  • Duplicate production to staging and adjust service PORT variables during creation
  • Stage multiple build and deploy changes across services, then apply them together
  • Increase a service replica count and commit with a short commit message

FAQ

Run railway variables --json or railway variables --service <name> --json to see runtime-resolved values.

When should I use environmentPatchCommit vs environmentPatchCommitStaged?

Use environmentPatchCommit for single changes that should deploy immediately. Use environmentPatchCommitStaged to apply all previously staged changes together.

What if my GraphQL queries fail in bash?

Always wrap scripts/railway-api.sh calls in a heredoc (bash <<'SCRIPT' ... SCRIPT) to prevent shell escaping issues with multi-line queries and special characters.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational