Railway services can exist globally while being absent from one environment

General lesson: in Railway, a service can exist at project scope while having no instance in a particular environment. In that state, adding environment variables alone does not enable scheduled execution; provision/sync the service instance, bind environment-local values through reference variables, deploy it, and verify the resolved cron manifest plus an actual successful run. This applies to persistent staging/production environments; it does not imply that copying one environment wholesale is safe. Avoid copying production credentials or endpoints into staging—reference the staging application service’s secret and domain instead. Rollback should remove only the target environment’s service instance, preserving the global service and other environments.

Evidence/example (2026-09-18): In the Shield Railway project, cron-prod existed globally and had a healthy production instance using /cron/railway.toml with */5 * * * *, while staging had no cron-prod service instance. The staging web service already held its own CRON_SECRET, so the recommended binding was CRON_SECRET=${{theft.CRON_SECRET}} and an environment-local ENDPOINT_URL based on the staging theft domain. No provider mutation was performed during the investigation.

Evidence: https://docs.railway.com/environments ; https://docs.railway.com/variables/reference