Railway CLI
Skill471 starsChanged 30 days agoApache-2.0View on GitHub
Railway CLI operations for authentication, context management, deployment, monitoring, and troubleshooting. Use when working with Railway infrastructure, deploying services, or managing environments.
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 1 is distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 273
"Project not found": Create .railway/config.json with projectId
- Very specific: line 277
SSH connection fails: Ensure deployment is running, use railway logs to check status
- Distinctive: line 279
Logs not showing: Check service name and environment are correct
- Very specific: line 285
Always specify
-e stagingexplicitly: when working with staging to avoid accidentally affecting production.
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Railway CLI for IOTA SDK
Check Authentication
railway whoamiContext Management
Check current context:
railway statusList all projects with IDs:
railway list --json | jq '.'Link project manually (create .railway/config.json):
mkdir -p .railway
cat > .railway/config.json << 'EOF'
{
"projectId": "<your-project-id>"
}
EOFSwitch environment:
railway environment <environment>Deployment
Deploy to specific environment and service:
railway up -s <service> -e <environment> --detachRedeploy latest deployment:
railway redeploy -s <service> -e <environment> -yCheck deployment status:
railway status -s <service> -e <environment>Monitoring
View deployment logs (real-time stream):
railway logs -s <service> -e <environment> --deploymentView build logs:
railway logs -s <service> -e <environment> --buildGet logs in JSON format (for parsing):
railway logs -s <service> -e <environment> --deployment --jsonFilter logs for errors/panics:
# Text output with grep
railway logs -s iota-sdk -e staging --deployment 2>&1 | grep -i -E "(panic|error|fatal)"
# JSON output with jq (more reliable)
railway logs -s iota-sdk -e staging --deployment --json 2>&1 | \
jq -r 'select(.message | test("panic|error|fatal"; "i")) | "\(.timestamp) \(.message)"'Get context around errors:
# Get 30 lines after each match
railway logs -s iota-sdk -e staging --deployment 2>&1 | grep -A 30 "panic"
# Limit total output
railway logs -s iota-sdk -e staging --deployment 2>&1 | tail -100Note: Railway enforces a rate limit of 500 logs/sec per replica. High-volume logging may result in dropped messages.
Variables
Get all variables for a service:
railway variables -s <service> -e <environment> --kvSet a variable:
railway variables -s <service> -e <environment> --set "KEY=value"Running Commands
Execute local command with remote environment variables:
railway run -s <service> -e <environment> -- <command>Note: railway run executes locally, not on the remote service. Use for running local commands with staging/production environment variables.
Database Access
Connect to database shell:
railway connect db -e <environment>Get database connection URL:
railway variables -s db -e <environment> --kv | grep DATABASE_PUBLIC_URLSSH into service (requires active deployment):
railway ssh -s <service> -e <environment>Common Operations for IOTA SDK
Analyzing Panics and Errors
Find recent panics with stack traces:
# Get panic with 30 lines of context (includes stack trace)
railway logs -s iota-sdk -e staging --deployment 2>&1 | grep -A 30 "panic"
# Find specific error patterns
railway logs -s iota-sdk -e staging --deployment --json 2>&1 | \
jq -r 'select(.message | test("your-pattern"; "i")) | .message' | tail -50Common error patterns for IOTA SDK:
- Translation errors:
"message .* not found in language" - Database errors:
"pq:|postgres:|connection|timeout" - HTTP panics:
"http: panic serving" - Multi-tenant errors:
"tenant_id|organization_id|forbidden" - Permission errors:
"permission denied|insufficient permissions"
Running Migrations on Staging
Get database credentials and run migrations locally:
# Get the public database URL
railway variables -s db -e staging --kv | grep DATABASE_PUBLIC_URL
# Example output: DATABASE_PUBLIC_URL=postgresql://postgres:PASSWORD@HOST:PORT/railway
# Extract connection details from the URL and export
export DB_HOST=<host-from-url> # Example: shuttle.proxy.rlwy.net
export DB_PORT=<port-from-url> # Example: 31150
export DB_NAME=<database-from-url> # Example: railway
export DB_USER=<user-from-url> # Example: postgres
export DB_PASSWORD=<password-from-url>
# Check migration status
make db migrate status
# Run pending migrations
make db migrate up
# Rollback if needed
make db migrate downDeploying New Version
# 1. Verify current status
railway status -s iota-sdk -e staging
# 2. Deploy new version
railway up -s iota-sdk -e staging --detach
# 3. Monitor deployment logs
railway logs -s iota-sdk -e staging --deployment
# 4. Verify deployment success
railway status -s iota-sdk -e staging
# 5. Check for errors
railway logs -s iota-sdk -e staging --deployment 2>&1 | grep -i error | tail -20Environment Variable Management
# List all environment variables
railway variables -s iota-sdk -e staging --kv
# Update application config
railway variables -s iota-sdk -e staging --set "LOG_LEVEL=debug"
# Update database connection (example)
railway variables -s iota-sdk -e staging --set "DB_HOST=new-host"
# Trigger restart after variable changes
railway redeploy -s iota-sdk -e staging -yDatabase Backup
# Get database URL
DB_URL=$(railway variables -s db -e staging --kv | grep DATABASE_PUBLIC_URL | cut -d'=' -f2)
# Create backup
pg_dump "$DB_URL" > backup_$(date +%Y%m%d_%H%M%S).sql
# Or with compression
pg_dump "$DB_URL" | gzip > backup_$(date +%Y%m%d_%H%M%S).sql.gzIOTA SDK Project Structure
Environment Names:
staging- Staging environmentproduction- Production environment
Service Names (adjust based on actual setup):
iota-sdk- Main Go applicationdb- PostgreSQL database
Example with actual service names:
# Deploy to staging
railway up -s iota-sdk -e staging --detach
# View logs
railway logs -s iota-sdk -e staging --deployment
# Check database
railway connect db -e stagingTroubleshooting
"Project not found": Create .railway/config.json with projectId
"No deployment found": Service has no active deployment in that environment
SSH connection fails: Ensure deployment is running, use railway logs to check status
Logs not showing: Check service name and environment are correct
Variable not updating: Redeploy service after setting variables
Production Safety
Always specify -e staging explicitly when working with staging to avoid accidentally affecting production.
Before Running Production Operations
- Double-check the environment flag (
-e production) - Verify current context with
railway status - Test on staging first
- Have a rollback plan ready
- Announce deployment to team
- Monitor logs during deployment
Production Deployment Checklist
- Code changes reviewed and approved
- Tests passing in CI/CD
- Staging deployment successful
- Database migrations tested on staging
- Rollback plan prepared
- Team notified of deployment
- Monitoring dashboard ready
- Environment flag verified (
-e production)
Emergency Rollback
# 1. Check recent deployments
railway status -s iota-sdk -e production
# 2. Redeploy previous version (if using git tags/branches)
git checkout <previous-version>
railway up -s iota-sdk -e production --detach
# 3. Or use Railway dashboard to rollback
# Visit Railway dashboard → Service → Deployments → RollbackQuick Reference
# Authentication
railway whoami
railway status
# Deployment
railway up -s iota-sdk -e staging --detach
railway redeploy -s iota-sdk -e staging -y
# Logs
railway logs -s iota-sdk -e staging --deployment
railway logs -s iota-sdk -e staging --deployment | grep -i error
# Variables
railway variables -s iota-sdk -e staging --kv
railway variables -s iota-sdk -e staging --set "KEY=value"
# Database
railway connect db -e staging
railway variables -s db -e staging --kv | grep DATABASE_PUBLIC_URL
# SSH
railway ssh -s iota-sdk -e stagingCommon Workflows
Debug Production Issue
# 1. View recent logs
railway logs -s iota-sdk -e production --deployment | tail -100
# 2. Search for errors
railway logs -s iota-sdk -e production --deployment | grep -i error -A 10
# 3. Check database connection
railway variables -s iota-sdk -e production --kv | grep DB_
# 4. SSH into service if needed
railway ssh -s iota-sdk -e productionUpdate Environment Configuration
# 1. Get current variables
railway variables -s iota-sdk -e staging --kv > current_vars.txt
# 2. Update variables
railway variables -s iota-sdk -e staging --set "NEW_FEATURE_FLAG=true"
railway variables -s iota-sdk -e staging --set "LOG_LEVEL=info"
# 3. Redeploy to apply changes
railway redeploy -s iota-sdk -e staging -y
# 4. Verify changes
railway logs -s iota-sdk -e staging --deployment | head -50Monitor Deployment
# Terminal 1: Watch deployment status
watch -n 5 'railway status -s iota-sdk -e staging'
# Terminal 2: Stream logs
railway logs -s iota-sdk -e staging --deployment
# Terminal 3: Check for errors
watch -n 10 'railway logs -s iota-sdk -e staging --deployment | grep -i error | tail -20'In this repository6 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .claude/guides/claude-code/agents.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- .github/copilot-instructions.mdCopilot instructions
- Database ConnectionSkill
- E2E TestingSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

