Skew Protection
Skew Protection stops a redeploy from breaking visitors who are already on the old version of your page. When you ship a new build, content-hashed asset filenames change; a browser still on the previous page may then request a JavaScript or CSS chunk that only the old deploy shipped, and 404 (a broken page or blank screen). With Skew Protection on, the edge serves that asset from the deploy the visitor's page came from.
It is a paid feature (the skew_protection entitlement) and is enabled per app with the skew_protection_enabled setting (see below). It is a per-app toggle only — there is no separate metrics or read endpoint.
How it works
- When the edge serves an app's HTML document, it sets a 24-hour
ngris_dplcookie pinning the current deploy (the cookie carries the deploy'suuid). - On that page's later asset requests (non-HTML files), the browser sends the cookie. If the asset is missing from the (now newer) current deploy, the edge retries the fetch against the pinned deploy — so the visitor doesn't 404 on a stale chunk.
- The pin only ever resolves a deploy that belongs to this app; a forged or expired pin simply misses and falls back to the current deploy. There is no per-request database write.
- It relies on deploy retention keeping the pinned deploy's build artifacts within the 24-hour cookie window; once a deploy is pruned, its pin falls back to current.
Skew Protection is most useful for static, SPA, and fullstack static front-ends built with content-hashed asset filenames (Vite, webpack, Next.js static export, and similar).
Enabling it
Turn Skew Protection on for an app by sending skew_protection_enabled: true to PUT /v1/applications/{uuid}. Enabling requires the skew_protection entitlement (a 403 otherwise); disabling is always allowed. The current state is returned as skew_protection_enabled on the application object (from GET /v1/applications/{uuid} and the list endpoint).
Errors
skew_protection entitlement (when enabling the setting).