Hide NuGet versions younger than you allow.
For every developer and every build. Hosted, in front of a public-only Azure Artifacts feed. You set the number of days (14 by default), and can override it per package.
Works with Azure Artifacts and NuGet today. On the roadmap: npm, other package repositories, and malware scanning.
Early access is limited and unbilled. We reply by email.
What your developers see
A floating range 2.* resolves to 2.3.7, with no error.
An exact pin on 2.4.0 fails the restore.
An example package with illustrative ages. Drag the slider to see which versions clear a different cooldown.
A new version can reach your builds within hours of publication.
Most teams pull whatever is newest. If an attacker publishes a bad release of a package you use, your next restore can fetch it before anyone has noticed. A waiting period gives the community time to catch it.
Dependency-update bots can delay the pull requests they open. They do not control what a restore on a laptop or in a pipeline can fetch. Packmoat enforces the delay at restore time, for everyone who uses it.
How it works
1. Point restores at Packmoat
Developers and build agents use a Packmoat address and a Packmoat token as their NuGet source. Their Azure DevOps tokens never reach us.
2. Packmoat checks the age
It looks up each version's publish date on nuget.org and hides anything younger than your cooldown, from version lists and from downloads.
3. Your feed stays yours
Allowed requests go to a public-only Azure Artifacts feed in your organization. Your private packages stay in a separate feed.
What happens in your builds
- Lists hide young versions. A hidden version does not appear in version lists or in downloads.
- Floating ranges fall back quietly. A range such as 2.* picks the newest version that has cleared the cooldown. A build can use an older version with no warning.
- Exact pins fail. A pin on a version still inside the cooldown fails the restore with NuGet's standard "unable to find package" error.
- Unknown age means hidden. If Packmoat cannot determine a publish date, it hides the version rather than let it through.
- Waivers. During early access, ask us to waive a version and we record it. Self-service waivers are on the roadmap.
Request early access
We admit a small number of teams. Early access is limited and unbilled, and we reply by email.
Questions
What is a cooldown, and is 14 days the right number?
A cooldown holds back new releases for a fixed period. A waiting period gives the community time to notice and pull a bad release, so waiting reduces your exposure. Fourteen days is the default, and you can set a different number for your whole organization. Per-package cooldowns are on the roadmap.
What if we need a security patch that is still inside the cooldown?
During early access, ask us to waive that version and we will record it. Self-service waivers with an audit record are on the roadmap, and we make no speed commitment yet. Until then you can pin to the last cleared version.
Does Packmoat see our developers' Azure credentials?
By design, no. Developers and build agents sign in with a Packmoat token, and their Azure DevOps tokens never reach us. In testing, wrong tokens were rejected and no Azure credential appeared in responses.
Can Packmoat see our private packages?
Only if your Azure permissions allow it. Packmoat's identity can read exactly what your Azure permissions let it read. Follow the setup checklist above and re-check permissions after any change.
What happens if Packmoat is down?
Restores through Packmoat fail, and by default there is no way around the cooldown. If we cannot determine a version's publish date, we hide that version rather than let it through. We have no availability guarantee during early access. A customer-controlled emergency bypass is on the roadmap.
Which IP address do we allowlist, and does it change?
A single fixed address for allowlisting is available on request. It is one address on one server in New York, with no regional failover and no standby address yet. We have not set a notice period for changing it. We will set one when the first customer asks.
We already use a dependency-update bot. Why do we need this?
Those bots control which upgrade pull requests are opened. Packmoat controls what any restore can fetch, on a laptop or in a pipeline. If a bot-based cooldown already meets your needs, you may not need Packmoat.
Can Azure Artifacts do this by itself?
Azure Artifacts records when a package was saved to the feed, not when it was published, so it cannot hide versions by publish age. Packmoat gets publish dates from nuget.org and filters on those.
Do you scan packages for malware?
No. Today Packmoat applies the cooldown only. Malware checks are on the roadmap.
Does a cooldown stop every supply-chain attack?
No. It reduces your exposure to newly published malicious versions. It does not help when a malicious package goes unnoticed past the cooldown, or with code your own team wrote.
Can developers go around it?
Only if direct access is left open. If developers can still reach nuget.org or your feed's own address, they can skip Packmoat. The setup checklist closes those paths, but Packmoat cannot stop access that your Azure permissions still allow.
Who are you, and what if you shut down?
Packmoat is an early, private project run by its founder. If we shut down, restores through Packmoat would stop, but your feeds stay in your Azure organization and you can point your tools back at them.
Ready to try a cooldown?
Early access is limited and unbilled. We will reply by email.