The ones that come up, answered without marketing

A free, self hosted registry that sits between your developers, your pipelines and the public registries: npm, PyPI, container images, NuGet, Maven, RubyGems, Composer, CocoaPods, Swift packages, and RPM and APT repositories. It proxies and caches them, checks every request against your rules and your security settings, and refuses anything that fails with a clear reason. It is sometimes called a package firewall, a registry firewall or a curation proxy.

It is MIT licensed. There is no paid tier, no feature held back, no seat count and no telemetry. The catch is the honest one: there is no company behind it selling support. You run it, and when it breaks you have the source, the documentation and the logs.

npm, pnpm, Yarn (classic and Berry) and Bun for JavaScript. pip, uv, Poetry and twine for Python. docker, podman, skopeo, compose and Kubernetes for container images. dotnet, nuget.exe and Visual Studio for NuGet. mvn, Gradle and sbt for Maven. Bundler and gem for Ruby. composer for PHP. pod for CocoaPods. SwiftPM for Swift. dnf and yum for RPM, and apt for Debian and Ubuntu. Anything that speaks those protocols works, because nothing about the clients changes except the address.

Maven and NuGet, yes, along with RubyGems, Composer, CocoaPods, Swift packages, and RPM and APT mirrors. Each one is switched on under Settings, Package types. Go and Cargo, no. If you need those behind the same policy, JFrog, Sonatype and Cloudsmith all cover thirty formats or more, and the comparison page says so plainly.

Yes, under image names you reserve, with a token whose owner is a publisher. Every layer is held until its malware scan is clean, a pushed tag never moves, and nothing pushed is deleted. npm publish, twine uploads and dotnet nuget push work the same way, for reserved names. Maven deploys and gem push are not taken.

It overlaps with both, as a private npm registry and a private Python index, and adds what they do not focus on: allow lists enforced in metadata, malware scanning, cooling off, typosquat and dependency confusion protection, a kill switch, request and approval, and an audit trail.

A Linux server with Docker, or without it, since the installer adds it. A DNS name and a TLS certificate on a reverse proxy in front. About 2 GB of disk to start. Ubuntu 22.04 and 24.04 are tested, and Debian and the RHEL family should work with the same steps.

We measured 96 seconds on a clean Ubuntu 24.04 server, from downloading the script to a registry answering its health check, most of it building the image. The getting started page replays that run.

sudo ./setup.sh --upgrade in the install directory. It pulls the latest code, tags the running image as npm-repo:previous, rebuilds and restarts, and leaves .env and your data alone. The schema updates itself on start. Plain docker compose up -d does not rebuild, which is the usual reason an upgrade seems to do nothing.

Yes, with the upstream switched off or the registry in lockdown mode it only serves what it has cached, and never calls out. Fill the cache first with Cache the ticked rules, or move a data directory across. Advisory feeds need a way out to update, and say so when they cannot reach it. Take osv out of the scanner list too, since the known malicious check answers error rather than clean when osv.dev cannot be reached.

Yes. Point each node at one MySQL or MariaDB with DB_HOST, RDS included, and keep the cache in S3 or Azure. An active and passive pair behind a health checking load balancer is the recommended setup.

In layers, because no single one is enough. A whitelist means unknown packages are refused. Cooling off keeps brand new releases away for a few days, which is when hijacks get caught. ClamAV, a hash blocklist or your own scanner check every file, optionally before the first download, and every name and version is checked against the OpenSSF malicious packages feed. Lookalike names are warned about or refused. And when one gets through anyway, the kill switch takes it away from everyone at once.

No, and it would be dishonest to suggest otherwise. JFrog and Sonatype employ researchers who analyze new packages as they are published. ForgeRepo™ uses signature scanning, the public OpenSSF malicious packages feed through osv.dev, advisory feeds and policy. The feed only knows what has been reported, but a package reported after you cached it goes on the kill switch by itself. For many teams the layers above are enough, and for some they are not.

Somebody publishes a package on a public registry using the name of one of your internal packages, and a build that looks in both places picks theirs. ForgeRepo™ prevents it with reserved names, which are never fetched from outside, and with routing by pattern, so each scope comes from exactly one registry with no silent fallback.

The download is refused with a 403 that names the reason, for example the rule or the kill switch note you wrote. Ranges resolve around blocked versions on their own, because blocked versions are removed from the metadata, but an exact pin asks for that one file.

No. npm audit is answered from local findings. Advisory lookups and the known malicious check send package names and versions to osv.dev, never files, and EPSS lookups send CVE ids. There is no telemetry, and reviewed lockfiles are read in memory and never stored.

It is written against the OWASP Top 10, with every permission checked on the server, object level access checked on every request, credentials stored as hashes and never shown twice, and outbound calls guarded against server side request forgery. The security page has the detail. If you find something, please report it privately.

It can, which is why there is audit only mode. For a week or two ForgeRepo™ serves everything, and opens a request for whatever no rule covers, with the exact versions used. Approve those, switch to whitelist, and nobody hits a wall on day one. After that, a blocked install opens a request by itself, and auto approve can take the clean ones.

Every file of the request is downloaded and malware scanned, and the versions are checked against the advisory feeds. It approves only when every file scans clean and the worst advisory is below High. A kill, a deny rule, a lookalike name, a reserved name, a held license or a missing scan answer always leaves it for a person, and the row says why.

From the error itself. npm and pip print the reason and the portal address, and a blocked install opens a request. In the portal, every line of the traffic log has a why link that shows the rule or check, the evidence, and what to do next.

Yes. Every token belongs to an application and an environment, and rules, waivers and lifecycle stages can be scoped to either or both. Production can block something dev is allowed to use, and with lifecycle stages enforced, production only gets versions promoted to it.

Consumers: search the package, a version range, a file SHA-256 or a CVE, GHSA or PYSEC id. It lists the applications and environments with production flagged, the developers and pipelines, the addresses, and the first and last download.

A cached package is served from local disk, so repeat installs are usually faster than going to the public registry. The first fetch of a new package pays the upstream download once, plus a scan if scan before serving is on.

JFrog is far broader, with about fifty formats, a research team, federation and an SLA. Blocking before download is Curation, a paid add-on on its top tiers. ForgeRepo™ does eleven formats, including npm, PyPI, images, NuGet and Maven, with blocking and a kill switch free. The full comparison.

Nexus Community Edition is free up to 40,000 components or 100,000 requests a day, and blocking needs Repository Firewall on Nexus Pro. Sonatype's research and quarantine are excellent. The full comparison.

Cloudsmith is fully managed SaaS with thirty three formats and a CDN, and its security policies are on the Ultra and Enterprise plans. ForgeRepo™ is self hosted, so packages never leave your network. The full comparison.

Tim Rice, who also wrote Failover LB, SQL Cluster and Git Code Review, all free and open source. ForgeRepo™ started as the npm registry for a real company, and was given away.

Yes. The MIT license lets you use it, change it, and ship it inside your own product, commercially or not, as long as the copyright notice stays with it.

The source is at github.com/hackrange/forgerepo. Issues and fixes are welcome there. For a security problem, please report it privately rather than in a public issue.