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

Developers and approvals

Tokens, applications and environments

A token is a person or a pipeline. With an application and an environment on it, every download says which team and which stage it landed in.

Developers make their own tokens, name them after where they are used, and pick an expiry. The token is shown once, with the exact npm, pip and docker commands to use it. An admin places each token in an application and an environment from the lists under Settings, Applications, and ticks which environments are production.

From then on every request that token makes is stamped with both names, copied onto the row as it is written, so months later a revoked or moved token cannot rewrite history. A rule, a waiver or a lifecycle stage can be scoped to an application, an environment, or an application in an environment. The scope comes only from the token, never from anything the client sends.

Require tokens makes every client prove who it is. A token can also be the way through the client network allow list, which keeps working when a CI runner moves or GitHub publishes a new address range.

packages.example.com/_admin/
A new token, with the commands for npm, pip and docker underneath.

In short

  • Per person and per pipeline tokens, shown once, revocable one at a time
  • Application and environment on every download
  • Rules, waivers and lifecycle stages scoped to them
  • Scope read only from the token, never from the client
  • A contact address per token for shared build tokens

In the documentation

Goes well with

  • Who has it Search a package, a hash or a CVE and see the applications, environments and pipelines that pulled it.
  • Allow lists and block lists Whitelist or blacklist by name, scope, wildcard or version range, for every type. A blocked version is not even listed to the client.
  • SSO, roles and allow lists OpenID Connect, five roles checked on every request, IP allow lists and break glass keys.

One container, about two minutes

A Linux box with Docker, or one without it, and a reverse proxy for TLS. The installer does the rest and it is safe to run twice. Free, MIT licensed, nothing to sign up for.