Problem
After a deployment, users keep seeing the old version of the platform. They have to manually clear their browser cache (or hard refresh) to get the new version.
Cause
Nginx does not send any Cache-Control header. Browsers then apply heuristic caching to index.html, which references the JS bundles by their old hashed names. As long as this stale index.html stays in cache, the user loads the old application.
The runtime config file config/app-config.js (not content hashed) has the same problem.
Proposed solution
In nginx/default.conf:
Cache-Control: no-cache on location /: index.html and app-config.js are revalidated on every load (304 response if unchanged, so nearly free)Cache-Control: public, max-age=31536000, immutable on location /assets/: Vite bundles are content hashed, they can be cached indefinitely
Note
The fix takes effect on the next deployment. Users who already have a stale index.html in cache will need to refresh one last time, after that updates will be automatic.
Problem
After a deployment, users keep seeing the old version of the platform. They have to manually clear their browser cache (or hard refresh) to get the new version.
Cause
Nginx does not send any
Cache-Controlheader. Browsers then apply heuristic caching toindex.html, which references the JS bundles by their old hashed names. As long as this staleindex.htmlstays in cache, the user loads the old application.The runtime config file
config/app-config.js(not content hashed) has the same problem.Proposed solution
In
nginx/default.conf:Cache-Control: no-cacheonlocation /:index.htmlandapp-config.jsare revalidated on every load (304 response if unchanged, so nearly free)Cache-Control: public, max-age=31536000, immutableonlocation /assets/: Vite bundles are content hashed, they can be cached indefinitelyNote
The fix takes effect on the next deployment. Users who already have a stale
index.htmlin cache will need to refresh one last time, after that updates will be automatic.