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

Running more than one node

One box is the right answer for most teams. When it is not, set DB_HOST and the second node joins the first.

By default the database lives inside the container on a unix socket. Set DB_HOST and a node uses an outside MySQL or MariaDB instead, RDS, Cloud SQL or your own, over TLS with DB_SSL=rds verifying Amazon's CA. Rules, users, sessions, tokens, requests, allow lists, settings, the audit trail and findings are shared. migrate-db.js --check moves an existing box onto the shared database, checking everything before it copies anything.

Cached files are local to each node unless the cache is in S3 or Azure. Settings reach other nodes within 30 seconds and rules within 5. Background jobs run on every node, so an active and passive pair behind a health checking load balancer is the calmer setup, and the docs say so.

Utilization shows live gauges for CPU, memory, the data disk and network, with ForgeRepo™'s own share, and trends for a day, a week, a month or a year, all without the Docker socket.

Honest limit: this is not a clustered product in the way the commercial HA editions are, with a vendor behind the failover. It is a shared database and a load balancer, done carefully.

packages.example.com/_admin/
Utilization. Live gauges, and trends you can drag to zoom.

In short

  • Shared MySQL or MariaDB, RDS and Cloud SQL tested
  • Schema builds itself on an empty database
  • Cache shared through S3 or Azure
  • Active and passive recommended, active and active works
  • Utilization gauges and a year of history

In the documentation

Goes well with

  • S3 and Azure storage Keep the cache in a bucket. Every upload checked by hash, and a local copy cap on the disk.
  • SSO, roles and allow lists OpenID Connect, five roles checked on every request, IP allow lists and break glass keys.
  • SIEM and email Signed webhooks, Splunk HEC and syslog in JSON or CEF. Digests instead of a mail per event.

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.