railway-deploy
Manage Railway deployments using the CLI. Use when a user asks to deploy to Railway, check deployment status, manage Railway services, set environment variables on Railway, view Railway logs, link a Railway project, add a database on Railway, scale Railway services, manage Railway environments, rollback a Railway deployment, or run commands with Railway env vars. Covers the full deploy lifecycle from project setup to production monitoring.
What this skill does
# Railway Deploy ## Overview Deploy, manage, and monitor applications on Railway using the CLI. Covers the full lifecycle: project setup, service configuration, environment variables, deployments, scaling, logs, and debugging. ## Instructions ### Task A: Project Setup & Linking First verify the CLI is installed. If `railway` is not found, install it: ```bash npm i -g @railway/cli # or: brew install railway ``` Check if already linked to a project: ```bash railway status ``` If not linked, either create a new project or link to an existing one: ```bash railway init # Create a new project railway link # Link to an existing project ``` After linking, confirm with `railway status` to verify project, service, and environment context. For CI/CD or headless environments, use token auth: ```bash RAILWAY_TOKEN=xxx railway up # Project-scoped token RAILWAY_API_TOKEN=xxx railway up # Account-scoped token ``` ### Task B: Deploy ```bash # Deploy current directory and stream logs railway up # Deploy without waiting for logs railway up --detach # Target a specific service railway up -s my-service # Deploy to a specific environment railway up -e staging ``` To remove the latest deployment: ```bash railway down ``` To redeploy the latest deployment (same code, fresh build): ```bash railway redeploy ``` To restart a service without rebuilding: ```bash railway restart ``` ### Task C: Manage Services & Resources ```bash # Add a service interactively railway add # Add a database railway add --database postgres # also: mysql, redis, mongo # Add a service from a GitHub repo railway add --repo user/repo # Switch linked service context railway service # Scale a service railway scale # Generate a Railway subdomain or add a custom domain railway domain railway domain example.com # Manage persistent volumes railway volume list railway volume add railway volume delete # Delete the entire project railway delete ``` ### Task D: Environment Variables ```bash # List all variables for current service/environment railway variable list # Set a variable railway variable set DATABASE_URL=postgres://user:pass@host:5432/db # Set multiple variables railway variable set KEY1=value1 KEY2=value2 # Delete a variable railway variable delete SECRET_KEY ``` ### Task E: Environments ```bash # Switch environment interactively railway environment # Create a new environment railway environment new staging # Delete an environment railway environment delete dev # Deploy to a specific environment railway up -e production ``` ### Task F: Logs & Debugging ```bash # Stream live logs railway logs # View build logs railway logs --build # View last N lines railway logs -n 100 # SSH into the running container railway ssh # Connect to a database shell (e.g., psql, mysql, redis-cli) railway connect ``` ### Task G: Local Development ```bash # Run a command with Railway environment variables injected railway run npm start railway run python manage.py migrate # Open an interactive shell with Railway env vars railway shell ``` ## Examples ### Example 1: Deploy a Node.js app from scratch **User request:** "Deploy my Node.js app to Railway" **Actions taken:** ```bash $ railway login > Opening browser for authentication... > Logged in as [email protected] $ railway init > Created project "my-node-app" in workspace "Personal" $ railway up > Uploading 2.3 MB... > Build started > Installing dependencies... > Build completed in 34s > Deployment live at my-node-app.up.railway.app $ railway domain > Service domain: my-node-app.up.railway.app ``` ### Example 2: Add a Postgres database and wire it up **User request:** "Add a database to my Railway project and set it up" **Actions taken:** ```bash $ railway status > Project: my-node-app > Service: web > Environment: production $ railway add --database postgres > Added PostgreSQL service to project # The DATABASE_URL is automatically injected. Verify: $ railway variable list > DATABASE_URL=postgres://railway:abc123@host:5432/railway > PGHOST=host > PGPORT=5432 > ... # Run migrations using Railway env vars $ railway run npx prisma migrate deploy > Applying migrations... > 3 migrations applied successfully $ railway redeploy > Redeploying web service... > Deployment live ``` ### Example 3: Debug a failing deployment **User request:** "My Railway deployment is crashing, help me debug it" **Actions taken:** ```bash $ railway status > Project: my-api > Service: web > Environment: production # Check build logs first $ railway logs --build > Step 4/8: RUN npm ci > npm ERR! Could not resolve dependency: peer express@"^4.0.0" # If build passes but runtime fails, check runtime logs $ railway logs -n 50 > Error: connect ECONNREFUSED 127.0.0.1:5432 # Verify variables are set $ railway variable list > DATABASE_URL=postgres://...@localhost:5432/mydb # BUG: using localhost # Fix: point to the Railway-provided database host $ railway variable set DATABASE_URL=postgres://user:pass@railway-db-host:5432/mydb $ railway redeploy > Redeploying... > Deployment live ``` ### Task H: Health Checks and Auto-Rollback After deploying, verify the service is healthy before considering the deploy complete. If unhealthy, roll back to the previous deployment. ```bash # Deploy and wait for completion $ railway up --detach # Health check loop — verify the service responds HEALTH_URL="https://your-app.railway.app/api/health" TIMEOUT=60 DEADLINE=$((SECONDS + TIMEOUT)) HEALTHY=false while [ $SECONDS -lt $DEADLINE ]; do STATUS=$(curl -s -o /dev/null -w "%{http_code}" "$HEALTH_URL" 2>/dev/null || echo "000") if [ "$STATUS" = "200" ]; then HEALTHY=true break fi echo "Waiting for healthy response... (status: $STATUS)" sleep 3 done if [ "$HEALTHY" = true ]; then echo "✅ Deployment healthy!" else echo "❌ Health check failed! Rolling back..." railway rollback echo "⏪ Rolled back to previous deployment" fi ``` **Automated deploy script with health verification:** ```python # deploy_railway.py — Deploy with health check and auto-rollback import subprocess import time import httpx def deploy_with_health_check(health_url, timeout=60): """Deploy to Railway, verify health, rollback on failure.""" print("🚀 Deploying to Railway...") subprocess.run(["railway", "up", "--detach"], check=True) print(f"🏥 Health checking {health_url}...") deadline = time.time() + timeout while time.time() < deadline: try: r = httpx.get(health_url, timeout=5) if r.status_code == 200: print("✅ Healthy!") return True except httpx.RequestError: pass time.sleep(3) print("❌ Unhealthy! Rolling back...") subprocess.run(["railway", "rollback"], check=True) print("⏪ Rolled back") return False ``` ## Guidelines - Always run `railway status` first to confirm project, service, and environment context before making changes. - Use `railway up --detach` in CI/CD pipelines to avoid blocking on log output. - Use `RAILWAY_TOKEN` for project-scoped CI/CD auth and `RAILWAY_API_TOKEN` for account-level operations. - Use `-s service-name` and `-e environment-name` flags when managing multi-service projects to avoid acting on the wrong target. - Use `railway run` to execute one-off commands (migrations, seeds) with production env vars without deploying. - If a deployment fails, check build logs (`railway logs --build`) first, then runtime logs (`railway logs`). - Use `railway connect` to get a database shell directly without needing connection strings locally. - Add `--json` to any command for machine-readable output in scripts. - Use `railway variable set` to update env vars, then `railway redeploy` to pick up the changes. - Use `railway environment new` to create staging/preview environments that mirror production config. - If `railway` command is not found, install via `npm i -g @railway/cli` or `brew instal
Related in Cloud & DevOps
appbuilder-action-scaffolder
IncludedCreate, implement, deploy, and debug Adobe Runtime actions with consistent layout, validation, and error handling. Use this skill whenever the user needs to add actions to an App Builder project, understand action structure (params, response format, web/raw actions), configure actions in the manifest, use App Builder SDKs (State, Files, Events, database), deploy and invoke actions via CLI, debug action issues, or implement patterns such as webhook receivers, custom event providers, journaling consumers, large payload redirects, action sequence pipelines, and Asset Compute workers. Also trigger when users mention serverless functions in Adobe context, action logging, IMS authentication for actions, or cron-style scheduled actions.
orchestrating-datacloud
IncludedSalesforce Data Cloud product orchestrator for connect→prepare→harmonize→segment→act workflows. Use this skill when the user needs a multi-step Data Cloud pipeline, cross-phase troubleshooting, or data space and data kit management. TRIGGER when: user needs a multi-step Data Cloud pipeline, asks to set up or troubleshoot Data Cloud across phases, manages data spaces or data kits, or wants a cross-phase sf data360 workflow. DO NOT TRIGGER when: work is isolated to a single phase (use the matching phase-specific skill), the task is STDM/session tracing/parquet telemetry (use observing-agentforce), standard CRM SOQL (use querying-soql), or Apex implementation (use generating-apex).
github-project-automation
IncludedAutomate GitHub repository setup with CI/CD workflows, issue templates, Dependabot, and CodeQL security scanning. Includes 12 production-tested workflows and prevents 18 errors: YAML syntax, action pinning, and configuration. Use when: setting up GitHub Actions CI/CD, creating issue/PR templates, enabling Dependabot or CodeQL scanning, deploying to Cloudflare Workers, implementing matrix testing, or troubleshooting YAML indentation, action version pinning, secrets syntax, runner versions, or CodeQL configuration. Keywords: github actions, github workflow, ci/cd, issue templates, pull request templates, dependabot, codeql, security scanning, yaml syntax, github automation, repository setup, workflow templates, github actions matrix, secrets management, branch protection, codeowners, github projects, continuous integration, continuous deployment, workflow syntax error, action version pinning, runner version, github context, yaml indentation error
sf-datacloud
IncludedSalesforce Data Cloud product orchestrator for connect→prepare→harmonize→segment→act workflows. TRIGGER when: user needs a multi-step Data Cloud pipeline, asks to set up or troubleshoot Data Cloud across phases, manages data spaces or data kits, or wants a cross-phase `sf data360` workflow. DO NOT TRIGGER when: work is isolated to a single phase (use the matching sf-datacloud-* skill), the task is STDM/session tracing/parquet telemetry (use sf-ai-agentforce-observability), standard CRM SOQL (use sf-soql), or Apex implementation (use sf-apex).
fabric-cli
IncludedUse this skill for Fabric.so CLI workflows with the `fabric` terminal command: diagnose/install/login, search or browse a Fabric library, save notes/links/files, create folders, ask the Fabric AI assistant, manage tasks/workspaces, generate shell completion, check subscription usage, produce JSON output, and use Fabric as persistent agent memory. Do not use for Microsoft Fabric/Azure/Power BI `fab`, Daniel Miessler's Fabric framework, Python Fabric SSH, Fabric.js, or textile/fashion fabric.
lark
IncludedLark/Feishu CLI skills: lark-cli operations for docs, markdown, sheets, base, calendar, im, mail, task, okr, drive, wiki, slides, whiteboard, apps, approval, attendance, contact, vc, minutes, event. Use when the user needs to operate Lark/Feishu resources via lark-cli, send messages, manage documents, spreadsheets, calendars, tasks, OKRs, deploy web pages, or any Feishu/Lark workspace operations.