A Telegram 409 Conflict for getUpdates means that the same bot token has more than one long-polling request in flight. One Railway service does not always mean one live process during a deployment: Railway starts the new container before removing the previous active deployment, and the two can overlap briefly.

Check these in order:

1. In Settings -> Scale, keep exactly one replica in one region.
2. In Settings -> Deploy -> Teardown, set Overlap time to 0 (or set RAILWAY_DEPLOYMENT_OVERLAP_SECONDS=0).
3. In the Deployments list, remove any older deployment that is still Active before retrying. Do not keep restarting both deployments.
4. Check that no local machine, worker service, preview environment, or second Railway service is running the same token.
5. Check Telegram's update mode without exposing the token:

https://api.telegram.org/bot<YOUR_TOKEN>/getWebhookInfo

If url is non-empty, either keep the webhook and stop polling, or call deleteWebhook once before using getUpdates. Never paste the real URL containing the token into this thread.

Telegram documents that getUpdates long polling and webhooks are mutually exclusive. Railway documents that the previous deployment is removed only after the new one comes online, with overlap controlled by the teardown setting:

• https://core.telegram.org/bots/api#getupdates
• https://core.telegram.org/bots/api#getwebhookinfo
• https://docs.railway.com/deployments/deployment-teardown
• https://docs.railway.com/deployments/reference#singleton-deploys

For a reliable hosted bot, a webhook is the cleanest fix because more than one container can receive HTTP traffic without competing for one polling lease. If you keep long polling, also handle SIGTERM by stopping the polling loop cleanly and retry a transient 409 after a short delay; a deploy-bound overlap should then clear when Railway removes the old container.

Changing the token alone is not a durable fix if two copies of the program receive the same replacement token or the code starts the polling loop twice.