Vercel cuts Hobby deployment retention and enforces 10GB cap that can block deploys

What changed

Vercel has tightened deployment retention on its free Hobby tier and is enforcing a storage ceiling that can stop new deploys. According to a changelog entry dated September 16, 2026 on the Vercel blog, Hobby projects now keep fewer deployments past the 30-day retention window, and every deployment a team retains counts against a 10GB Deployment Storage allowance. Exceeding that allowance can block deployments entirely until storage is freed.

The new retention rules

Each Hobby project now keeps only its three most recent production deployments and its three most recent deployments of any type, no matter their age. Everything else is subject to the shortened retention policy. Vercel also notes that preview deployments no longer have their own protection, so older preview builds are removed under the same rules rather than being preserved separately.

There are exceptions. The current production deployment is never deleted, and both aliased deployments and deployments on active branches remain protected.

Immediate deletion for teams over the cap

For Hobby teams already above the 10GB limit, the cleanup is immediate rather than gradual. Deployments that do not qualify for the exceptions above are deleted right away instead of waiting out the 30-day window. Vercel frames the change as a way to reclaim storage tied up by dormant projects so that actively developed ones have room, which means inactive side projects will now be swept automatically.

What Hobby users can do

Vercel points affected users toward two options. The first is to reduce Deployment Storage usage directly, keeping fewer or smaller deployments so the team comes back under the cap. The second is upgrading to Pro, where storage is metered at $0.10 per GB per month.

Why it matters

Free tiers are where hobbyists, students and prototypes live, and this change lands on two fronts. The first is operational: a storage cap that can block deploys turns a quiet quota into a potential outage for personal projects, portfolios or small APIs that deploy automatically from a Git push. If a CI pipeline or scheduled build pushes a Hobby team over 10GB, further deployments fail until someone intervenes, which is a real problem if anything you care about depends on that deployment staying current.

The second is the loss of history. Retaining only three production deployments and three of any type means older builds disappear on a schedule, taking with them the rollback targets and reference points a developer might want when debugging something that worked months ago. Anyone who has been treating deployment history as an archive will need a different habit, such as exporting artifacts they care about before the window closes.

The change also fits a familiar pattern among platform vendors: free-tier generosity narrows over time, and the practical remedies become cleanup work or a paid plan. For Vercel the economics are understandable, since stored deployment artifacts cost real money, but Hobby users should audit their current usage now. Teams already over the limit lose unprotected deployments immediately rather than gradually, so waiting to see what happens is the one option that no longer exists.