your marker test proves the container serving those routes never receives the new files, and combined with git push not auto-deploying at all, this smells like a wiring issue not a cache issue. three things to check in order:

confirm the domain youre curling actually belongs to the service youre deploying. open that service → settings → networking and check the up.railway.app domain listed there matches the one youre testing. a duplicated service or second environment serving the domain while you deploy to the other explains every symptom, including "successful" deploys that change nothing.

check volumes. if theres a volume mounted at a path containing those two html files (or a parent folder like /app/public), the volume contents shadow whatever the new image ships. deploys succeed, files never change. settings → volumes, look at the mount path.

the git push thing: service → settings → source, check the repo/branch is right and no watch paths are filtering your changes out. separate misconfig but fix it while youre there.

maybe it's railway volume browse / railway volume files issue

File on disk is old → something is shadowing or excluding it at that path (volume mount is the prime suspect; .dockerignore/.railwayignore excluding those specific files from the build context is a secondary one).

File on disk is new but the response is old → it's not a filesystem problem at all. The route is served from somewhere else: an in-memory cache the app loads once at startup, a DB, external object storage, or an SSR cache.

if there's not volume

Check whether those two files match a pattern in .dockerignore or .railwayignore they can be committed yet excluded from the build context, leaving an older baked-in copy. And confirm you're curling and deploying the same service and environment: railway status to see the linked service/env, and verify the *.up.railway.app host you're hitting belongs to the service actually receiving these deploys

Thanks manuproject and adrianatdr for the thorough checklists — went through everything:

1. Domain match confirmed — ai-phone-builder-production.up.railway.app under Settings → Networking matches exactly what I've been testing. ariapos.cloud is correctly attached to this same service. No duplicate service/environment.

2. Volumes — none exist on this service.

3. Watch Paths — empty, no filtering.

4. .railwayignore — doesn't exist. (.dockerignore also confirmed absent earlier.)

5. railway status — confirms correctly linked: right project, right service (AI-Phone-Builder, marked primary), right environment (production), Online status.

Also re: the git-push-not-deploying symptom — "Auto deploys when pushed to GitHub" is toggled ON with the correct branch (main) selected, yet a plain git push genuinely doesn't trigger any deployment activity right now (confirmed via Deploy Logs showing nothing new). Only the Railway CLI or manual dashboard "Redeploy" trigger a build.

Really appreciate the detailed troubleshooting from both of you — everything you flagged checks out clean on my end. At this point I'm fairly confident this is something on Railway's side. Happy to share deployment IDs or any other diagnostic info that would help someone from the team take a closer look.

Try unlink and relink the github repo, then Deploy Latest Commit through the Command Palette

Thank you mayori. I just revaluated build and went a different direction. Thanks again!