> For the complete documentation index, see [llms.txt](https://docs.sealsecurity.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sealsecurity.io/setup-apps-os/artifact-server/cooldown.md).

# Cooldown period

A per-tenant policy that keeps newly published origin versions out of resolution for a set number of hours.

A cooldown period is a per-tenant policy of the Seal Artifact Server. When it is enabled for your tenant, an origin version published upstream within the last N hours is left out of the index and metadata responses the server returns, so your package manager resolves the previous release instead. Nothing fails, and no error is returned.

The policy exists to keep a build from picking up a brand-new release the moment it appears, before Seal or anyone else has had a chance to look at it.

The window is a whole number of hours, up to 168 (7 days), and it applies to every ecosystem the policy covers. It is a tenant-wide setting, not a per-build choice. It is opt-in and off by default (a window of 0 hours). Contact your Seal account team to set a cooldown period for your tenant.

This page assumes your package manager is already pointed at the Seal Artifact Server. See [Configuring package managers](/setup-apps-os/artifact-server/configuring-package-managers.md) for the basic setup.

## What the build sees

The build resolves the newest version that is outside the window. An `npm install <package>` for a package released this week installs the previous release, and the build succeeds as usual. Nothing in the response tells the client that a version was left out, so there is no error to handle and no message to read.

Sealed versions are never subject to a cooldown period. A sealed version is served and listed as usual however recently it was released, so replacing an origin version with its sealed version is unaffected.

## Where the policy applies

The cooldown period applies to the responses your package manager reads when it is deciding which version to use:

| Ecosystem | Filtered responses                                                                               |
| --------- | ------------------------------------------------------------------------------------------------ |
| npm       | the packument                                                                                    |
| Python    | the PEP 503 simple index, the PEP 691 JSON simple index, and the `/pypi/<package>/json` response |
| Go        | `@v/list` and `@latest`                                                                          |

A few behaviours follow from filtering those responses:

* **npm dist-tags are repaired, not dropped.** A tag such as `latest` that names a version inside the window is re-pointed at the newest origin version outside it, so a plain `npm install <package>` resolves instead of failing. Sealed versions are never promoted into a tag.
* **`/pypi/<package>/json` stays self-consistent.** When the release named by `info.version` is inside the window, `info.version` and `urls` are re-pointed together at the newest release outside it.
* **Go `@latest` never fails.** When the version `@latest` names is inside the window, the server answers with the newest surviving release rather than an error, so the go command stays with Seal instead of falling through to the next `GOPROXY` entry.

Maven and Gradle, Composer, NuGet, and RubyGems are not covered today, and neither are the OS ecosystems (RPM, DEB, and APK). Requests in those ecosystems are served exactly as they are without a cooldown period.

## What a cooldown period does not change

* **Downloads are untouched.** A cooldown period governs resolution, not consumption. A build that already knows the exact version it wants still downloads it: a lockfile, `npm ci`, `pip install <package>==<version>`, and `go get <module>@<version>` all fetch the version they name, whether or not it is inside the window.
* **Only the responses listed above are filtered.** Other surfaces of the same ecosystem are not: npm search results, Go pseudo-versions, and any client configured to list a public registry alongside Seal (rather than through Seal) all see the unfiltered upstream list.
* **A cooldown period is not an enforcement boundary.** It shapes what your build resolves to by default. To have the server refuse to serve a version outright, see [Blocking vulnerable downloads](/setup-apps-os/artifact-server/download-blocking.md).

## Related

* [Blocking vulnerable downloads](/setup-apps-os/artifact-server/download-blocking.md): the per-tenant policies that refuse to serve versions with open malicious or high and critical vulnerabilities.
* [Transparent safest relocation](/setup-apps-os/artifact-server/transparent-safest.md): the per-tenant mode that serves the safest sealed version for a plain origin-version request.
* [Configuring package managers](/setup-apps-os/artifact-server/configuring-package-managers.md): pointing your package manager at the Seal Artifact Server.