Vercel deployment retention: three kept, the rest deleted

Vercel has tightened what its free tier keeps. Under the new Vercel deployment retention policy, each Hobby project holds on to its three most recent production deployments and its three most recent deployments of any type, regardless of age. That is down from ten production deployments, and it applies to every Hobby project — not only the ones over the storage limit.

If you park staging environments, client review links or side projects on Hobby, this is worth ten minutes of your attention. Not because anything is on fire, but because a habit a lot of teams have — treating the deployment list as a safety net — just got materially less safe.

What Vercel deployment retention still protects

The protections that survive, on every plan:

• Your current production deployment. It is never deleted. Garcha, Vercel's head of pricing, put it plainly: "Your current production deployment is never deleted, and aliased and active-branch deployments remain protected, along with each project's most recent deployments."
• Aliased deployments — anything a domain points at.
• The latest preview deployment on an active Git branch. One per branch.
• The three most recent production deployments, and the three most recent of any type, on each Hobby project.

On Pro and Enterprise, the last 20 non-production deployments in a Ready state are still kept. That count-based exception is the one Hobby lost.

What Hobby projects actually lost

Three changes, and they compound:

1. Ten production deployments became three. Your rollback history on a free project is now two steps deep behind current.
2. The preview count exception is gone. Previously a number of recent preview deployments were retained on their own; now only the latest preview on an active branch is protected. Merge the branch, delete it, and the preview goes with the next sweep.
3. The 30-day grace period disappears once you are over the limit. Hobby includes 10GB of Deployment Storage. Under the limit, nothing changes for you. Over it, deletions of unprotected deployments apply immediately instead of after 30 days.

That last one is the sharp edge. It is not a slow tightening you will notice in a dashboard — it is a threshold, and crossing it changes the behaviour the same day.

Deleted is not gone for 30 days

This is the part the announcement coverage mostly skipped, and it is the useful part. A successfully built deployment that gets deleted enters a 30-day recovery period. You can restore it from the project's Settings, under Security, in Recently Deleted.

So the failure mode is recoverable if you notice. The problem is that nobody watches a storage quota on a side project, and the thing you need a six-month-old deployment for is usually something you discover on a bad afternoon rather than something you plan for.

Why Vercel changed it

Volume. According to Garcha, Vercel now handles more than 10 million deployments a day, more than a six-fold increase year on year. His reasoning for the change was that the old defaults were built for a different user: "Our former retention defaults were designed for teams that ship constantly and need deep rollback history. They made less sense for Hobby projects, where dormant deployments were quietly consuming storage that active projects need."

That is a fair description of what free-tier storage actually holds. Most of it is dead weight from projects nobody has opened in a year. Reclaiming it to keep the free tier viable is a reasonable trade, and Vercel framed it as exactly that rather than dressing it up as a feature.

Who this actually bites

Not hobbyists, mostly. The teams that will feel it are the ones running real work on a free plan:

• Agencies with client demo links on Hobby projects. A preview URL you sent a client in March is not protected once that branch is gone.
• Teams whose staging environment is a Hobby project because it was quicker than adding a seat.
• Anyone whose rollback plan is "promote the last good deployment" and whose last good deployment is older than three releases.

We build a lot of web applications on Next.js, and the third case is the one we see most. Instant rollback is genuinely excellent, and because it is excellent people stop maintaining the ability to rebuild a given commit from scratch. Then the platform changes a retention default and the gap shows up.

What to do about it

None of this requires a migration. It requires deciding what your deployment history is actually for:

1. Tag releases in Git. If a production deploy corresponds to a tag, you can always rebuild it. Deployment retention becomes a convenience rather than a dependency.
2. Check your storage usage once. If you are under 10GB, the immediate-deletion change does not apply to you at all. Knowing which side of the line you are on takes a minute.
3. Move anything a client can see off Hobby. A demo link that dies quietly is worse than no demo link.
4. Stop counting rollback as a recovery plan. It covers one failure mode — the last deploy was bad. It does not cover a bad migration, a deleted record or a corrupted build cache. The same reasoning applies to the backups you have never restored: an untested recovery path is a guess.

If your staging setup has quietly become production-adjacent, that is usually the signal to give it real cloud and deployment engineering rather than a better free tier.

The verdict

This is a reasonable change, communicated honestly, with a recovery window that makes the worst case survivable. It is also a useful reminder that anything you depend on and do not pay for can be reshaped around you — which is fine, as long as you know which of those things you depend on. The equivalent lesson on another platform's free tier showed up as failures teams only found in production.

Check your storage number, tag your releases, and move the client-facing stuff. That is the whole response. Details are in Vercel's changelog entry and The New Stack's reporting, as of September 2026.