Vercel · Vercel Deployment Storage

What Is a Deployment

Every Vercel deployment creates a separate Deployment — the actual artifact produced by that deployment — and assigns it its own access URL, for example: https://<domain>-kfqiciq3o-<project-id>-projects.vercel.app.

You can think of a Deployment as a snapshot: it lets you roll back to a specific version, inspect exactly what a given version contained, and debug problems in historical versions.

Taking a Next.js project as an example: after the build (Build) completes, the output is written to the out directory. That is the build output of the deployment, and Vercel saves it to Deployment Storage.

These files take up storage space and incur storage costs, which is why Deployment Storage has a usage limit.

Hobby Storage Limits

The Deployment Storage limit for Hobby teams is 10 GB. Once you go over the limit, new deployments are blocked until you free up storage space.

Vercel automatically cleans up expired historical deployments according to the Deployment Retention Policy, while keeping certain special deployments — for example the most recently created deployments, the current Production deployment, deployments with an Alias, and the latest Preview Deployment on a still-active Git branch.

Checking Usage

In the Vercel Dashboard, the Usage panel gives you a quick view of Deployment Storage usage across all Projects. For example, 1.39 GB / 10 GB means the build artifacts of all Projects together take up 1.39 GB.

You can also open a specific Project and check it in Overview.

Deleting Deployments

Open a Project's Deployment list, open the details page of a deployment, click the ⋯ (three-dot) button in the top-right corner, and choose Delete from the menu to delete that Deployment.

The web UI currently has no bulk-delete feature, so you can only delete deployments one at a time; if you need to clean up in bulk, use the Vercel CLI as shown below:

List deployments:

vercel list
 
# Output similar to
> Deployments for <account-projects>/<example.com> [472ms]
 
  Age      Project                              Deployment                                                        Status      Environment     Duration     Username
  10h      <account-projects>/<example.com>     https://<example.com>-i5a1iqk7h-<account-projects>.vercel.app     ● Ready     Production      2m           <vercel-account>
  10h      <account-projects>/<example.com>     https://<example.com>-kfqiciq3o-<account-projects>.vercel.app     ● Ready     Production      2m           <vercel-account>
  11h      <account-projects>/<example.com>     https://<example.com>-5i5a0pyzp-<account-projects>.vercel.app     ● Ready     Production      2m           <vercel-account>

Delete a specific deployment:

# Corresponding to the deployment URL above, for example:
# https://<example.com>-i5a1iqk7h-<account-projects>.vercel.app
vercel remove <deployment-url>

Delete several at once:

vercel remove <deployment-url-1> <deployment-url-2> <deployment-url-3>

Shorthand:

vercel rm <deployment-url>

Clean up the safely deletable deployments for a Project (--safe skips deployments that have an active Preview URL or Production Domain):

vercel remove <project-name> --safe
 
# Output similar to
 
> Found 18 deployments for removal in <account-projects> [2s]
> The following 18 deployments will be permanently removed:
  dpl_45krSoRPbDq3vrYRh6LSHkWkPVFj      https://<example.com>-kfqiciq3o-<account-projects>.vercel.app      10h ago
  dpl_9wBc6RopPyASsTjWoAzytccsHAai      https://<example.com>-ckuakbjx7-<account-projects>.vercel.app      9d ago
  ...
  dpl_4nCVdhVvMspVGBVxhSkbanRJB4vg      https://<example.com>-gvkrze2ry-<account-projects>.vercel.app      450d ago
# Enter y to confirm deletion
> Are you sure? (y/N) y
> Success! Removed 18 deployments [3s]
- <example.com>-kfqiciq3o-<account-projects>.vercel.app
...
- <example.com>-gvkrze2ry-<account-projects>.vercel.app

After deleting historical deployments:

Deployment deleted
        ↓
Fewer deployments actually retained
        ↓
Deployment Storage Usage updated

The last step is not instantaneous — there has been discussion in the community about this.

Vercel now updates the Dashboard based on the daily Deployment Storage state, rather than the previous Billing Period Maximum, so the numbers refresh more promptly.

So it is normal to still see the old Usage figure right after deleting deployments — just wait for the next daily statistics update.

Retention Policy

If you don't want to keep a large number of historical deployments long term, you can use the Deployment Retention Policy to configure how long each type of deployment is kept; deployments that reach the limit are deleted automatically. See the official documentation: Deployment Retention.

Where to configure it: in the console, go to Settings → Build and Deployment → Deployment Retention Policy. You can also type retention into the search box on the settings page to jump straight to it.

The default retention period for each plan is as follows:

Plan	Canceled	Errored	Pre-Production	Production
Hobby	30 days	30 days	30 days	30 days
Pro / Enterprise	30 days	90 days	180 days	1 year

Team-level policies override these defaults, while a project-level policy applies only to that project and takes precedence over the team default.

Note that Vercel does not delete every deployment the moment it exceeds the retention period. The following are still retained:

The most recently created deployments (Hobby keeps the latest 3, Pro / Enterprise the latest 10);
Production deployments in the Ready state (Hobby keeps the latest 3, Pro / Enterprise the latest 20);
Deployments that have a Production Alias;
Deployments targeted by a branch alias for a custom environment (Custom Environment);
Non-production deployments that have any custom alias;
The latest Preview Deployment on a still-active Git branch (the branch has not been deleted, and its associated Pull Request has not been merged or closed).

Once the retention period is reached, a background job usually marks the deployment for deletion within 48 hours; if it still matches one of the exceptions above, it is re-evaluated once the exception no longer applies, and that re-evaluation can take up to 30 days.

A deleted deployment can still be restored during its recovery period from Settings → Security → Recently Deleted; successfully built deployments have a 30-day recovery period, while failed builds may be garbage-collected sooner.

Other Considerations

If your source code is already managed by Git, then the version history is effectively already in Git: commits, branches, and tags are enough to restore any change, and to roll back you just check out the corresponding commit and redeploy. For personal projects, that is usually enough — there is no need to treat Deployment Storage as a version repository and let a large number of historical deployments pile up (all the more so given that Hobby only has 10 GB).

Deployment's advantage is that switching is fast: each Deployment is an artifact that was already built at the time, with its own access URL, and Rollback or Promote takes a single step. It requires neither a local rebuild nor a dependency on your local environment and dependency versions. By contrast, rolling back via Git requires a rebuild, and the output may not be exactly the same as it was, because dependency versions may have changed.

The two play different roles: Git records versions, while Deployment provides a snapshot that can be run directly. For personal projects, Git is usually enough to record versions; that does not mean Deployment is useless — it is still valuable when you need a fast rollback, want to share a preview with someone, or need an artifact that is exactly the same as it was at the time.