News and analysis
Deployment history: retention should match the recovery plan
Vercel retention changes and GitLab’s Artifact Central beta connect release history, artifact availability and operational ownership.
An earlier application version is useful only while the team can find and apply it. When a platform shortens deployment history, the recovery plan changes too. October announcements from Vercel and GitLab show why artifact retention belongs in operational planning rather than being left as a default setting.
What changes at Vercel
In its 9 October announcement for existing Pro teams, Vercel describes Deployment and Functions Storage billing and a 30-day retention window. Older deployments will begin being deleted on 23 October unless teams change their retention settings beforehand. Each team’s exact billing start date is communicated separately by email.
A second announcement on the same date concerns new Pro teams, where 30 days becomes the default. A deleted deployment cannot be recovered or used for rollback. The notices address different groups; do not apply one deadline to every account without checking its conditions.
For an owner, the immediate step is specific: establish the project’s policy and which verified releases will remain after deletion. Do not blindly shorten the history. First agree how long the team needs to discover a problem and who decides whether to return to an earlier version.
Package registries have another policy
On 6 October, GitLab introduced Artifact Central as a free beta, an organization-level registry with roles, quotas and retention, including npm, Maven and Docker/OCI repositories. Its beta status needs separate consideration against operational requirements.
The connection is not that these products replace one another. Deployments and packages may live in different places with different lifetimes. If a package disappears, a release record alone does not mean the team can deploy the same output again. Conversely, a retained image does not explain the configuration or data state associated with it.
Test what history is actually usable
Create a compact inventory: application release, source revision, package or image, environment settings and related data changes. Record a storage location and lifetime for each. Keep database backups distinct from application history, since they solve different problems.
In a separate environment, try to recover a selected verified release using materials that are actually preserved. Establish that the procedure does not depend on a deleted deployment or an accidental file on someone’s laptop. Assign an owner to the policy and repeat the exercise when it changes.
Our server core guide distinguishes startup from preserved state. The archived infrastructure material describes recovery requirements without confirming current operation of every component. For your maintenance plan, discuss usable history and a release-recovery check.