Vercel Hobby Can Remove Old Previews Before 30 Days

Vercel Hobby's 30-day deployment history is no longer a safe rollback promise. Since 16 September 2026, a Hobby team over its 10GB Deployment Storage limit can have an old preview or production rollback target removed immediately when no retention exception protects it.

The current production deployment is still safe. So are deployments with qualifying aliases and the latest preview for an active Git branch. The change lands on everything outside those protected groups, which is why a personal prototype can keep running while an old review link quietly stops working.

The 30-day window is no longer a floor

Deployment retention is the rule that decides how long Vercel keeps the built files behind each deployment. Those stored files are what let you reopen an old preview, promote a tested build without rebuilding it, or roll production back during an incident.

Hobby's normal retention interval is still 30 days. The new part is an over-limit cleanup rule: once the team is above 10GB of Deployment Storage, an unprotected deployment can become eligible for deletion before those 30 days pass. That is the business consequence of the change. Free deployment history is now conditional on both storage usage and the exceptions below.

Each Hobby project gets two recent-deployment protections:

• The latest 3 deployments created, of any type
• The latest 3 Ready production deployments

Treat those as one combined set, not six reserved slots. A recent production deployment can sit in both groups. If all three newest deployments are also the three newest Ready production releases, only those same three deployments get protection from these two rules.

Preview deployments no longer have a separate recent-preview allowance. A preview outside the newest three survives only when another exception applies.

What Vercel still protects

The easiest way to read the rule is to separate protections that depend on recency from protections that depend on how a deployment is being used.

These exceptions come from Vercel's current deployment retention rules. A saved deployment URL by itself is not one of the listed protections. The relationship that matters is the alias, branch, production state, or recent position attached to the deployment.

That distinction changes a common workflow. You can send a preview to someone, merge the pull request, and assume the link will remain useful for the rest of the month. Once that branch is no longer active, its latest-preview exception ends. If the team is already above 10GB and the deployment is outside both latest-three sets, the link can lose its target before day 30.

Who this actually affects

A solo builder with several personal prototypes is the clearest case. Old projects can hold stored build output while active projects keep deploying. Crossing the team limit lets Vercel clear unprotected history across that Hobby team, so the rollback target you care about may belong to a project you have not touched recently.

A designer sharing a non-commercial concept has a different risk. The current preview for an open review branch is protected. The older link used for an earlier design decision may not be. If that exact build must remain reviewable, it needs a qualifying custom alias or another preservation plan before the branch closes.

A maintainer using deployments as a rollback shelf should check the recent production set. The latest 3 Ready production deployments remain protected, but an older known-good release is not safe just because it is less than 30 days old.

A freelancer, agency, or company should not use retention as the only upgrade test. Hobby is limited to personal, non-commercial use. Commercial work belongs on Pro even when it fits under 10GB, so the deployment-history change reinforces a plan decision that already exists.

Hobby teams below 10GB are not in the new immediate-cleanup path. Their deployments still follow the normal 30-day policy and its exceptions. Pro and Enterprise teams are also outside this specific Hobby change. Their default retention windows and protected recent-deployment counts are larger.

Audit the history that still matters

Do this from the team level first. The 10GB limit belongs to the Hobby team, while the useful clues are split across projects.

1. 1

   Check both storage meters

   Select the correct team in Vercel, open Usage, then choose Deployment Storage. Review both Deployment Storage, which covers build outputs and static assets, and Functions Storage, which covers function bundles. Open Projects under each metric to find the projects carrying the most stored output.

2. 2

   Write down the deployments you cannot lose

   For each large project, open Deployments. Record the current production deployment, the production build you would actually roll back to, any preview URL still in a review or approval workflow, and any old build needed for an audit or regression check. This list is the requirement. The deployment feed is only the inventory.

3. 3

   Match every keeper to a protection

   Check whether each keeper is in the latest 3 created, in the latest 3 Ready production deployments, carrying a qualifying alias, or the latest preview for an active branch. Do not count the two latest-three groups separately when the same deployment appears in both.

4. 4

   Preserve the exception, or preserve the source

   Keep a review branch active while its latest preview is still needed. Give a must-keep non-production deployment a custom alias when that fits the workflow. For everything else, make sure the source commit, configuration, and external data needed to rebuild it are available somewhere outside deployment history.

5. 5

   Remove storage that has no job

   After the owners confirm what can go, remove stale custom aliases and close stale pull requests through the normal repository process. Then inspect the largest deployment's Resources view for oversized static output or Function bundles. The Usage page can identify a project, but it cannot name the exact file, deployment, or bundle causing the total.

Vercel's storage optimization guide recommends comparing the same team, both storage metrics, the same projects, and the same 30-day range after a change. Retention cleanup and smaller build output solve different problems. The first reduces stored history over time. The second makes new deployments smaller.

Cleanup and Pro change different parts of the math

Cleaning up is the zero-subscription-cost option for a personal, non-commercial project. You give up history that has no current job, reduce output size where possible, and stay under the Hobby limit. The cost is operational: fewer old previews to inspect and fewer production builds available for rollback.

Pro is not a $0.10 upgrade. Deployment Storage and Functions Storage each list at $0.10 per GB-month on Pro, so keeping 10GB of one metric for a full month lists at $1. But the plan starts with a $20 monthly platform fee, including one deploying seat and $20 in monthly infrastructure usage credit. Each additional deploying Owner or Member seat adds another $20 per month. Viewer seats are free.

That makes the decision rule straightforward. Do not compare “delete history” with “pay $1 for storage.” Compare cleanup with the full $20 monthly plan, then add every extra deployer and check whether the included credit covers the team's actual storage and other infrastructure use. The full Vercel pricing breakdown walks through the rest of that bill.

For a personal prototype, $20 a month may be more than the saved history is worth. For commercial work, plan eligibility settles the question before retention does. For a one-developer business that already needs Pro, the larger retention defaults and recent-deployment protections are part of the value you are already buying.

What to do on Monday

If your Hobby team is above or close to 10GB, start with the Usage page and identify the projects holding the most Deployment Storage and Functions Storage. Then mark the exact preview links and rollback targets that still have a business or review job. Protect those deliberately, and let history with no job go.

If the team is comfortably below 10GB, there is no emergency cleanup to perform. Keep the normal 30-day policy in mind, especially when closing a branch that owns a preview someone still needs.

If the project is commercial, stop treating Hobby cleanup as the long-term plan. Budget the full Pro fee, keep deploying access to the people who need it, use free Viewer seats for everyone else, and compare that bill with the cost of rebuilding a missing review or rollback workflow.

For one plain-English breakdown like this each week, join the newsletter.