Description of the issue: Service cycling-app in project generous-renewal shows a fully successful deployment (Initialization, Build, Deploy, Post-deploy, Network all green, marked ACTIVE), but the live root endpoint (GET /) keeps returning an old deployed version instead of the current one. This has persisted across multiple new deployments and two manual restarts. Error messages: None — there's no error or failed request. The endpoint responds normally with valid JSON; it just reflects an old version number instead of the currently deployed one. Troubleshooting already done: - Confirmed via two independent clients hitting the URL directly, ruling out local/client-side caching - CDN Caching confirmed OFF in the service's Edge settings - Manual restart of the active deployment attempted — no change - A second, unrelated deployment (triggered by a variable change) also didn't resolve it - GitHub source confirmed correct and matching the intended deployed version One thing worth checking: healthcheckPath in this service's railway.json is set to "/" — the same endpoint used to verify the version. Wondering if there's an edge case where the healthcheck marks a new deployment healthy while an old container instance keeps receiving some or all live traffic, rather than a full cutover. Link to GitHub repo: github.com/MTP1402/cycling-app

Hey I ran some analysis on your repo and it looks like your your APP_VERSION is hard coded to an older version. In `MTP1402/cycling-app`: ``` main.py line 4 # VERSION: 2.1.1 (2026-07-26) <- the comment you have been updating main.py line 241 APP_VERSION = "1.7.0" <- what is actually served main.py line 1123 @app.get("/") main.py line 1125 return {"status": "Cycling Coach API running", "version": APP_VERSION} ``` So to fix it just update the version manually: 1. Open `main.py` and change line 241: ```python APP_VERSION = 2.1.1 ``` 2. Commit and push. Your service redeploys on push, or use Command Palette (Ctrl-K) → Deploy Latest Commit. 3. Open your service URL. `/` should now return `"version":"2.1.1"` You can also automate the versioning tags with github actions https://github.com/marketplace/actions/tag-version. I think it'd make your developer experience a bit better :)

Successful deployment not being served - stale version persists after multiple redeploys

mtp1402

HOBBYOP

a month ago

Description of the issue:

Service cycling-app in project generous-renewal shows a fully successful deployment (Initialization, Build, Deploy, Post-deploy, Network all green, marked ACTIVE), but the live root endpoint (GET /) keeps returning an old deployed version instead of the current one. This has persisted across multiple new deployments and two manual restarts.

Error messages:

None — there's no error or failed request. The endpoint responds normally with valid JSON; it just reflects an old version number instead of the currently deployed one.

Troubleshooting already done:

Confirmed via two independent clients hitting the URL directly, ruling out local/client-side caching
CDN Caching confirmed OFF in the service's Edge settings
Manual restart of the active deployment attempted — no change
A second, unrelated deployment (triggered by a variable change) also didn't resolve it
GitHub source confirmed correct and matching the intended deployed version

One thing worth checking: healthcheckPath in this service's railway.json is set to "/" — the same endpoint used to verify the version. Wondering if there's an edge case where the healthcheck marks a new deployment healthy while an old container instance keeps receiving some or all live traffic, rather than a full cutover.

Link to GitHub repo:

github.com/MTP1402/cycling-app

Solved$10 Bounty

Pinned Solution

brezzy1337

HOBBYTop 10% Contributor

25 days ago

Hey I ran some analysis on your repo and it looks like your your APP_VERSION is hard coded to an older version.

In MTP1402/cycling-app:

main.py line    4   # VERSION: 2.1.1  (2026-07-26)    <- the comment you have been updating
main.py line  241   APP_VERSION = "1.7.0"             <- what is actually served
main.py line 1123   @app.get("/")
main.py line 1125   return {"status": "Cycling Coach API running", "version": APP_VERSION}

So to fix it just update the version manually:

Open main.py and change line 241:
```
APP_VERSION = 2.1.1
```
Commit and push. Your service redeploys on push, or use Command Palette (Ctrl-K) → Deploy Latest Commit.
Open your service URL. / should now return "version":"2.1.1"

You can also automate the versioning tags with github actions https://github.com/marketplace/actions/tag-version. I think it'd make your developer experience a bit better :)

3 Replies

Railway

BOT

a month ago

This thread has been opened as a bounty so the community can help solve it.

Status changed to Open Railway • 26 days ago

mayori

MODERATOR

a month ago

Try Deploy Latest Commit

Open your service > Open the Command Palette (Ctrl-K) > Select Deploy Latest Commit

If that didn't work, Try disable the Build Cache by adding NO_CACHE=1 to the Service Variables

Also, Nixpacks is deprecated, I would recommend you to use Railpack instead, You can change it by opening your Service Settings, scroll to the Build section and you can change the Builder there

brezzy1337

HOBBYTop 10% Contributor

25 days ago

Hey I ran some analysis on your repo and it looks like your your APP_VERSION is hard coded to an older version.

In MTP1402/cycling-app:

main.py line    4   # VERSION: 2.1.1  (2026-07-26)    <- the comment you have been updating
main.py line  241   APP_VERSION = "1.7.0"             <- what is actually served
main.py line 1123   @app.get("/")
main.py line 1125   return {"status": "Cycling Coach API running", "version": APP_VERSION}

So to fix it just update the version manually:

Open main.py and change line 241:
```
APP_VERSION = 2.1.1
```
Commit and push. Your service redeploys on push, or use Command Palette (Ctrl-K) → Deploy Latest Commit.
Open your service URL. / should now return "version":"2.1.1"

You can also automate the versioning tags with github actions https://github.com/marketplace/actions/tag-version. I think it'd make your developer experience a bit better :)

mtp1402

HOBBYOP

25 days ago

@brezzy1337 — you got it exactly right, confirmed directly against the file. Line 241 was hardcoded to 1.7.0 while the comment above it said 2.1.1 — two separate things that needed two separate updates, and only one was actually happening for a while. Fixed now, redeploying.

Correcting my last update too, since it was wrong: there was never a caching issue isolated to /, and never a Railway platform problem at all. Every deployment tonight genuinely succeeded and took effect correctly — I just had a stale version string in my own code that made it look otherwise. Sorry for the noise on this thread while I chased the wrong explanation.

Appreciate you actually digging into the repo rather than just guessing — that's what actually solved it. Accepting this as the solution.

Status changed to Solved brody • 21 days ago

Welcome!