Product

Overview

How it works Watch it work All 35 features Screenshots How ForgeRepo™ is secured

Keep bad packages out

Malware scanning Typosquat detection Dependency confusion protection Cooling off new releases Allow lists and block lists

When something goes wrong

Kill switch Who has it Lockdown and degraded modes Vulnerability monitoring

Developers and approvals

Requests and auto approve Check, walk and review Waivers Dry run
Formats

Languages

Private npm registry PyPI proxy and private index Private NuGet feed and proxy Maven repository proxy RubyGems mirror Composer and Packagist proxy

Apple, containers and Linux

CocoaPods CDN mirror Swift package registry Docker registry mirror RPM mirror for dnf and yum APT mirror for Debian and Ubuntu

Use it as

An npm firewall Artifacts, SBOMs and lifecycle More than one node SSO, roles and allow lists
Learn

Guides

Learn secure development Secure coding Secure pipelines Unsafe vs safe Security and development

Supply chain

Supply chain attacks, 2016 to 2026 Software supply chain security
Compare Side by side, all four ForgeRepo™ vs JFrog ForgeRepo™ vs Sonatype ForgeRepo™ vs Cloudsmith
Docs

Start

Getting started Download All documentation Questions

For developers

npm setup pip setup docker login Push a Docker image CI basics

For administrators

First setup Rules and their order Six incidents, walked through Backup and upgrade
Pricing Install it
  1. Home
  2. Documentation
  3. Administrator Guide
  4. Writing rules

Rules and approvals

Writing rules

Patterns, version ranges, priority and scope, and how the winning rule is chosen.

12
  1. Higher priority wins first
  2. Scope a rule to the tokens of one application or environment
Higher priorityNarrower scope(app, env)Exact name, thenlonger patternDeny beforeallowWinner decidesNo rule matches: whitelist blocks,blacklist allowstietietie
Each step only matters when the step before it is a tie.
FieldNotes
PatternA name or a pattern where * matches anything, including the / in a scope. Up to 5 wildcards.
Kindallow or deny. A deny with a version range only blocks those versions, the rest of the package still comes through.
Version rangeEmpty means every version. See the table below.
Priority-1000 to 1000, default 0. Compared first.
Only for application / Only in environmentLimits the rule to tokens in that scope.
NoteWhy the rule exists. Shown to approvers, and worth writing.
TypeVersion range examples
npm4.21.2, 1.2.*, ^4.0.0, ~1.2.0, >=4.17.21, 1.2.3 || 1.4.5
PyPI==2.31.*, ~=2.31.0, >=2.31,<3, >=2.31,!=2.32.1
imageslatest, 1.27.*, stable-alpine, sha256:..., joined with ||
  • npm deny rules match names in any letter case. Allow rules match the exact case.
  • An allow covers a prerelease like 2.0.0-beta.1 only when its range names a prerelease. An allow with no range never covers prereleases.
  • Paste a list adds up to 2000 names at once.
  • Tick rules to flip, enable, disable or delete them together.
The rules list shows whether each rule is cached and whether its versions have advisories.

Caching approved versions ahead of time

Tick allow rules and click Cache now to download them before anyone needs them, up to 2000 files. A rule that pins exact versions caches those. A rule for any version caches the current release, and a range like ^4.0.0 caches the newest version it allows, without changing the rule. An image rule with a tag pattern like 1.27.* is skipped. Saving an allow rule for every version also caches the current version in the background when Cache the current version of any-version rules is on.

Note

For an image, Cached counts a tag only when every image in its list, and the config and every layer of each, is on disk. Walking an image's dependency tree or pulling one platform learns part of it, so the cell says how far along it is, like "26.04: 12 of 30 files downloaded". Cache now downloads the rest.