> For the complete documentation index, see [llms.txt](https://argos-ci.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://argos-ci.com/docs/learn/deployments/retention.md).
# Lifecycle and retention
Deployments are permanent, immutable records. Once a deployment is ready, it keeps working at its own URL and Argos never expires it, replaces it in place, or removes it automatically. This page explains what that means for how you deploy and how often.
### How long deployments last
A deployment has no expiration. It stays reachable at its immutable [deployment URL](/docs/learn/deployments/urls-and-domains.md#deployment-url) for as long as the project exists—whether it was created minutes ago or months ago.
There is no retention window to configure and nothing that ages deployments out. The only way a deployment stops existing is if you delete the whole project (see [Deleting deployments](#deleting-deployments)).
### Overwriting a deployment
You can't overwrite a deployment. Every `argos deploy` run creates a **new** deployment with its own immutable URL—the previous one keeps working untouched.
What moves instead of being overwritten are the shared URLs:
* The [branch URL](/docs/learn/deployments/urls-and-domains.md#branch-url) always points at the latest deployment on that branch. Re-deploying the same branch updates the branch URL to the new build; the previous deployment stays available at its own deployment URL.
* The [production domain](/docs/learn/deployments/urls-and-domains.md#production-domain) always serves the latest promoted production deployment. A new production deployment takes over the domain immediately; earlier production builds stay reachable on their own URLs.
So from a reviewer's point of view, a new deploy on the same branch effectively supersedes the old one—the link they use keeps showing the latest build—without any manual cleanup, and without losing the older builds' stable URLs.
### Deleting deployments
Individual deployments can't be deleted, the same way [builds are immutable records](/docs/learn/review-workflow/builds-list.md#faq). There's no bulk-delete and nothing you need to clear out: deployments don't age, and they don't count toward your [screenshot quota](/docs/learn/billing-and-subscription/pricing-plans.md) (that quota applies to visual testing, not deployments).
If you ever need to remove every deployment for a project, delete the project from **Settings → General**. This removes the project entirely, including its builds and deployments, and can't be undone.
### Choosing a deploy cadence
Because deployments never pile up in a way you have to manage, you can deploy as often—or as rarely—as fits your workflow:
* **On every pull request** — The most common setup. Each PR push creates a preview deployment and the link appears in the [pull request comment](/docs/learn/review-workflow/pull-request-comments.md). See [Use deployments in CI](/docs/learn/deployments/use-deployments-in-ci.md).
* **On a subset of pull requests** — If you don't need a preview on every PR, gate the deploy step on a label (for example, only run `argos deploy` when a `deploy-preview` label is present) or on changes to the relevant directory.
* **On releases** — Deploy to [production](/docs/learn/deployments/environments.md#production-deployments) from your release branch, either by matching the [production branch pattern](/docs/learn/deployments/environments.md#configure-the-production-branch) or by passing `--prod`.
Attaching previews to a PR label and running production deploys on releases is a perfectly reasonable setup—there's no downside to old deployments sticking around, and no cleanup step to schedule.
### FAQ
How long do deployments stick around?
Indefinitely. Deployments don't expire—each one stays reachable at its immutable deployment URL for as long as the project exists.
Can I overwrite a previous deployment?
No. Every deploy creates a new immutable deployment. The branch URL and production domain automatically move to point at the latest build, so the links people share stay current, while older builds remain available at their own URLs.
Do I have to bulk-delete old deployments to clear them out?
No. There's nothing to clean up—deployments don't age out and don't count toward your screenshot quota. Individual deployments can't be deleted; the only way to remove them all is to delete the project.
### Related
* [Deployments overview](/docs/learn/deployments.md)
* [URLs and domains](/docs/learn/deployments/urls-and-domains.md)
* [Environments](/docs/learn/deployments/environments.md)
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://argos-ci.com/docs/learn/deployments/retention.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.