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 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.

Related

• Blocking vulnerable downloads: the per-tenant policies that refuse to serve versions with open malicious or high and critical vulnerabilities.

• Transparent safest relocation: the per-tenant mode that serves the safest sealed version for a plain origin-version request.

• Configuring package managers: pointing your package manager at the Seal Artifact Server.