3 months ago
I’m reaching out regarding a production issue we’re experiencing with our application, WorkLid, which is currently hosted entirely on Railway.
We have a distributed development setup where a developer working remotely pushes frontend and backend changes directly through Railway. After a deploy completes successfully, the developer is able to see the updated features immediately. However, on my end—and more importantly for some users—we are not consistently seeing the latest updates unless the browser cache is cleared or the site is opened in an incognito window.
This is a major concern for us because it suggests that end users may not reliably see new features or bug fixes after deployment, and they would have no reason to manually clear their cache.
Here is what we are observing:
Static assets are served directly via Railway (no external CDN such as Cloudflare or Vercel).
The issue primarily affects frontend UI changes, including HTML templates and CSS/JS updates.
Backend behavior is less clear, but the main inconsistency is on the frontend.
We deploy directly to production from our main branch.
A hard refresh (Cmd + Shift + R) does not always resolve the issue.
Opening the site in an incognito window usually shows the updated version immediately.
We are not knowingly setting custom cache headers (Cache-Control, ETag, max-age), but we are unsure if defaults are being applied at the platform level.
From our perspective, this feels like either:
aggressive browser or platform-level caching of static assets, or
missing cache invalidation / cache-busting on deploys (e.g., unversioned static files being reused).
Because this directly impacts user experience and feature rollout reliability, we’d really appreciate guidance on:
Whether Railway applies any default caching behavior for static assets or frontend responses
How cache invalidation is handled on deploys
Best practices or recommended configuration to ensure users always receive the latest frontend assets after a deploy
Whether there is a Railway-side setting or header configuration we should be adjusting
Our goal is to make sure that every production deploy reliably reflects for all users without requiring cache clears or incognito mode.
Happy to provide logs, headers, or environment details if that would help diagnose the issue further.
Thank you in advance for your help — we’re eager to resolve this quickly since we already have active users on the platform.
Best regards,
Abdullah Alakashi
Founder, WorkLid
2 Replies
3 months ago
To answer your questions:
1. the railway edge does not cache any requests
2. no invalidation needed, see #1
3. This would come from setting cache headers from your app (to control how the browser caches assets) and implementing version-based cache busting (like hashing the filenames via a bundler, to avoid the same app.js filename for 2 app versions)
this would be an app-level configuration.
I'm going to open your thread for community contributions and attach a bounty so that our community can help you fix these issues.
Status changed to Awaiting User Response Railway • 3 months ago
3 months ago
This thread has been marked as public for community involvement, as it does not contain any sensitive or personal information. Any further activity in this thread will be visible to everyone.
Status changed to Open itsrems • 3 months ago
3 months ago
What language is your site created in?
If you're using Vite, the files such as app.js and styles.css should already have a hash in them (e.g. app.9f3a2c.js and styles.a18d44.css), if they don't - check that is isn't disabled in vite.config.js.
If you're using Webpack, then make sure that your output is set to
output: {
filename: '[name].[contenthash].js',
assetModuleFilename: '[name].[contenthash][ext]'
}