Version skew occurs when different versions of your application run on client and server, causing application errors and other unexpected behavior. For example, imagine your newest deployment modifies the data structure by adding a required field to a user's profile. Older clients wouldn't expect this new field, leading to errors when they submit it.
Vercel's Skew Protection resolves this problem at the platform and framework layer by using version locking, which ensures client and server use the exact same version. In our example, outdated clients continue to communicate with servers that understand the old data structure, while updated clients are served the most recent deployment.

By implementing Skew Protection, you can reduce user-facing errors during new rollouts and boost developer productivity, minimizing concerns about API compatibility across versions.
- To use Skew Protection, you must opt-in
- Skew protection is available on Next.js version 13.4.7 or newer. The Skew Protection platform primitive is available to all frameworks
- Currently, Skew Protection can manage version skew for deployments up to a day old (24 hours). Custom durations are on our roadmap for future updates.
- Currently, you cannot deny-list a specific deployment (for example, one which should not be served due to severe bugs), but it's on our roadmap for future updates.
Ensure you are using Next.js 13.4.7 or newer
Add
useDeploymentId: true
flag to theexperimental
section of your project’snext.config.js
file:next.config.js/** @type {import('next').NextConfig} */ const nextConfig = { experimental: { useDeploymentId: true, // If use with serverActions is desired serverActions: true, useDeploymentIdServerActions: true, }, }; module.exports = nextConfig;
This activates the feature for all framework-managed static file requests from your Next.js app such as for JS and CSS files. Our expectation is that a future version of Next.js will turn this on, by default.
Additionally, if you use Next.js Server Actions, you can opt-into Skew Protection by adding
useDeploymentIdServerActions:true
. We’re planning to extend support to additional request types in the future.
You can experiment with per-request opt-in today by reading the deployment id from process.env.NEXT_DEPLOYMENT_ID
and passing it through fetch
requests on the X-Deployment-Id
header:
const r = await fetch('/get', {
headers: {
// Ensures the request will be handled by the expected
// deployment.
'X-Deployment-Id': deploymentId,
},
});
We are planning to support automatic Skew Protection for additional request-types in the future.
Was this helpful?