Hi all,
I’m running into an issue with an NGINX web server on a DigitalOcean Droplet where, after a new deployment, some users are still seeing old cached content even though the files on disk are updated. This seems to affect CSS/JS and some template files.
Here’s the setup:
• Ubuntu 22.04 droplet
• NGINX 1.18 configured with expires headers for static assets
• No CDN in front of the server (just Cloudflare DNS)
• PHP backend (FastCGI) serving dynamic content
After pushing a new release (updated CSS and template changes), everything looks correct when I test directly on the server or with curl, but some visitors report seeing the old styles and minor layout issues. Restarting NGINX doesn’t seem to fix it for all users immediately, and I’m not sure if this is being cached at the browser level, somewhere in NGINX, or both.
What I’ve tried so far:
• Clearing NGINX fastcgi cache (if any)
• Setting add_header Cache-Control no-cache for testing
• Bumping static asset filenames with version query params
Still, recurring complaints about stale content persist.
For context, I manage deployments for sites like Rincon Family Dentistry, and consistent user experience across deploys is important to us, so I’m trying to understand reliable cache control practices here.
Has anyone dealt with late‑cache issues like this on a DigitalOcean Droplet with NGINX? Are there NGINX settings or best practices you recommend to ensure updated content is served immediately after a deploy?
Thanks in advance!
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
Heya, @9f9b6925bf62424c8c549899d6768c
If curl shows the new files but users still see old CSS/JS, this is almost certainly browser caching, not NGINX.
Restarting NGINX won’t fix it because browsers are honoring your expires headers. If you deploy a new style.css with the same filename, users who already cached it will keep using the old version until it expires.
The reliable production solution is filename versioning (cache busting). Instead of:
/style.css?v=2
Use hashed filenames like:
/style.abc123.css
Generate the hash during your build process so every deploy produces new filenames. Then you can safely keep long cache headers:
location ~* \.(css|js|png|jpg|svg|woff2?)$ {
expires 1y;
add_header Cache-Control "public, immutable";
}
Do not set long caching on dynamic PHP responses.
If Cloudflare is orange-cloud (proxied), also confirm caching is disabled there.
Regards
Become a contributor for community
Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation.
DigitalOcean Documentation
Full documentation for every DigitalOcean product.
Resources for startups and AI-native businesses
The Wave has everything you need to know about building a business, from raising funding to marketing your product.
The developer cloud
Scale up as you grow — whether you're running one virtual machine or ten thousand.
Get started for free
Sign up and get $200 in credit for your first 60 days with DigitalOcean.*
*This promotional offer applies to new accounts only.