Set Vercel deployment retention so side projects stay cheap

Before your next Vercel deploy, you can set one control that keeps a side project near zero without losing rollback safety. Most weekend projects do not die from traffic. They die from a small bill that keeps growing while nobody is watching. The usual suspect is the storage that keeps old deploys restorable.

That pile is the storage meter for the files that make a deploy roll back. If you leave the Deployment Retention Policy setting alone, you are choosing a storage bill without saying what you are buying. You do not have time to watch a bill. You have time to set one control and check it occasionally.

Retention is the storage lever

Vercel's Deployment Storage product holds the build output and Vercel Function bundles that remain attached to deployments. Vercel's Deployment Retention Policy setting determines when each deployment becomes eligible for deletion. One hidden cost people miss is the old deploy still holding files. If a deploy is no longer needed, the files can stop counting.

Vercel measures Deployment Storage usage in GB-months, with one GB held daily for a 30-day month counting as one GB-month. Vercel bills Deployment Storage at $0.10 per GB per month. The $0.10 per GB-month price is the Pro list price. Vercel's Hobby plan includes up to 10 GB of Deployment Storage, and existing teams keep current pricing with no bill change at the time of the announcement. For a small project, the included amount can be enough for a long time.

The two windows decide the bill

You only need two decisions: how long production must stay restorable, and how long pre-production or canceled work should remain available. The first window is your rollback safety. The second is your test habit. Most side projects stay side projects, and that is fine. You are not trying to preserve every experiment. You are trying to keep the one you might need.

The one-lever rule: production retention is the rollback window you actually need; pre-production and canceled retention is the shortest safe window; estimate GB-months before extending either.

• Decide the rollback window. Done: you can name the last deploy you would want to restore, and anything older is fair game. If the project has no real users, the window can be short. If it has users, keep it long enough to undo a bad release.
• Set production retention to that window. Done: the oldest production deploy you want to keep is inside it. This is the only window that should be generous. A production deploy is the version your visitors can actually see.
• Set pre-production and canceled retention to the shortest safe window. Done: test builds disappear before they become a storage habit. A pre-production build that helps you for a short time does not need to stay for a long time. If you cannot explain why a deploy should survive, shorten the window.
• Estimate the storage before extending either window. Done: you can say how many GB-months the change will add. Do this before you click save, not after the bill arrives. A rough number is enough if it tells you the change is small.

The common mistake is treating pre-production like production. The first window protects users. The second protects your test storage. That keeps the rollback path clear without turning every test into a permanent archive. Keep the short window for work that was never meant to run for customers.

Extend only when the math is small

Before you lengthen retention, multiply the size of what you keep by the months it stays. If the answer is a few GB-months, the change is probably fine. If it is a large chunk of the included amount, stop and shorten the window. The price is small enough that the real cost is forgetting to revisit the setting.