// Railway CLI operations for authentication, context management, deployment, monitoring, and troubleshooting. Use when working with Railway infrastructure, deploying services, or managing environments.
| name | Railway CLI |
| description | Railway CLI operations for authentication, context management, deployment, monitoring, and troubleshooting. Use when working with Railway infrastructure, deploying services, or managing environments. |
railway whoami
Check current context:
railway status
List 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>"
}
EOF
Switch environment:
railway environment <environment>
Deploy to specific environment and service:
railway up -s <service> -e <environment> --detach
Redeploy latest deployment:
railway redeploy -s <service> -e <environment> -y
Check deployment status:
railway status -s <service> -e <environment>
View deployment logs (real-time stream):
railway logs -s <service> -e <environment> --deployment
View build logs:
railway logs -s <service> -e <environment> --build
Get logs in JSON format (for parsing):
railway logs -s <service> -e <environment> --deployment --json
Filter 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 -100
Note: Railway enforces a rate limit of 500 logs/sec per replica. High-volume logging may result in dropped messages.
Get all variables for a service:
railway variables -s <service> -e <environment> --kv
Set a variable:
railway variables -s <service> -e <environment> --set "KEY=value"
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.
Connect to database shell:
railway connect db -e <environment>
Get database connection URL:
railway variables -s db -e <environment> --kv | grep DATABASE_PUBLIC_URL
SSH into service (requires active deployment):
railway ssh -s <service> -e <environment>
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 -50
Common error patterns for IOTA SDK:
"message .* not found in language""pq:|postgres:|connection|timeout""http: panic serving""tenant_id|organization_id|forbidden""permission denied|insufficient permissions"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 down
# 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 -20
# 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 -y
# 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.gz
Environment Names:
staging - Staging environmentproduction - Production environmentService Names (adjust based on actual setup):
iota-sdk - Main Go applicationdb - PostgreSQL databaseExample 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 staging
"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
Always specify -e staging explicitly when working with staging to avoid accidentally affecting production.
-e production)railway status-e production)# 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 โ Rollback
# 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 staging
# 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 production
# 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 -50
# 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'