Summary: On November 6, 2026, Vercel shipped a new --delete-project-after flag for Vercel CLI that lets you set a brand-new project to expire. Once the expiration date passes, Vercel deletes the project automatically. If you spin up prototypes, demos, and test apps faster than you clean them up, this moves that cleanup from your todo list to the platform.
The problem it solves
Every builder I know has a Vercel dashboard full of orphaned projects: the demo deployed for a single client call, the hackathon throwaway, the preview app an agent created last week that nobody remembers owning. Individually they’re harmless. Collectively they clutter the dashboard, muddy the project list your teammates see, and carry whatever environment variables you attached to them.
Until now, the only fix was manual: notice the project, open its settings, delete it, confirm. The new flag makes deletion a property of the project at creation time. As Vercel’s changelog puts it, expired projects are deleted automatically, so prototypes, demos, and test apps don’t need cleaning up by hand.
How the flag actually works
The mechanics are simple. You pass the flag to vercel deploy along with a duration:
# Delete the new project after one day
vercel deploy --delete-project-after 1dFive durations are supported: 1h, 1d, 1w, 2w, and 30d. When the deploy runs, the CLI prints the exact date and time when the project will expire, so you’re never guessing about the countdown. That printed timestamp matters in scripts and CI, where a human might not be watching the output — log it if you need to audit what’s scheduled for deletion.
The undo path is also a first-class command rather than a settings page hunt:
vercel project keep my-projectThat removes the expiration and the project behaves like any other long-lived project again. So the workflow for a demo that might turn into something real is: deploy it with an expiration, and if the demo earns a longer life, run keep before the clock runs out.
You need Vercel CLI v65.12.0 or later. Check your version before scripting around this, since older CLIs will either ignore the flag or fail in ways your CI logs may not surface clearly.
The one constraint to internalize
Here’s the catch, and it’s worth repeating because it will bite someone on your team: the flag only applies when vercel deploy creates the project. If you deploy to an existing project and pass --delete-project-after, the project’s expiration does not change — the CLI just prints a warning and continues.
That’s a deliberate design, presumably to prevent an accidental deploy from wiping out a project your team relies on, but it changes how you should use the flag. You cannot retrofit an expiration onto an existing mess of old test projects. For those, cleanup stays manual. The flag works best when you adopt it as a habit going forward: every throwaway deploy starts life with an expiry attached.
It’s also worth noting the published vercel deploy documentation pages don’t document --delete-project-after in the option list I reviewed, so the changelog is currently the clearest reference for the flag’s behavior. If you’re writing internal tooling against it, test against v65.12.0 explicitly rather than trusting docs you haven’t verified.
One subtlety for scripted deploys
If you’re building automation on top of the CLI — say, an agent that scaffolds demo apps on demand — there’s a related behavior worth knowing. According to Vercel’s own deploy documentation, the first deployment of a new project is always a production deployment, even when you omit --prod. Combined with the expiration flag, that means a scripted one-shot deploy goes straight to a production URL and then deletes itself on schedule.
That combination is actually a neat pattern for agent-driven workflows. Deploy, get a shareable production URL immediately, let the platform reclaim the project when the demo window closes. It’s the same instinct behind ephemeral compute: give the workload exactly the lifetime it needs. I made a similar point when writing about Vercel Drives going GA for persistent agent state — the platform is steadily splitting its primitives into things that persist and things that expire, and this flag extends that split to whole projects.
What the sources don’t tell you
A few open questions before you build critical workflows on this. The changelog doesn’t specify what happens to custom domains or aliases attached to an expiring project, or whether deletion is recoverable after the fact. It also doesn’t say whether there’s any warning period before deletion, which matters if you’re relying on keep as your escape hatch — if the project vanishes first, keep has nothing left to save. And the sources don’t establish whether expiration can be set through any path other than project creation, so assume you can’t for now.
What to do next
Two practical steps. First, update your CLI to v65.12.0 or later and run one real throwaway deploy with --delete-project-after 1h — verify the printed expiration timestamp appears where your CI logs it, and confirm vercel project keep reverses it before you trust it with anything you care about. Second, if your team has standing conventions for demo deploys, add the flag to the template now; the flag’s creation-time-only constraint means the habit has to start at deploy number one, not after the dashboard is already messy.
One careful exception: anything holding state you’d mourn — a database connection, a domain you want to reuse, env vars nobody documented — should stay expiration-free until you’ve confirmed how deletion treats those attachments.
Sources
View the original post on X