On 9 October 2026 Vercel's changelog carried a one-paragraph product note: new Pro teams now default to a 30-day deployment retention period. The interesting part is not the number. It is the reason the note gives for it, in Vercel's own words: "Coding agents have accelerated development, increasing deployment frequency and the amount of stored deployment history."
That is the first time on this beat that a platform has named agent-driven deploy frequency as the mechanism behind a storage default. It is also the kind of change that is easy to miss, because it is not a price change. Nothing on the pricing page moved. A default moved, for new Pro teams, in a settings panel most people open once.
What the note actually says
Read it carefully, because it is scoped tightly and it is worth keeping the scope intact:
- It applies to new Pro teams. The note says nothing about existing teams, so it tells you nothing about them either way.
- It does not say what the default was before, so there is no before-and-after to quote.
- A longer retention period can be chosen in the team's settings "when you need more history for inspection or rollback".
- "Deployment Storage and Functions Storage each cost $0.10 per GB-month." Two line items, each at that rate — two numbers, not one.
- "Older deployments may be deleted under your retention policy. Deleted deployments cannot be restored or used for rollback." That sentence is Vercel describing Vercel's product; it is the sentence to read twice.
What deployment history is for
Most developers never think about retained deployments until the day they need one. They exist for two jobs, and the note names both.
Inspection. A retained deployment is a frozen answer to "what exactly was live at 14:07 on Tuesday?" — the build output, the environment it was built with, the logs around it. When a customer reports something that only happened for an afternoon, the deployment from that afternoon is the evidence. Git tells you what the source was; the deployment tells you what the build was, which is not always the same thing (a dependency resolved differently, a build-time environment variable, a platform-side change).
Rollback. The reason platform rollbacks feel instant is that they do not rebuild anything. They point traffic at a build that already exists. That only works while the build still exists. A retention policy is therefore also a rollback horizon: you can roll back as far as you retain, and not one deployment further.
Why agents change the arithmetic
Retention cost is a product of three things: how often you deploy, how big each deployment is, and how long you keep them. For years the first term was small and human-shaped. A developer pushes a few times a day; a busy team of ten might produce thirty deployments on a heavy day, counting previews.
A coding agent does not push like a person. An agent working through a task list may open a branch, push, read the preview, push again, and repeat until a check passes — and it may do that for dozens of tasks in parallel, around the clock, with no one feeling the pace. Every one of those pushes that reaches a deploy hook produces a stored deployment. The source diff between two agent pushes might be three lines; the stored build output is the full artefact every time.
So the first term in the product grew by an order of magnitude for some teams, while the other two stayed where they were. The platform's lever is the third term: keep less of it by default. That is what the note describes, and it is a reasonable response. It also means the rollback horizon for a new Pro team is now a defined, finite window rather than "whatever accumulated".
To make the shape of it concrete with an invented example, not a quote: a team whose agents produce 40 deployments a day at 60 MB of stored output each adds about 2.4 GB of deployment history per day. Over a 30-day window that is roughly 72 GB in steady state; over 90 days it would be about 216 GB. At a published rate of $0.10 per GB-month for a storage line item, that is the difference between a bill you notice and one you do not — and the same arithmetic applies to whichever platform you are on, with its own numbers.
The failure mode to design around
The dangerous version of this is not the bill. It is the rollback that is no longer there. A release goes out, a slow-burning data problem surfaces five weeks later, and the "known good" deployment you would roll back to has aged out under a policy nobody on the team chose consciously. If the platform's rule is that deleted deployments cannot be used for rollback, the recovery path becomes "rebuild the old commit from source and hope it builds the same way" — which is exactly the gap between source and build that inspection was supposed to cover.
None of that is an argument against short retention. It is an argument for knowing your retention and keeping your rollback path independent of it.
What to check in your own settings this week
- Find the retention setting and read the actual value. Do not assume it from a blog post, including this one. Check whether your team is governed by a "new teams" default or a legacy one — if the platform's note only mentions new teams, treat your own status as unknown until the settings page says otherwise.
- Find out which storage line items retention feeds. On Vercel the note names two, Deployment Storage and Functions Storage, each billed per GB-month. Other platforms split it differently. The question is the same: what gets bigger when you deploy more often?
- Ask whether your rollback depends on retained deployments or on your repository. If it is the former, your retention window is your rollback window. If you want a longer safety net than you are willing to pay storage for, tag releases in git and make sure a tagged commit rebuilds reproducibly — pinned dependencies, build-time variables recorded, no "latest" anywhere in the build.
- Decide what your agents are allowed to deploy. Deploy on merge to a protected branch rather than on every push; let agents iterate on a branch with previews that expire quickly; squash the loop before it reaches the production deploy hook. The cheapest deployment to retain is the one that was never created.
- Put the storage line items on a dashboard. A default that changes quietly is caught by a number that moves, not by a changelog you happened to read.
- Keep your own copy of anything you must keep. If compliance or an audit needs a build artefact from eleven months ago, that is your artefact store's job, not a hosting platform's retention default.
The note is 120 words long and will scroll off most people's radar within the week. The mechanism it describes will not. Agent-era deploy volume is the new normal, retention defaults are how platforms absorb it, and the only version of the number that matters is the one in your own settings. Go and read it.
DeployBase is managed container hosting for Node.js, Laravel and PHP apps. Whatever you host with — us included — the checklist above is about your settings, not ours: open them and read the values.