Skip to content
Docs

Optimize Deployment Storage

Start with deployment retention. It controls how long Vercel keeps deployment output and can reduce storage without an application-code change.

Set the retention periods that preserve the history your team needs for review, recovery, and audits. After the policy takes effect, investigate projects that still have high usage and reduce their output size.

Confirm how long each application needs its Pre-Production and Production deployments before you shorten a period.

To set the default for new projects:

  1. Open Team Settings.
  2. Select Security & Privacy.
  3. Find Deployment Retention Policy.
  4. Set the periods for Canceled, Errored, Pre-Production, and Production deployments.
  5. Clear Apply this policy to all existing projects unless you intend to update every existing project.
  6. Select Save.

The team policy applies to new projects. Selecting Apply this policy to all existing projects also replaces the retention policy for every existing project in the team.

To change one project:

  1. Open the project.
  2. Select Settings, then Security.
  3. Find Deployment Retention Policy.
  4. Set the periods for this project.
  5. Select Save.

This change applies only to this project. It does not change the team default or another project's policy.

Set each period from how your team uses the deployment:

Deployment stateKeep long enough for
Pre-ProductionCode review, quality assurance, external approvals, and regression investigation
ProductionIncident recovery, rollback, and release audits
Canceled and ErroredBuild debugging

Use the same team and date range for each comparison:

  1. Open Usage for the correct team and select Deployment Storage.
  2. Set the date range to the last 30 days.
  3. Record the team total for Deployment Storage and Functions Storage.
  4. For both metrics, select Projects and record the projects with the most storage.
  5. After Usage refreshes, compare the same team, metrics, projects, and date range.

If storage remains high after the retention policy takes effect, find the projects and output types that use the most storage:

  1. Open Usage for the correct team.
  2. Select Deployment Storage.
  3. Open Deployment Storage and select Projects.
  4. Repeat the review for Functions Storage.
  5. Use the same date range for both metrics.
  6. Open the largest project and review its deployment history and output.

The Usage page shows Deployment Storage by project. It does not identify the deployment, file, or Function bundle that caused the total. Use Usage to find the projects to investigate. Then use the project's Deployments page and the deployment Resources view to inspect deployment age, static-file sizes, and Function sizes.

Use the following table to select the next action:

What you findWhere to check nextNext action
A project has high Deployment StorageOpen a representative deployment and review Resources, then Static AssetsRemove unneeded static output and large packaged files.
A project has high Functions StorageOpen a representative deployment and review Resources, then FunctionsInspect large bundles and confirm that each configured region is required.
A project has many old Preview deploymentsReview the project's Deployments page and Pre-Production retention policyShorten Pre-Production retention after the project owner confirms the required review period.
A project has many old Production deploymentsReview the project's Deployments page and Production retention policyConfirm the rollback and audit window before you shorten retention.
Storage remains high after a retention changeReview retention policy exceptions, including active aliases and the latest Preview deployment for each active Git branchConfirm that each exception is still needed. Remove stale custom aliases, and merge or close stale pull requests through your normal repository process.
Deployment volume increases unexpectedlyCompare deployments with Git commits, deploy hooks, webhooks, continuous integration jobs, and coding-agent activityFix duplicate triggers or runaway automation while preserving intended deployments.

Create a Preview deployment from a representative commit. Open the deployment, then open Resources in the sidebar. This view lists static files and their sizes. It also lists each Function's type, runtime, size, and regions.

Record the largest static files and Functions. Change one dependency, import, output rule, or large file, then create another Preview deployment from the same type of change. Compare the new Resources view with the baseline deployment.

Keep only the files required to serve the application. Do not set an entire repository or a broad build workspace as the Output Directory.

For a custom framework, write only the required files to .vercel/output. See Configuring a Build and the Build Output API.

Do not package large videos, archives, or changing data exports into each deployment when the application can load them from separate storage.

Use a product such as Vercel Blob for files that your application uploads, changes, or deletes independently. Confirm the access, delivery, and retention requirements before you move data.

Remove dependencies and files that a function does not use. Check generated code, native binaries, development data, and repeated packages.

Variable-path imports can cause file tracing to include an entire directory. Large files imported by server-side code also become part of the Function bundle.

For Vercel Functions outside Next.js, use includeFiles and excludeFiles when automatic tracing includes the wrong files. For Next.js, use outputFileTracingIncludes and outputFileTracingExcludes.

Test every changed function. Excluding a required file can cause a runtime error even when the build succeeds. See the functions configuration.

Verify one change at a time:

  1. Create one Preview deployment after each build-output change.
  2. Open the Preview URL and test the main application paths.
  3. Test each changed Vercel Function.
  4. Confirm that static files and runtime data load.
  5. Compare the new deployment Resources view with the baseline deployment.
  6. After Usage refreshes, compare the same project, metrics, and 30-day date range.
ChangeExpected resultWhen to check
Smaller static outputLower Deployment Storage per new deploymentAfter the changed Preview deployment appears in Usage
Smaller Function bundlesLower Functions Storage per new deploymentAfter the changed Preview deployment appears in Usage

Retention changes affect stored history over time. Output changes affect new deployments. Compare them separately.

For product details, see Deployment Storage.

Last updated August 21, 2026

Was this helpful?

supported.