Solved Deploy sonrası cache temizlenmiyor

[tailadmin]

Vuejs projesinde build aldıktan sonra domain paneline girip cache temizleyene kadar eski sayfalar görünmeye devam ediyor.

 

[admin]

Hi, and thanks for the detailed report.

Short answer first: this is not something specific to Panelica — it is the normal behaviour of any SPA build (Vue, React, Svelte) sitting behind one or more caching layers. That said, we would like to be certain it is not us, so a little help from you would settle it quickly.

Why the hashed filenames are not the problem

Vite and Webpack deliberately give every build new filenames like index-ABC123.js. Because the name changes, a browser can never reuse the old file — it simply does not know about it. Panelica serves those hashed assets with Cache-Control: immutable, which is exactly right for content whose name changes on every build.

The file that actually matters is index.html

index.html never gets a hash. Its name stays the same, and it is the file that decides which JS bundle loads. So if a stale index.html is served, it points at yesterday's bundle and the whole page looks old — even though the new files are sitting on disk.

Panelica does not put a long-lived cache header on .html; our static-asset rule covers images, JS, CSS and fonts only. But other layers in front can, and usually that is where it comes from:

• Cloudflare — the most common cause. By default HTML is not cached, but a "Cache Everything" page rule or a cache setting on the zone will hold it. After each deploy you need to purge. You can do that from the CloudFlare tab in the panel in one click, or add a deploy step that calls the purge API.
• Browser heuristic caching — when a response carries no explicit Cache-Control, browsers are allowed to guess a lifetime from Last-Modified. That is enough to keep an old index.html around for a while.
• Service worker — if your project ships one (PWA plugin, Workbox), it can serve the previous shell until it updates itself, independently of everything above.

Where we would like your help

We want to rule out our own side properly rather than assume. Two things would tell us exactly which layer is holding it:

1. Is your site served as compiled static files (the contents of dist placed directly in public_html), or is it running as a Node application behind a reverse proxy? This matters: if it is the second and full-page caching is enabled for the domain, the HTML can be held server-side for 30 minutes — and in that case it is ours to adjust, not something you should have to work around.
2. The response headers for your index.html, right after a deploy:

curl -I https://yourdomain.com/index.html

The cache-control, age and cf-cache-status lines in that output identify the responsible layer immediately.

What usually removes the problem for good

Once we know which layer it is, the fix is normally a one-time setting rather than a manual purge after every deploy. If it turns out to be Cloudflare, a purge call at the end of your deploy script makes it disappear permanently. If it turns out to be on our side, we will correct it in the panel.

Send those two details whenever convenient and we will follow it through with you.

 

[tailadmin]

Deploy panelinde bir pipeline oluşturdum. deploy settingste deploy target: /home/xxx/deploy.

Beklediğim durum pull ile deploy klasörü içine dosyaları alıp, npm ci ile packages.lock'a uygun paketleri kurmak ve yine deploy içinde build alıp, 2. adımda oluşan dist klasörü içeriğini public_html'e kopyalamak. Bu süreçte public_html sıfırdan oluşmalı diye düşünüyorum fakat eski site görünüyor. Domain paneline girip-(panelica) cache clear yapmadıkça yeni build görünmüyor.

Pipeline
1.adım: npm ci && npm run build
2.adım: rsync -a dist/ /home/xxx/public_html

 

[admin]

Thanks for the extra details — this one is on our side, and there's a simple switch for it.

What's happening: your domain has Full-page Cache turned on. This is a speed feature: nginx keeps the pages your site returns for up to 30 minutes, so repeat visitors are served instantly without hitting PHP/Apache. It's built for WordPress and other CMS sites. For a Vue/SPA build it has a side effect: index.html (the file that decides which hashed JS bundle loads) is a normal 200 response, so nginx keeps it too. Your rsync replaces the file on disk, but the cached copy stays until it expires or you press Clear Cache — which is exactly why clearing it fixes things.

Where to turn it off (takes effect immediately, no downtime):

1. Go to Domains in your panel and open your domain.
2. Click Edit, then open the Web Server tab — the URL looks like https://your-panel:8443/domains/edit/<domain-id>#webserver.
3. Find the Full-page Cache card and switch it off.

The hashed assets (index-ABC123.js, CSS, images) still get their normal 30-day browser caching, so you lose nothing for a static build; full-page cache only ever helped dynamic PHP pages.

If you'd rather keep it on (for example a PHP backend on the same domain), press Clear Cache under Quick Actions on the domain's General tab after each deploy, or call the panel's clear-cache endpoint for the domain as a last pipeline step.

On our side: we're changing two things — a successful Git deploy will purge the domain's full-page cache automatically, and HTML entry files won't be held in the full-page cache anymore. Until that ships, the switch above is the fix.