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