pnpm's minimumReleaseAge is a number of minutes a version must have been published before pnpm will install it. Since pnpm v11 the default is 1440, one day. Strict mode decides whether pnpm fails or falls back to a newer version when nothing old enough fits your range.
The basic setting
The pnpm docs describe the reasoning plainly: most malicious releases are discovered and removed from the registry within an hour, so a delay reduces the chance of installing one. The setting applies to every dependency, including transitive ones. It was added in v10.16.0 with a default of 0, and the default changed to 1440 in v11.
# pnpm-workspace.yaml
minimumReleaseAge: 1440
One exception is documented: a config dependency pinned with version and integrity is not subject to the age check.
Strict or not
This is the part most teams miss. minimumReleaseAgeStrict controls what happens when no version in the requested range is old enough.
| Strict value | Behavior when nothing is old enough |
|---|---|
| false | pnpm falls back to a version that does not meet the age, so the install still succeeds |
| true | pnpm fails resolution |
The default depends on how you got the age. If you set minimumReleaseAge yourself, in pnpm-workspace.yaml, the global config, a PNPM_CONFIG variable or on the command line, strict is on by default. The built-in 1440 default is non-strict for backward compatibility.
So a project relying on the built-in default can still receive a brand new version in the fallback case. If you want the delay to be a real gate, write the value down explicitly or set strict to true.
Letting urgent fixes through
A delay also delays security patches. minimumReleaseAgeExclude lets named packages bypass the rule:
minimumReleaseAge: 1440
minimumReleaseAgeExclude:
- '@myorg/*'
- nx@21.6.5
- webpack@4.47.0 || 5.102.1
Patterns arrived in v10.17.0, and exact version exemptions in v10.19.0. Keep exceptions narrow. A whole-package exclusion applies to all versions of that package, while a version selector exempts only the release you reviewed.
Setting minimumReleaseAgeExcludePrune to true (v11.22.0) lets pnpm remove exclusion entries that the freshly written lockfile no longer resolves, so exceptions do not pile up.
Mirrors that omit publish dates
The check needs the time field from registry metadata. Some private registries and mirrors leave it out. minimumReleaseAgeIgnoreMissingTime defaults to true since v11.0.0, which means pnpm skips the age check for such a package. If your internal mirror drops dates, your delay silently does nothing for those packages. Set the option to false to fail instead, and fix the mirror.
A rollout plan
- Write minimumReleaseAge explicitly so strict mode turns on.
- Run the install in CI and list failures.
- Add narrow excludes for packages you must take on release day.
- Confirm your mirror returns publish dates.
- Review the exclude list each quarter.
For the general idea across managers, see minimum release age cooldown policies.
Where Safeguard fits
An age delay lowers risk at install time but does not tell you what is in your tree today. Safeguard's dependency scanning and SBOM generation read your lockfiles, and continuous monitoring flags a component when a new advisory lands. A free scan is at https://gold.safeguard.sh/scan.
Quick check
What is the pnpm default release age in version 11?
1440 minutes, which is one day. Before v11 the default was 0.
Why did my install pick a version newer than the age I set?
If you relied on the built-in default, strict mode is off and pnpm falls back to a newer version when nothing old enough satisfies the range. Set the age explicitly or turn strict on.
Sources
Last reviewed: 19 October 2026.
