Vercel charges for deployment storage – manage costs and rollback

Vercel is starting to charge existing Pro teams for storing deployments and their associated function bundles. At the same time, affected teams will have a shorter storage window unless they actively choose otherwise.

If you run a product on Vercel, this is not just a change to your bill. How long a deployment is retained also determines which preview environments you can open, how far back you can investigate an issue and whether an earlier production version can still be restored immediately.

The important thing is therefore not to delete as much as possible. You need to choose a retention period that suits how the product is developed, tested and restored.

What Vercel is changing

In Vercel’s changelog, published on 9 October 2026, the company says that charges for Deployment Storage and Functions Storage will also apply to existing Pro teams. The exact start date may vary between teams and, according to Vercel, will be stated in the email sent to the team’s administrators.

As part of the change, Vercel says that the storage window for affected teams will change to thirty days. Deployments older than this will start to be deleted from 23 October 2026 unless the team opts out of the change in its retention settings before then. Settings that already use an equally short or shorter window will not be affected.

There are therefore two separate changes to manage:

• Storage becomes a billable resource. The cost is affected by how much build output and function code is stored and how long it is retained.
• Older deployments may disappear sooner. This reduces storage, but also shortens the history available for troubleshooting, comparisons and rollback.

Vercel lets you set different retention periods for Pre-Production, Production, Canceled and Errored deployments. This means you do not need to use the same rule everywhere. A failed build rarely has the same long-term value as a stable production version.

Also check whether the change is being made at team or project level. A team policy may become the default for new projects and can also be applied to existing projects. A project policy applies only to the selected project. Be careful with options that overwrite settings for the entire team.

What Deployment Storage actually contains

A deployment is more than an entry in Vercel’s history. When Vercel builds your application, it creates files that the platform needs to display and run that particular version.

Deployment Storage includes build output and static files. This may include compiled JavaScript, CSS, images packaged with the project and other content from the build process.

Functions Storage includes the bundles used for Vercel Functions. A bundle may contain your server code, dependencies and other code needed when a function runs. If functions are deployed across several regions, the same type of output may need to be stored in several places.

Storage grows mainly when:

• the project creates deployments frequently
• old deployments are retained for a long time
• build output contains large static files
• functions include large dependencies
• automation creates duplicate or unnecessary deployments
• several projects use generous retention periods without actually needing the history

This should not be confused with services such as Vercel Blob or the database in Supabase. Deployment Storage is linked to the built version of the application. Blob storage is used for files that the application itself uploads and manages. Supabase, in turn, stores data and database structures outside the Vercel deployment.

The distinction matters during a rollback. When you restore an older deployment, you restore the application version that Vercel has stored. You do not automatically restore Supabase data, database migrations, Stripe configuration or changes in other external services.

It may therefore be possible to activate an older frontend even though the database already has a new structure. This can result in new errors rather than a successful recovery. A stored deployment is therefore an important part of recovery, but it is not a complete backup of the entire product.

Lower storage can mean slower recovery

There is a clear trade-off between cost and the ability to recover. Short retention reduces the amount of stored material. Long retention provides more versions to investigate and return to.

For the production environment, the question should be: How long after a release might we reasonably discover a serious issue?

Some issues appear immediately. Others only emerge when a particular customer journey is used, a payment renews, a scheduled job runs or a long-standing user opens part of the product. If the last working deployment has already been deleted, you can no longer roll back to it immediately through Vercel.

Instead, you need to find the right commit in Git, rebuild it and create a new deployment. This may work, but it is not the same as activating an already built and previously tested result. The build environment, dependencies or external services may have changed since the old version was created.

Vercel has a recovery period for deployments that have recently been marked for deletion. During this period, they may appear under Recently Deleted in the project’s security settings. Treat this as protection against mistakes, not as your normal rollback process. Failed deployments may also be removed more quickly than successful builds.

Retention can also be affected by exceptions. For example, a deployment may be retained if it still has an active alias or is the latest preview version for an active Git branch. These exceptions are useful, but they can also prevent storage from falling as expected.

A reasonable strategy is often to:

• retain production versions based on the period in which issues are normally discovered
• give preview versions enough time for review and approval
• remove cancelled and failed builds sooner
• document which external systems must be managed during a rollback
• regularly check that an older version is still compatible with the database

Preview environments need a clear lifecycle

Preview deployments are one of Vercel’s most useful features. They make it possible to test a branch or pull request without affecting production. In workflows involving Lovable or coding agents, however, the number of previews can grow quickly, particularly if every change is sent to Git and triggers a new build.

A shorter retention period means that old preview links stop working sooner. This may affect you if the links are used for design reviews, customer interviews, external quality assurance or approvals that take time.

You should therefore decide what a preview link means in your workflow. Is it temporary and linked to an active branch, or should it serve as an archive of a decision? If a particular version needs to remain available much later, a standard preview deployment may be the wrong place to store it.

Also review what actually ends up in each build. Common causes of unnecessarily large deployments include:

• videos, archives or exports stored directly in the project
• an output directory that includes more than the completed application
• server functions that import an entire library for a small task
• generated files that should be created when needed
• uploaded user content that has been added to the source code

Large files that change independently of the application should normally be kept in separate file or object storage. This prevents every deployment from carrying a new copy. However, the move must take account of access control, deletion, backups and how the files are delivered to users.

Also check whether automation is creating more deployments than intended. Deploy hooks, Git integrations, CI jobs and coding agents can overlap. If the same commit is built several times, you should find the duplicate trigger before trying to solve the problem solely through shorter retention.

Check this in Vercel

Start by selecting the right team in Vercel and opening Usage. Then go to Deployment Storage and review both standard Deployment Storage and Functions Storage. Compare the projects to see which account for the largest share of storage.

The Usage view shows which project you should investigate, but not always the exact file or function causing the usage. Open a representative deployment in the project and go to Resources. There you can review static files, functions, bundle sizes and regions.

Use this checklist:

• Read the email from Vercel and note when charging begins for the team.
• Check retention for Pre-Production, Production, Canceled and Errored deployments.
• Make sure no team setting unintentionally overwrites projects with specific requirements.
• Identify which projects use the most Deployment Storage.
• Check Functions Storage separately – it may differ from standard deployment storage.
• Look for large static files and unnecessarily large function bundles.
• Check old preview branches, open pull requests and outdated aliases.
• Look for duplicate builds from Git, deploy hooks, CI and coding agents.
• Decide how far back a production version must be available for immediate restoration.
• Document how Supabase, Stripe and other external systems are managed during a rollback.
• Test the recovery process before it is needed during a live incident.

Ideally, change one thing at a time. Start with retention where it is clear that the history is not needed. Then monitor usage over a comparable period. If storage remains high, you can move on to build output and function bundles. This will show you which change actually had an effect.

The aim is not the shortest possible retention period, but a deliberate policy in which the cost is proportionate to the value of quick troubleshooting and recovery.

Once operations and recovery are under control, the next question is how the product can start supporting itself – read more about the path to paying customers.

---

Source: Vercel changelog