Pro Teams Default Deployment Retention Shortened to 30 Days: Balancing Storage Costs and Rollback Capability

The platform recently adjusted the default deployment retention policy for Pro teams: new Pro teams now retain only 30 days of deployment history by default. This change directly addresses the surge in deployment frequency brought about by the widespread adoption of Coding Agents — when automated coding tools continuously push build artifacts, deployment history expands at a rate far exceeding the past, driving up storage overhead.

Why 30 Days

The official rationale is straightforward: Coding Agents accelerate the development process, deployment frequency rises accordingly, and the volume of stored deployment history swells. Shortening the retention window strikes a balance between "keeping recent, queryable history" and "limiting old history and its storage costs."

There's an easily overlooked layer of logic behind this judgment: the value of deployment history decays rapidly over time. The vast majority of rollbacks and troubleshooting occur within the most recent few releases. The probability of old builds older than a month being retrieved is very low, yet the storage space they occupy doesn't shrink just because "nobody's looking." Setting the default to 30 days is essentially replacing the hoarding habit of "keep everything" with probabilistic thinking.

Deployment Retention refers to the time window during which the platform automatically preserves historical deployment records and their build artifacts. Each deployment generates an immutable build snapshot (containing code, dependencies, and artifact files). These snapshots are used both for rapid rollbacks and for version comparison when troubleshooting production issues. Once the retention period expires, the platform automatically cleans up expired snapshots according to policy to free up storage. The key to understanding this concept is that retention is not simply "log preservation" — it directly determines how far back a team can roll back to a historical version when an incident occurs. Therefore, setting a retention period is essentially a trade-off between "rollback depth" and "storage cost," not a purely technical parameter.

The More You Use, the More Noticeable the Cost

Deployment storage and function storage are both billed at $0.10/GB-month. The unit price seems trivial on its own, but in high-frequency deployment scenarios, the cumulative effect is quite significant.

Suppose a team generates multiple deployments per day with Agent assistance, each producing build artifacts ranging from a few hundred MB to several GB. The difference between 30-day and 90-day history retention could mean a storage bill several times larger. For teams running multiple projects and multiple environments simultaneously, this gap is further amplified. Shortening the default from a longer cycle to 30 days effectively saves teams from having to make a proactive cost-optimization decision.

GB-month is a common unit for cloud storage billing, representing the cost of "storing 1 GB of data for one month." It doesn't bill based on instantaneous usage but rather integrates over storage duration: if 10 GB is retained for a full month, the billing is 10 GB-month; if 5 GB is retained for a full month and another 5 GB for only half a month, it's approximately 7.5 GB-month. This metering method means that even if a team adds no new deployments, stale history continues to incur costs as long as it remains within the retention period. Understanding GB-month helps clarify the real benefit of retention adjustments — shortening the window doesn't just reduce "how much is stored" but also shortens "how long it's stored." The product of both is the source of billing changes.

What If You Need Longer History

30 days is just the default, not a hard cap. Teams can choose a longer retention period in settings for scenarios requiring longer history for inspection or rollback. For projects with slow release cadences but high risk per change, extending retention is a reasonable choice.

There's a risk that needs to be recognized in advance: old deployments beyond the retention policy will be deleted, and once deleted, cannot be recovered or used for rollback. In other words, the retention period is essentially an "irreversible deletion line." If a team relies on a specific historical version as a fallback, it must proactively extend the retention period before it gets cleaned up — rather than waiting until a rollback is needed to discover the build is no longer there.

Coding Agent refers to AI tools capable of autonomously or semi-autonomously completing coding tasks. They can continuously generate code, submit changes, and trigger build and deployment pipelines. Unlike the traditional "human commit — human release" rhythm, Coding Agents work at machine pace, potentially generating dozens of deployments in a single day. This high-frequency characteristic is precisely the backdrop for this policy adjustment: storage defaults designed around human release frequency in the past quickly fill up in Agent scenarios. Understanding how Coding Agents operate helps determine whether your team's deployment frequency has entered the "high-frequency" range, and thus whether you need to extend retention or optimize build artifact sizes.

Practical Impact on Teams

This adjustment sends two signals.

First, Agent-driven development models are changing infrastructure's default assumptions. Storage defaults designed around "human release cadence" are no longer appropriate in the face of automated high-frequency deployments. The platform lowering the default is a product-level change to absorb the side effects brought by Agents.

Second, cost control is shifting from "after-the-fact optimization" to "reasonable by default." Rather than having teams dig through storage optimization guides after their bills go up, it's better to set the more economical option as the default and make "needing more" a proactive choice. This default-design philosophy has reference value for teams using similar platforms.

For Pro teams, the most practical action right now is to check their project's deployment retention settings: confirm whether the default 30 days meets rollback needs, evaluate whether key projects need manual extension, and revisit the recommendations in the storage optimization guide.

One-line Summary

Pro teams' default deployment retention shortened to 30 days to address high-frequency deployment storage bloat caused by Coding Agents.

Paragraph Summary

The platform has shortened the default deployment retention period for new Pro teams to 30 days, directly driven by the surge in deployment frequency and rapid expansion of deployment history storage caused by the widespread adoption of Coding Agents. Officials believe deployment history value decays rapidly over time, and 30 days strikes a balance between queryable history and storage costs. Deployment storage and function storage are billed at $0.10/GB-month, and under high-frequency deployment, the billing gap between 30-day and 90-day retention can be several times. 30 days is only a default; teams can extend retention in settings, but should note that old deployments beyond the retention policy will be deleted and cannot be recovered or used for rollback. The article notes this reflects how Agent-driven development is changing infrastructure default assumptions, and the trend of cost control shifting from after-the-fact optimization to reasonable-by-default.