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:
- Open Team Settings.
- Select Security & Privacy.
- Find Deployment Retention Policy.
- Set the periods for Canceled, Errored, Pre-Production, and Production deployments.
- Clear Apply this policy to all existing projects unless you intend to update every existing project.
- 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:
- Open the project.
- Select Settings, then Security.
- Find Deployment Retention Policy.
- Set the periods for this project.
- 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 state | Keep long enough for |
|---|---|
| Pre-Production | Code review, quality assurance, external approvals, and regression investigation |
| Production | Incident recovery, rollback, and release audits |
| Canceled and Errored | Build debugging |
Use the same team and date range for each comparison:
- Open Usage for the correct team and select Deployment Storage.
- Set the date range to the last 30 days.
- Record the team total for Deployment Storage and Functions Storage.
- For both metrics, select Projects and record the projects with the most storage.
- 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:
- Open Usage for the correct team.
- Select Deployment Storage.
- Open Deployment Storage and select Projects.
- Repeat the review for Functions Storage.
- Use the same date range for both metrics.
- 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 find | Where to check next | Next action |
|---|---|---|
| A project has high Deployment Storage | Open a representative deployment and review Resources, then Static Assets | Remove unneeded static output and large packaged files. |
| A project has high Functions Storage | Open a representative deployment and review Resources, then Functions | Inspect large bundles and confirm that each configured region is required. |
| A project has many old Preview deployments | Review the project's Deployments page and Pre-Production retention policy | Shorten Pre-Production retention after the project owner confirms the required review period. |
| A project has many old Production deployments | Review the project's Deployments page and Production retention policy | Confirm the rollback and audit window before you shorten retention. |
| Storage remains high after a retention change | Review retention policy exceptions, including active aliases and the latest Preview deployment for each active Git branch | Confirm 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 unexpectedly | Compare deployments with Git commits, deploy hooks, webhooks, continuous integration jobs, and coding-agent activity | Fix 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:
- Create one Preview deployment after each build-output change.
- Open the Preview URL and test the main application paths.
- Test each changed Vercel Function.
- Confirm that static files and runtime data load.
- Compare the new deployment Resources view with the baseline deployment.
- After Usage refreshes, compare the same project, metrics, and 30-day date range.
| Change | Expected result | When to check |
|---|---|---|
| Smaller static output | Lower Deployment Storage per new deployment | After the changed Preview deployment appears in Usage |
| Smaller Function bundles | Lower Functions Storage per new deployment | After 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.
Was this helpful?