We don't currently have built-in autoscaling based on queue depth, but you can achieve this using our Public API. The serviceInstanceUpdate mutation accepts a numReplicas field, so you can build a lightweight autoscaler that monitors your queue length and adjusts replicas (including down to 0) programmatically - see the API Cookbook for the exact mutation. The Serverless feature won't help here since it wakes services on inbound traffic, which doesn't apply to workers that pull from a queue.

Railway workers are meant to be long running services, so your concern is valid. A worker service is not the same as a cron style job that starts, finishes, and exits. Railway’s own guide describes background workers as always-on services, while cron jobs are the scheduled pattern that only run when triggered.

For your use case, the best pattern is usually:

1. Put jobs into a real queue Use Redis plus BullMQ, Celery, Sidekiq, or similar. Railway explicitly recommends Redis-backed queues for this setup. Your API enqueues jobs and your workers consume them.
2. Keep your worker tier separate from the API Railway supports scaling workers independently because they are separate services. Multiple worker replicas can all consume from the same Redis queue.
3. Do not expect native queue based scale-to-zero from Railway workers Railway supports vertical scaling automatically, but horizontal replicas are something you increase manually in service settings. Their docs describe replica scaling as manual, not queue-latency driven autoscaling.

So the practical answer is:

• If you need true scale-to-zero overnight, use a scheduled pattern, not a permanently running worker fleet. Railway cron jobs are the native option for tasks that can run on a schedule and exit.
• If you need event-driven queue consumers that wake up exactly when jobs arrive and drop back to zero automatically, Railway does not appear to provide that natively for worker replicas today.

What I would recommend in practice:

• Keep 1 small worker if you need low-latency daytime and nighttime processing.
• Add more replicas manually during expected busy windows.
• If your spikes are predictable, use scheduled scale-ups before peak hours and scale-downs after peak hours.
• If you want real queue-length autoscaling, use an external autoscaler. Judoscale is one example that explicitly supports Railway and background worker autoscaling from queue latency.

So the short answer is: Railway can do queue + workers well, but native worker services are not really designed as zero-at-night, ten-during-the-day queue consumers. For that, either use cron for scheduled batch work, or add an external autoscaling layer if you want dynamic worker counts.

Hello

worker services are always-on by default and will consume resources even when idle, the only native feature that can help is serverless mode , it automatically sleeps your service after 10 minutes of no outbound traffic. however the catch is that if your worker keeps an active connection to redis/queue broker it will likely prevent it from sleeping, so it may not work cleanly for your use case

and i think railway does not currently have built-in autoscaling based on queue depth. horizontal scaling is manual only (you set replica count yourself in the settings)

so for my information there's no out-of-the-box solution for this on railway right now. your best bet is to either try serverless mode and test if your worker actually sleeps when the queue is empty

Hope this help you :)