Deployment Retention Policies Now Preserve Active Branch Deployments

A subtle but meaningful change has been made to deployment retention policies, altering the calculus of risk for managing development workflows. The core of the update is this: the latest preview deployment for branches with open or unmerged pull requests will no longer be deleted by automated retention policies. (Source). This resolves a direct conflict that existed in the previous system, where a deployment could be essential to an active review process yet still be flagged for removal simply because it crossed a time-based threshold.

Previously, deployments for active branches could be removed if they exceeded the configured retention window. This created a tension between two valid objectives: maintaining a clean slate of deployments through shorter retention windows and ensuring the stability of in-flight work. A short retention window could inadvertently delete a preview deployment that was still the subject of an open pull request, disrupting the review cycle. The only way to avoid this was to set longer retention windows, which could lead to an accumulation of unnecessary deployments.

The new policy eliminates this trade-off. By explicitly protecting the latest preview deployment for any branch with an open or unmerged pull request, the system now allows for the safe use of shorter retention windows. The risk of losing active preview deployments due to an aggressive cleanup policy is now mitigated. This change is not a tiered feature; it applies to all plans, establishing a new baseline for operational stability. The system is now more intelligent, distinguishing between a deployment that is merely old and one that is old but still relevant to an ongoing task.

This new protection for active branches builds upon an existing set of guarantees. The system continues to preserve the 10 most recent production deployments and any aliased deployments, regardless of any configured retention settings. This creates a clear hierarchy of persistence. Production and aliased deployments have the highest level of protection. The latest preview deployments for active work now occupy a second, protected tier. All other deployments remain subject to the configured time-based retention window. This layered approach provides a more predictable and robust framework for managing the lifecycle of deployments.

The immediate effect is a reduction in operational friction. The need to manually adjust retention settings to protect specific, long-running pull requests is gone. One can now set a global policy with the confidence that the system will not interfere with active work. The open question this policy shift presents is what other forms of context-aware lifecycle management might follow. If the system can understand the state of a pull request to inform its retention logic, it demonstrates a capacity for more nuanced, workflow-integrated automation. This moves beyond simple, time-based triggers and toward policies that reflect the actual state of the work being done.