← Blog · Guides

Vercel project expiry: the flag that only works on a new project

November 6, 2026

On 6 November 2026 Vercel added a way to make a project delete itself. The changelog entry opens: "You can now set a new project to expire when you deploy it with Vercel CLI." The reason it gives is a good one: "Expired projects are deleted automatically, so prototypes, demos, and test apps don't need cleaning up by hand."

The useful part for anyone scripting deploys is one sentence further down, and the word that matters in the opening line is new. This article covers what shipped, the one case where the flag does nothing, and the general lesson about where an expiry date lives.

What Vercel shipped

The mechanism is a single flag on vercel deploy:

vercel deploy --delete-project-after 1d
  • Durations: exactly five values are supported: 1h, 1d, 1w, 2w and 30d. There is no 3-day or 90-day option. If your demo needs four days, the next value up is a week.
  • Confirmation: the CLI prints the date and time when the project expires.
  • Cancelling: vercel project keep my-project removes the expiry.
  • Version: it needs Vercel CLI v65.12.0 or later.

Two things the entry does not tell you. It says nothing about pricing or which plans can use the flag, and we have not found that stated anywhere else, so we are not guessing. And on 7 November 2026 the CLI reference pages for vercel deploy and vercel project did not yet list the flag or the keep subcommand. For now the changelog entry is the only documentation.

The flag only works when the project is created

Here is the sentence that decides how you can use it: "The flag only applies when vercel deploy creates the project. If you deploy to an existing project with the flag, its expiration doesn't change and the CLI prints a warning."

So the expiry is set once, at creation, and the same command cannot manage it afterwards. That rules out two assumptions people tend to make.

  • "I'll add the flag to my existing deploy script." If the project already exists, nothing changes except a warning in the output. In CI that warning sits in a log nobody reads, and the project you meant to clean up stays.
  • "Each redeploy with the flag resets the clock." It does not. A deploy that passes the flag to an existing project leaves the expiration as it was. A demo created with 1w on Monday still expires the following Monday, however many times you redeploy it with 1w during the week.

The entry describes one way to change an expiry after creation, vercel project keep, and that removes it. It does not describe extending one, and it does not say what a deploy without the flag does to a project that is set to expire. If you depend on either, test it on a throwaway project first.

Using it in a script

Because the flag only counts at creation, it suits workflows that create a fresh project each time. One example is a demo per pull request, each with its own project name, so that every run really does create the project:

# a new project per pull request, deleted after two weeks
vercel deploy --yes --delete-project-after 2w

# changed your mind about one of them
vercel project keep my-demo-pr-123

(--yes accepts the defaults when the CLI sets up a new project.) Two habits make this safer:

  • Read the expiry line the CLI prints. If it is missing, the project already existed and the flag did nothing.
  • Treat the warning as a failure in CI. If your pipeline expects a self-deleting project, a warning that the expiration did not change means the pipeline is not doing what you think.

This is a different feature from Vercel's --temporary deployments. Those are for deploying without logging in: the CLI prints a claim URL and how long the deployment has before it expires, and you claim it to keep it. Project expiry is for logged-in users who choose a lifetime for a project they own.

The same lesson as last week's cron article

In where a scheduled job lives we said a cron entry stored in the platform is not in your repository, nobody reviews it, and it does not roll back when your code does. An expiry date is the same kind of state. It is held by the platform and fixed when the project is created, and nothing in your repository shows that a project is due to be deleted. Reverting a commit will not cancel it. The command that set it is in your shell history or a CI log, not in a file anyone reviews. If a project matters, check it with the platform, not with your code.

Does DeployBase do this?

No. We read our own code before writing this section. DeployBase has no expiry setting for an app: nothing in our deploy path accepts a lifetime, and no scheduled job deletes an app because a date has passed. The same applies to staging environments (included from the Business plan up). A staging copy stays until someone clicks Delete Staging on the app's page in the dashboard.

For prototypes and demos, that means you do the cleanup. Write the date you plan to delete a demo app somewhere your team will see it, and delete it from the dashboard when the date comes. It is more manual than Vercel's flag, but nothing on our side deletes an app on a timer that someone else set.

Checklist

  • The flag sets an expiry only on a vercel deploy that creates the project. On an existing project you get a warning and no change.
  • Durations are fixed: 1h, 1d, 1w, 2w, 30d.
  • vercel project keep cancels an expiry. Run it before the date, not after.
  • Upgrade to CLI v65.12.0 or later first.
  • Pricing and plan limits are not stated in the announcement.

Sources: Vercel changelog, "Vercel CLI can now set new projects to expire", published 6 November 2026, read in full 7 November 2026; Vercel CLI reference pages for vercel deploy and vercel project, read 7 November 2026. DeployBase behaviour checked against our own code on 7 November 2026.