Vercel’s October change gives existing Pro teams two separate things to check: the start of billing for Deployment Storage and Functions Storage, and the retention window for older deployments. The storage charge starts on a team-specific date that Vercel says it will send by email. The retention change has a shared deadline: starting October 23, deployments older than 30 days will be deleted under the policy unless the team opts out in its retention settings beforehand.
Treat these as different decisions. The Usage page helps you see how much storage each project uses. The Deployment Retention Policy controls how long deployment states remain available. Shortening retention can reduce stored history, but a deployment that is deleted can no longer be used for rollback. Check the projects and release histories that matter before the deadline.
What changes for existing Pro teams
Vercel’s 9 October changelog says billing for Deployment Storage and Functions Storage will begin for all Pro teams. It does not set one start date for every team: Vercel says to check the email sent to your team for the start date that applies to you. Do not infer your date from another team’s invoice or from the October 23 retention deadline.
The same announcement says that the deployment retention window changes to 30 days on October 23. Deployments older than 30 days will be deleted starting then unless you opt out in retention settings before that date. If your settings already retain deployments for 30 days or less, Vercel says they are unchanged by this transition.
The 30-day change concerns deployment history. Storage reporting is separate: Vercel says the Usage page shows Deployment Storage and Functions Storage by project. That distinction matters when one large project accounts for most of a team’s stored output, or when several projects have different release and rollback needs. Review the per-project amounts rather than treating the team as if every project consumes the same amount.
Check the settings that apply to each project
Start with the Deployment Retention Policy. Vercel’s changelog specifically tells teams to review the retention periods for Pre-Production, Production, Canceled, and Errored deployments. Open the project’s Settings, then Security, and find the Deployment Retention Policy. Check what is configured for each deployment state and whether it matches the history your team still needs.
Do this project by project. A production service with frequent releases may need a longer rollback history than a temporary preview project. A canceled or errored deployment may have different troubleshooting value from a successful production release. The right window depends on how your team investigates incidents, reviews releases, and restores service; there is no single duration that fits every project.
Also check the policy exceptions documented by Vercel. On Pro and Enterprise plans, the latest ten deployments created, the latest twenty Ready production deployments, and the latest twenty Ready non-production deployments are protected from the ordinary retention interval. Aliased deployments and the latest preview for an active Git branch also have documented exceptions. These protections can preserve selected history, but they are not a reason to skip the policy review: deployments outside the protected set can still age out.
If the team needs a deployment for rollback or investigation beyond the current window, decide before the deadline whether to retain it under a longer policy or preserve the relevant release material elsewhere. Vercel says deleted deployments cannot be used for rollback. Don’t build the incident plan around an old deployment remaining available after it falls outside your chosen retention period.
Read storage usage separately from retention
Open the Usage page and review Deployment Storage and Functions Storage for each project. Record which projects account for the largest amounts and whether those amounts are expected. This is a useful baseline before changing retention or reducing future deployment output. The Usage page is a measurement surface; it does not by itself tell you whether a project’s rollback policy is appropriate.
For a project with unexpectedly large deployments, inspect the build output and function bundles. Vercel’s changelog suggests removing unnecessary build files, moving large assets to Vercel Blob, and shrinking Function bundles to reduce future deployment size. Those are changes to future output. They do not substitute for deciding how much past deployment history the team needs to keep.
Do not assume that reducing retained history and shrinking future artifacts solve the same problem. A short retention window changes how long deployments remain available. A smaller deployment changes how much output each new deployment contributes. Check both the current per-project usage and the project’s future build contents, then choose the action that matches the source of the storage.
Make a rollback plan before changing retention
For every production project, identify the releases the team expects to roll back to and the oldest release that might still be needed during an incident. Compare that history with the policy currently set for Production. If your team needs more than the 30-day window, Vercel’s new-team announcement says teams can choose a longer period in settings; the existing-team announcement says to opt out in retention settings before October 23 if the new 30-day window is not suitable.
Then inspect your non-production projects. Preview history can matter when a branch remains active, while canceled and errored builds may matter for debugging a deployment failure. Consider those states on their own rather than applying the production choice everywhere. Vercel’s documentation lists exceptions that keep some deployments regardless of the normal retention interval, but a general retention rule still determines what happens to the rest.
Write down the owner for each project’s decision and the date it was checked. If a deployment must remain available for a release, incident, or audit, confirm that the policy protects it. If you do not need older history, shorter retention may be appropriate; if you do, opt out or select a longer period before the deadline. A deleted deployment is not a dependable rollback target.
A short review before October 23
Use this sequence for each project:
- Check the team email for the storage-billing start date. It varies by team.
- Open Usage and note Deployment Storage and Functions Storage for the project.
- Review the Deployment Retention Policy for Pre-Production, Production, Canceled, and Errored deployments.
- Identify releases the team may need for rollback or investigation, including any older than 30 days.
- Check the documented exceptions, then opt out or choose a longer retention period before October 23 if the default window does not fit.
- Look for large build files, assets, or function bundles that can be reduced in future deployments.
- Recheck the project after saving the policy and make sure the team knows which older deployments will no longer be available.
Keep billing and retention in separate notes. The billing start date comes from Vercel’s email to your team. The retention deadline is October 23. The Usage page shows project-level storage, while the policy determines which deployment history remains. This review lets a team make the storage decision with its own usage and rollback needs in view.
If you are also sizing isolated workspaces for coding agents, our separate guide to Vercel Sandbox storage covers that product’s disk capacity; it is not the same as Deployment Storage for projects.
Top comments (1)
tr.ee/dev-to