Vercel Deployment Retention: What Changes on 23 October

The short answer: what happens on 23 October

Vercel deployment retention for existing Pro teams changes to 30 days. Per Vercel's 9 October changelog, deployments older than 30 days will be deleted starting 23 October 2026 unless you opt out in your retention settings before then. Settings already at 30 days or shorter are unchanged, and deleted deployments cannot be used for rollback [1].

The same notice says Deployment Storage and Functions Storage billing will begin for all Pro teams at $0.10 per GB-month. Vercel does not give one start date: it says to check the email sent to your team for when billing starts for you [1]. New Pro teams already default to a 30-day retention period [2].

That is the confirmed part. What the headline does not tell you is how much of your history is actually exposed, which depends on a list of exceptions in Vercel's docs.

What Vercel keeps even after 30 days

Vercel's retention documentation lists exceptions. A deployment is kept while any of them is true. On Pro and Enterprise these include the last 10 deployments created in a project, the last 20 production deployments in a Ready state, and the last 20 non-production deployments in a Ready state [3].

On every plan, a deployment with a production alias is kept, a deployment that is the target of a custom-environment branch alias is kept, a non-production deployment with any custom alias is kept, and the latest preview deployment of a Git branch that is still active is kept. A branch counts as active until it is deleted or its pull request is merged or closed [3].

Our reading, not Vercel's wording: your live production site and your most recent rollback targets are covered by these exceptions. What is exposed is the long tail, such as an old preview you want to reopen to reproduce a bug, a release from four months ago you need to inspect for an audit, or a rollback target older than your last 20 production builds. If a project ships rarely, 30 days may delete very little. If it ships many times a day, the 20-deployment exceptions can be used up within days, and that is where the new window starts to bite.

Deleted does not always mean gone: recovery and timing

Vercel's docs describe a recovery period. When a deployment passes its retention limit it enters a recovery period, visitors to it see a 410 status code, and you can restore it for 30 days for successfully built deployments, from project Settings under Security, in the Recently Deleted section. After that its resources are permanently removed [3].

Timing is not instant either. The docs say a background job typically marks an expired deployment for deletion within 48 hours, and a deployment that was protected by an exception when first checked can be re-evaluated later, which can take up to 30 days [3].

There is a conflict to be aware of. The changelog says deleted deployments cannot be used for rollback [1], while the docs describe a restore step for the 30-day recovery period [3]. Both can be true: a deleted deployment cannot be rolled back to directly, but within the recovery period it may be restorable first. The docs page we read was marked last updated 16 September 2026, before the October announcement, so check the current page and your dashboard rather than assuming the recovery window applies to your team.

What does Vercel deployment storage cost?

Vercel prices Deployment Storage and Functions Storage at $0.10 per GB-month each [1]. Vercel's docs say each successful deployment can add both: Deployment Storage for build outputs and static assets, and Functions Storage for function bundles stored in each region where they are deployed [4].

The docs name three drivers of usage: how many deployments are retained, how large each deployment's output is, and how long they are kept [4]. Here is a worked example using only those inputs, and the figures are illustrative arithmetic, not Vercel data. A project that keeps 300 deployments at 150 MB each holds about 45 GB. At $0.10 per GB-month that is about $4.50 a month for that project's deployment storage, before Functions Storage and before any allowance in your plan, which we did not verify.

Two things follow. First, for most small teams the dollar figure is modest, so the real decision is about history and recovery, not cost. Second, large outputs multiply fast: a project that ships big static assets or heavy function bundles with every build costs far more per retained deployment, and trimming output size helps as much as shortening retention [4][5].

Check your Vercel deployment retention in ten minutes

1. Open your team's Usage page and look at Deployment Storage and Functions Storage per project, which Vercel says it shows there [1]. Note which projects hold the most.

2. Open each important project's settings, then Security, then Deployment Retention Policy, and read the current periods for Canceled, Errored, Pre-Production and Production deployments [3]. You can also run the CLI command shown in Vercel's docs, vercel list with a policy option, to view them [3].

3. Decide per project, not per team. A project policy replaces the team default for that project only, so a client site that ships monthly can keep a long window while a busy app uses a short one [3].

4. If you need history, for audits, a contract, or because you roll back to older builds, set a longer period before 23 October. That is the opt-out Vercel refers to [1]. Longer periods keep more output, which raises storage [4].

5. If you do not, reduce storage at the source: remove unnecessary build files, move large assets to Vercel Blob, and shrink function bundles, as Vercel's own optimisation guide suggests [1][5].

6. Keep your own release record. Do not rely on a hosting platform as your only archive of what you shipped. A tagged commit in Git, a build log or a release note is enough to rebuild a past version, and it does not expire with a retention setting.

Free Hobby plan: a related change

A separate change affects Hobby teams. The New Stack reports that on the free plan, older unprotected deployments are now deleted immediately when a team exceeds the 10 GB Deployment Storage limit, and each Hobby project keeps its three most recent production deployments and three most recent deployments of any type [6].

The same report quotes Vercel's head of pricing saying the current production deployment is never deleted and that aliased and active-branch deployments stay protected [6]. If you run a small project or a prototype on Hobby, that is the page to read.

What to expect next (prediction)

Prediction, not fact: expect other platforms to put a price on retained build history. Vercel's own stated reason is that coding agents have increased how often teams deploy and how much history is stored [2], and its pricing head says the platform now handles more than 10 million deployments a day, over six times a year ago [6].

If that trend continues, the sensible habit is to treat deployment history as a cost you set deliberately, with a retention period chosen per project, rather than an unlimited default.

Frequently asked questions

The short version

Before 23 October, open your retention settings, decide per project how much history you need, and either lengthen the period or accept the 30-day default. Your live production deployment and recent rollback targets are protected by documented exceptions, but old previews and old releases are not.

If hosting and infrastructure costs are part of planning a product, our SaaS infrastructure cost guide covers the wider picture, and the services page explains how we scope SaaS builds.