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

2 months 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

PRO

2 months 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

2 months ago

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

Status changed to Open Railway • 2 months ago

mayori

MODERATOR

2 months 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

PRO

2 months 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

2 months 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 • 2 months ago

Welcome!