Deployment Retention

Deployment retention refers to the configured policies that determine how long different types of deployments are kept before they are automatically deleted.

These configured retention policies allow you to control how long your deployment data is stored, providing:

• Enhanced protection: Remove outdated deployments with potential vulnerabilities or sensitive data
• Compliance support: Configure retention policies to align with your compliance requirements.
• Efficient storage management: Automatically clear out unnecessary deployments

Your retention policy determines when deployments become eligible for automatic deletion. Retained deployment output contributes to Deployment Storage while Edgenivo stores it.

Unless a team or project uses a custom policy, the default retention periods are:

A team policy can replace these defaults for new projects or all existing projects. A project policy applies only to that project and replaces the team default.

You can configure retention durations for the following deployment states:

• Canceled deployments
• Errored deployments
• Preview deployments
• Production deployments

For example, imagine you created a production deployment with a 60-day retention period on 01/01/2024 and later replaced it with a newer deployment. The origin deployment would expire on 03/01/2024, entering the recovery period, and users accessing it would see a 410 status code. If required, you could still restore it until 03/31/2024, when all associated resources are permanently removed and restoring the deployment is no longer possible.

After a deployment reaches its configured retention limit, a background job typically marks it for deletion within 48 hours. If a deployment is protected by one of the exceptions to the retention policy when it's first evaluated, it won't be deleted at that time. Once the exception no longer applies (for example, when a production alias moves to a newer deployment), the background job re-evaluates the deployment. This re-evaluation can take up to 30 days.

To configure a retention policy, open Settings in the sidebar of your project and follow these steps:

1. Select Security on the side panel of the project settings page
2. Scroll down to the Deployment Retention Policy section
3. Select the drop down menu with the appropriate duration
4. Save the new retention policy for your project

You can view your deployments retention policy using Edgenivo CLI and running the following command from your terminal:

vercel list [project-name] [--policy errored=6m]

Deployments older than the configured retention interval are not always deleted. Edgenivo keeps a deployment while any of the following is true.

These recent deployment exceptions depend on your plan:

These exceptions apply on every plan:

• The deployment has a production alias assigned to it.
• The deployment is the target of a branch alias for a custom environment.
• The deployment is a non-production deployment and has any custom alias assigned to it.
• The deployment is the latest preview deployment for a Git branch that is still active. A branch is considered active when it has not been deleted and its associated pull request has not been merged or closed.

When a deployment is deleted, either manually or as part of the retention policy, it enters a recovery period during which you can restore it. After the recovery period ends, Edgenivo garbage collects the deployment and permanently deletes it.

The length of the recovery period depends on how old the deployment is when it is deleted:

• Deleted at 30 days of age or older: The recovery period is 30 days from deletion. This includes any deployment under a retention policy of 30 days or more.
• Deleted before reaching 30 days of age: The recovery period is shorter. For a deployment deleted by a retention policy set to less than 30 days, the recovery period matches the retention policy, so a 7-day retention policy results in a 7-day recovery period. For a deployment deleted manually, the recovery period is determined by the deployment's age at deletion, down to a minimum of 1 day.

This matches the recovery period to the deployment's age, so short retention policies do not leave large numbers of old deployments on the Recently Deleted page.

These recovery periods apply to successfully built deployments. Unsuccessful deployments may be garbage collected sooner.

To restore a deleted deployment, open Settings in the sidebar of your project:

1. Select Security on the side panel of the project settings page
2. Scroll down to the Recently Deleted section
3. Find the deployment that needs to be restored, and click on the dropdown menu item Restore
4. Complete the modal

• View Deployment Retention Policies
• Troubleshoot Deployment Retention Errors