After deploying a new version of the AutoBot frontend, users may continue to see the old version due to browser caching. This guide explains why this happens and how to resolve it.
Modern browsers aggressively cache static assets (JavaScript, CSS, images) to improve performance. Even though our nginx configuration is designed to prevent caching of HTML files and force revalidation, browsers may:
- Ignore or misinterpret cache headers in certain scenarios
- Cache service worker registrations that continue serving old assets
- Use disk cache even when memory cache is cleared
- Persist cached assets across browser restarts
Method 1: Hard Refresh (Fastest)
- Press
Ctrl + Shift + R(Windows/Linux) orCmd + Shift + R(macOS) - This forces Chrome to bypass cache for the current page
Method 2: Clear All Cached Data (Most Thorough)
- Press
Ctrl + Shift + Delete(Windows/Linux) orCmd + Shift + Delete(macOS) - Select "All time" from the time range dropdown
- Check only "Cached images and files"
- Click "Clear data"
- Reload the page (
F5orCtrl + R)
Method 3: DevTools Cache Clear
- Open DevTools (
F12) - Go to the Network tab
- Right-click on any network request
- Select "Clear browser cache"
- Reload the page
Method 1: Hard Refresh
- Press
Ctrl + Shift + R(Windows/Linux) orCmd + Shift + R(macOS)
Method 2: Clear Cache
- Press
Ctrl + Shift + Delete(Windows/Linux) orCmd + Shift + Delete(macOS) - Select "Everything" from the time range
- Check only "Cache"
- Click "Clear Now"
- Reload the page (
F5)
Method 1: Hard Refresh
- Press
Cmd + Option + R
Method 2: Clear Cache
- Go to Safari → Settings → Privacy
- Click "Manage Website Data..."
- Search for your AutoBot domain
- Click "Remove" then "Done"
- Reload the page
For quick testing without clearing cache:
- Chrome/Edge:
Ctrl + Shift + N(Windows/Linux) orCmd + Shift + N(macOS) - Firefox:
Ctrl + Shift + P(Windows/Linux) orCmd + Shift + P(macOS) - Safari:
Cmd + Shift + N
Navigate to the AutoBot URL in the private window. If the new version loads correctly, the issue is cache-related.
After clearing cache, verify you're seeing the new deployment:
- Open DevTools (
F12) - Go to the Network tab
- Reload the page
- Look for JavaScript files like
index-[HASH].js - The hash should match the latest deployment (compare with
dist/index.htmlon the server)
Example:
OLD: /assets/index-BcXl2NoH.js
NEW: /assets/index-DfGh3KpL.js ← Hash changed = new build
If the frontend logs its version on startup, check the browser console:
- Open DevTools (
F12) - Go to the Console tab
- Look for version/build information in the startup logs
- Open DevTools (
F12) - Go to the Network tab
- Reload the page
- Click on
index.html - Check the Response Headers for
Last-ModifiedorETag - Compare with the server's deployment timestamp
Our nginx configuration applies different cache strategies based on file type:
Cache-Control: no-store, no-cache, must-revalidate, proxy-revalidate, max-age=0no-store: Don't store this response in any cacheno-cache: Revalidate with server before using cached copymust-revalidate: Can't serve stale cache, must check servermax-age=0: Expires immediately
Result: Browser fetches fresh HTML on every request.
Cache-Control: public, immutable, max-age=31536000public: Can be cached by any cache (browser, CDN, proxy)immutable: Content will NEVER change (safe to cache forever)max-age=31536000: Cache for 1 year (31536000 seconds)
Result: Once cached, these files are served instantly from cache. Since filenames include content hashes (e.g., index-BcXl2NoH.js), new deployments generate new filenames, automatically bypassing cache.
- User requests
https://autobot.example.com/ - Browser fetches
index.html(no-cache → always fresh) index.htmlreferences<script src="/assets/index-DfGh3KpL.js">- If hash is new, browser fetches new JS (cache miss)
- If hash is same, browser uses cached JS (cache hit)
The problem: If the browser somehow cached the old index.html, it will reference old asset hashes, serving the old version entirely.
The current configuration (deployed via Ansible) includes:
# Enable ETag support for cache validation
etag on;
# HTML files - NEVER cache
location ~* \.html$ {
add_header Cache-Control "no-store, no-cache, must-revalidate, proxy-revalidate, max-age=0";
add_header Pragma "no-cache";
add_header Expires "0";
if_modified_since off;
}
# JS/CSS with hash - cache forever
location ~* \.(js|css)$ {
expires 1y;
add_header Cache-Control "public, immutable, max-age=31536000";
}To minimize cache-related issues after deployments:
cd autobot-slm-backend/ansible
ansible-playbook -i inventory/inventory.yml playbooks/deploy-frontend.yml --tags frontend,nginxThis ensures:
- Old files are removed from
dist/before new ones are copied - Nginx is reloaded with updated configuration
- Proper file permissions are set
ssh autobot@<frontend-ip>
ls -lh /opt/autobot/autobot-frontend/dist/
cat /opt/autobot/autobot-frontend/dist/index.htmlCheck that:
- Deployment timestamp matches your build
- Asset hashes in
index.htmlare new
Before announcing deployment, test in incognito mode to verify cache doesn't interfere.
Include the asset hash or build timestamp in release notes so users can verify they're running the latest version.
Possible causes:
- Service Worker caching: Unregister service workers in DevTools → Application → Service Workers
- Proxy/CDN caching: If there's a proxy between users and nginx, it may cache responses
- Browser extensions: Ad blockers or privacy extensions may interfere with cache headers
- Old browser version: Update browser to latest version
Possible causes:
- DNS caching: Old IP may be cached in DNS if infrastructure changed
- Load balancer caching: If using a load balancer, it may cache responses
- Mixed deployments: Verify all frontend servers are updated (if using multiple)
This is expected behavior: Hard refresh bypasses cache, normal reload respects cache headers. If normal reload serves old content, the cache headers may not be correctly applied.
Debug steps:
- Check network tab: Is
index.htmlshowing200(from cache) or304(revalidated)? - Verify nginx config is applied:
sudo nginx -ton the frontend server - Check nginx access logs:
sudo tail -f /var/log/nginx/autobot-frontend-access.log
If cache clearing doesn't resolve the issue:
- Verify deployment: Check that new files are actually on the server
- Check nginx logs: Look for errors in
/var/log/nginx/autobot-frontend-error.log - Test with curl:
curl -I https://autobot.example.com/to see raw headers - Create GitHub issue: Include browser version, console errors, and network tab screenshots