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

Formats and running it

A private npm registry and npm proxy

Point npm at ForgeRepo™ with one line of .npmrc. Nothing else changes for developers, and everything they pull now goes past your rules and into your cache.

registry=https://packages.example.com/
//packages.example.com/:_authToken=${NPM_TOKEN}

npm install resolves as it always does among the versions the rules allow, and the resolved addresses in package-lock.json point at your box, so npm ci rebuilds from the lockfile through it too, with npm checking every tarball against the integrity the lockfile recorded. pnpm, Yarn classic and Berry, and Bun work the same way.

Tarballs are cached on disk once, under their SHA-256, and checked against what npm published. Metadata is filtered on the way out, never in the cache. Stale metadata is served for as long as you say when npm is down.

Publishing

Reserve your scope, give your CI account the publisher role, and npm publish. Each publish adds exactly one version and its tarball must match its manifest. A published version never changes and is never removed: republishing and npm unpublish are refused, while npm deprecate and npm dist-tag work. A new version starts in quarantine until its malware scan comes back clean.

packages.example.com/_admin/
Packages. Everything asked for, what the rules say, and what is cached.

In short

  • npm, pnpm, Yarn and Bun, with lockfiles that point at your box
  • Caching proxy with integrity checks and stale while offline
  • Publish under reserved scopes, immutable versions
  • npm audit answered locally
  • Search, dist-tags and deprecations supported

In the documentation

Goes well with

  • PyPI proxy and private index pip, uv and Poetry. PEP 503, 691, 658 and 700, and twine uploads for your own projects.
  • Docker registry mirror Pull through Docker Hub, GHCR, Quay or Harbor, and push your own images to reserved namespaces. Everything by digest, the layers scanned.
  • Dependency confusion protection Reserve your npm scopes, PyPI prefixes, image namespaces and NuGet ids. A public package with your internal name is never fetched.

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.