Vercel Bills Deployment Storage at $0.10 per GB per Month

Vercel now bills Deployment Storage at $0.10 per GB per month — the storage that keeps your old deployments rollback-ready.

The framing in Vercel's changelog is worth reading literally: every deployment produces a set of files, including the pages, functions, and assets Vercel serves, and Deployment Storage "keeps those files available so you can inspect previous deployments and roll back when needed." Rollback is not a feature that exists independently of storage. It is the storage.

What rollback actually does

The recovery path is a three-click sequence, not a redeploy. Per the changelog: "If a production deploy ships a bug or a change you want to reverse, rolling back restores the previous version in seconds. Open your project, click Instant Rollback on the Production Deployment tile, then choose an earlier production deployment."

The important clause is the last one — Vercel "immediately repoints your domains to that deployment, with no rebuild required." No rebuild means no dependency install, no cold build cache, and no chance of a fresh build behaving differently from the artifact you tested. That is the difference between a rollback and a revert-and-deploy.

The pricing and who pays it

• $0.10 per GB per month for Deployment Storage.
• Hobby teams include up to 10 GB.
• Existing teams, per Vercel, "continue with their current pricing, with no change to their bill at this time."

That last line is the one to file away. "At this time" is not a permanent exemption, and the meter is now defined and visible — the Usage page shows Deployment Storage and Functions Storage broken out by project.

The retention trade-off is a real decision

Retention is configurable, and the changelog states the cost of tightening it in one sentence: you can edit your Deployment Retention Policy to set how long Pre-Production, Production, Canceled, and Errored deployments stay available, but "shorter retention means less storage, but you can't roll back to a deleted deployment."

An assessment rather than a Vercel recommendation: those four categories do not deserve the same retention window. Canceled and errored deployments are diagnostic artifacts with a short useful life. Pre-production builds age out quickly. Production deployments are the ones your incident response depends on, and they are the last place to trim. Setting one global retention number treats an incident-recovery asset and a stale preview build as the same thing.

How to cut the bill without cutting rollback

Vercel's own suggestions target deployment size instead of retention: trim your output directory, move large files to Vercel Blob, and reduce Function bundle size. Each shrinks every future deployment rather than deleting the history you might need at 2 a.m.

The practical order for a team looking at this line item for the first time: read the per-project breakdown on the Usage page, shorten retention on canceled and errored deployments, then attack deployment size. Touch production retention last, if at all.

What to watch: whether that "no change to your bill at this time" grace period gets an end date. Teams on large monorepos with heavy output directories are the ones who will feel it first when it does.