Problem Statement

Currently, Railway's serverless functionality has limitations that prevent many applications from utilizing it effectively:

1. Database Connection Blockers: Applications that maintain active database connections (like Appsmith, connection poolers, etc.) cannot use serverless mode, as these connections prevent the service from sleeping.
2. No True Sleep API: The deploymentStop mutation completely stops the service, meaning:
   • Incoming requests cannot wake the service
   • Manual intervention is required to start
3. Cost Implications: Services that could benefit from reduced usage during off-hours (saving 30-50% on compute costs) are forced to run 24/7.

Proposed Solution

Implement a new deploymentSleep mutation and sleep state that:

mutation sleepDeployment($id: String!, $gracePeriodSeconds: Int) {
  deploymentSleep(id: $id, gracePeriodSeconds: $gracePeriodSeconds) {
    id
    status  # "sleeping"
  }
}

Expected Behavior

1. Graceful Sleep Process:
   • Send SIGTERM to allow graceful shutdown
   • Force-close database after grace period
   • Preserve deployment configuration and state
   • Mark as "sleeping" not "stopped" or "crashed"
2. Auto-Wake on Request:
   • Incoming HTTP requests trigger automatic wake
   • Brief "waking up" page while service starts
   • Seamless experience once running
3. Programmatic Control:
   • deploymentSleep - Put the service to sleep
   • deploymentWake - Manually wake service
   • Cron-compatible for scheduled sleep/wake cycles
4. Status Indicators:
   • Clear "sleeping" status in dashboard
   • No crash notifications for intentional sleeps
   • Metrics showing sleep/wake cycles and savings

Use Cases

• Business Hours Services: Internal tools used 9-5 can sleep overnight
• Development/Staging: Auto-sleep after inactivity
• Periodic Jobs: Sleep between scheduled runs
• Cost Optimization: 35-50% savings for services unused overnight/weekends