Persistent startCommand Override for Cron Service in Nixpacks Monorepo
asafcha
HOBBYOP

2 months ago

Hello Railway Support Team,

We are experiencing a persistent issue with a cron-based service in our Python monorepo and would appreciate your guidance.

Our Goal: We have a service named universe-builder that is designed to run a cron job. To achieve this, we need its container to stay alive with a simple, long-running startCommand. The project is configured to use the Nixpacks builder and is managed via a railway.json file.

The Problem: No matter what we set as the startCommand for the universe-builder service in our railway.json, the Railway platform ignores it. Instead, it consistently tries to run the start command from our main web service (uvicorn main:app...). This causes the container to start a web server, which then fails the platform's health checks and is shut down, creating a deployment loop.

We have confirmed that the "Custom Start Command" in the service's UI settings is empty. The railway.json file is the source of truth.

Troubleshooting Steps We've Taken:

  1. Initial Attempt (sleep infinity): Our first startCommand was "sleep infinity". This caused the container to crash immediately with an OverflowError: timestamp out of range for platform time_t. This indicates the command was being read initially.

  2. Finite Sleep (sleep 2147483647): To solve the overflow, we used a large integer. At this point, the behavior changed: the platform began ignoring this command and started launching the Uvicorn web server instead, leading to the health check failures.

  3. Standard Commands (tail -f /dev/null): This standard command was also ignored, with the platform still launching Uvicorn.

  4. Python Keep-Alive Script: We created a dedicated keep_alive.py script. This was also ignored, and the platform launched Uvicorn.

  5. Builder Switch (Procfile & BUILDPACKS): We attempted to switch to a Procfile and the Heroku Buildpacks builder. This resulted in a catastrophic failure of all services in our monorepo, so we have reverted to Nixpacks.

Our Question: Why is the Nixpacks builder ignoring the specific startCommand for our non-web universe-builder service and forcing it to use the command from our web service? What is the officially recommended method to run a non-web, background service for cron jobs within a monorepo on your platform using Nixpacks?

We seem to be stuck in a configuration loop and would be very grateful for your help.

Thank you.

$10 Bounty

3 Replies

Railway
BOT

2 months ago

Hey there! We've found the following might help you get unblocked faster:

If you find the answer from one of these, please let us know by solving the thread!

brody
EMPLOYEE

2 months ago

This thread has been marked as public for community involvement, as it does not contain any sensitive or personal information. Any further activity in this thread will be visible to everyone.

Status changed to Open brody • about 2 months ago

asafcha
HOBBYOP

2 months ago

Following up on my previous ticket regarding the startCommand override issue with our non-web services.

Thank you for the automated response and the links to the documentation. We have thoroughly reviewed the "Deploying a Monorepo" guide. Based on that guide and standard best practices, we have prepared a significant architectural change on a new, separate Git branch (restructure-services).

The changes we've prepared are as follows:

  1. Restructured the project: Each service (web, worker, universe-builder, etc.) has been moved into its own isolated subdirectory (e.g., services/web/, services/worker/).

  2. Isolated dependencies: Each service directory now contains its own requirements.txt file.

  3. Provided explicit build instructions: We have added a nixpacks.toml file inside each service's subdirectory, containing an explicit start command to prevent any auto-detection conflicts.

  4. Updated railway.json: The configuration now points to the correct rootDirectory for each isolated service.

This was done to provide a clear and unambiguous context to the Nixpacks builder, which we believe is incorrectly identifying all services as web services.

However, given the multiple failures we've experienced and the significant nature of this architectural change, we are currently holding off on pushing this new branch and deploying it.

We are waiting for a response from a support engineer to review our situation and confirm if this is indeed the correct path forward. Could you please look into our ticket and provide your expert guidance?

We are standing by.

Thank you.

sarangsohail
FREE

2 months ago

Hey there, thanks for your patience.

I think I see the issue. Nixpacks is scanning your whole monorepo and auto-detecting your web service's uvicorn command, then applying it to all services. That's why it keeps launching the web server instead of your keep-alive command.

Your restructure with isolated service directories should fix this. When you set the Root Directory in each service's settings (like services/universe-builder), Nixpacks will only look at that folder and won't see the web service code.

Make sure each service has:

  • Root Directory set in dashboard (e.g., services/universe-builder)

  • Its own nixpacks.toml with explicit start command

Just a heads up, Nixpacks is deprecated now. Railway recommends Railpack for new services. Since you're restructuring anyway, might be worth switching to avoid future issues.

Loading...