The Config File Path on your worker service is saved correctly as /backend/railway.worker.json, but the deployment is falling back to the root /railway.json because Railway could not find a file at that path in your repository. When the specified config file does not exist, Railway resolves to the default railway.json or railway.toml at the repo root, which is why your worker picks up the api's start command. Confirm that a file named exactly railway.worker.json exists at /backend/railway.worker.json in your repo (the path is absolute from the repo root, not relative to any root directory setting), and that it contains the celery start command you want.

Subject: Config File Path setting not applied to deployments (service "worker" always resolves api's config)

Project: m2rplace (c30aed6a-f1c8-44c1-a5a1-4797ef753066)

Environment: production (dde151a5-9719-41fa-ba2e-ccea854f59ba)

Service: worker (7b5fce3f-caf5-419b-aed2-4bac9a84b4b1)

Issue

Config File Path for "worker" is set to /backend/railway.worker.json (confirmed present in repo, contains startCommand: "celery -A workers.celery_app worker --loglevel=info -c 4"). Every deployment still resolves and runs the sibling service's config instead (/railway.json, belonging to "api").

Confirmed via railway status --json: meta.configFile reports /railway.json on all 3 fresh deployments after the setting was saved. Confirmed via railway ssh --service worker "cat /proc/1/cmdline": container runs uvicorn main:app (api's command) instead of celery.

Deployment IDs affected (all after the Settings change)

• a413a473-395e-443a-9507-1d15b85571d3 (04:42:24Z)
• 70e748e9-8da9-4f91-bf78-bfb4e27c3ad9 (05:00:39Z)
• 6dd9de19-6796-4e5d-b157-48043e7f6676 (05:11:54Z, via railway redeploy)

Additional detail: meta.serviceManifest.build.builder reports DOCKERFILE, while meta.fileServiceManifest.build.builder (from the resolved config) reports NIXPACKS — a builder-detection mismatch, noting for completeness.

Impact

This service has never run Celery since setup on 2026-08-10 — queued tasks in Redis are never consumed.

What we've tried

• railway up --service worker --path-as-root (same result)
• NIXPACKS_START_CMD env var (ignored — build uses DOCKERFILE, not Nixpacks)
• Editing "Custom Start Command" in dashboard while Config File Path was set (saves but has no effect)
• Correcting Config File Path to /backend/railway.worker.json (current) — still resolves to /railway.json
• 3 independent forced redeploys after correction — identical result each time

Counter-example ruling out "no connected source"

Support bot suggested Railway can't find the file because no source is connected. Checked via railway service list --json:

api    -> source: None

beat   -> source: None

worker -> source: None

All 3 services share source: None (confirmed: no GitHub integration, all deploys manual via railway up). But this can't be the actual cause — beat is under identical conditions and its Config File Path (/backend/railway.beat.json) resolves correctly. Verified today by forcing beat's first redeploy since 08-10: railway ssh --service beat "cat /proc/1/cmdline" confirmed it runs celery -A workers.celery_app beat exactly as configured.

If "no connected source" broke resolution generally, beat would show the same symptom — it doesn't. This points to something specific to worker's stored Config File Path record (possibly stale/corrupted from creation on 08-10), not a project-wide issue.

Could someone compare the internal Config File Path resolution record for worker (7b5fce3f-caf5-419b-aed2-4bac9a84b4b1) against beat (2c19a500-55cf-4d1e-ad40-ea24d09375ca) in the same project/environment? Both are configured identically from our side. Happy to provide more logs/deployment IDs.