The footprint number we're not going to quote you

A package firewall sits in the path of every dependency your team pulls. That buys you a decision point — and it also means the thing is running, all the time, on infrastructure someone has to operate. So “what does it cost to run at idle” is a fair question to ask before you put one in front of your builds.

We measured ours, on one laptop, against two repository managers. The results give us three different true ratios. The largest is 260×, and we’re not going to use it. This post is mostly about why.

What we measured

Same laptop, same Docker, all three with no traffic flowing. Nexus CE 3.94.0 and Artifactory Pro 7.146.29 were measured on 24 July 2026, 3–9 minutes after boot. The Artifactory image was unlicensed.

	Yellow Jack (full stack)	Nexus CE 3.94	Artifactory Pro 7.146
Processes	6 + Postgres’s 7	1, no database	16 + a mandatory Postgres
Idle RAM	60.8 MiB	1.26 GiB	~3.6–3.7 GiB
Idle CPU	1.24% (1.23 of it Postgres)	~0.5%	~7–15%, never goes quiet
Image	≈797 MB (152 MB ours)	1.2 GB	6.28 GB
External database	Postgres	none	Postgres, mandatory

Three ratios, three different claims

From one table you can honestly derive all of these:

• 21× less idle memory — our whole stack against Nexus.
• ≈61× less idle memory — our whole stack against Artifactory.
• ~260× — our firewall binary alone (4.9 MiB idle) against Nexus.

All three are arithmetic on the same measurement. They are not interchangeable, and the difference between them is the whole game.

The 260× compares one process to an entire repository manager. It’s the number a marketing page would print, and it’s the one that would be least useful to you, because nobody deploys the firewall binary and nothing else — our own stack includes a control plane, a console and a database. If we quoted you 260× and you later measured 21×, you’d be right to conclude we’d sold you something.

So the number we’ll stand behind is 21×, whole stack against whole product, and we’ll show you the table it came from.

Where Nexus wins, plainly

Nexus is one container with no database. We are six processes plus a Postgres. If you value operational simplicity above everything, that is a real advantage and it is theirs.

It also beats us on idle CPU: 0.5% for the entire product, against our 1.24% — and 1.23 of our 1.24 is Postgres. Nexus’s half-percent is doing the whole job; ours is mostly a database sitting idle.

The comparison isn’t fair, and that’s the argument

Nexus and Artifactory store and serve artifacts. We don’t. Yellow Jack is a gate, not a repository — it holds no artifacts, and the only durable state in the stack is the approval database that records what was allowed, blocked, and by whom.

So of course a repository manager is bigger. Comparing them on footprint is apples to oranges.

That’s exactly the point. If what you want is a decision at the pull boundary, you shouldn’t have to run a repository to get one. Today, the way most teams get policy enforcement on package pulls is by adopting a repository manager that happens to include it — and inheriting 16 processes, a mandatory database and a 6 GB image to get there. You can keep the registry you already run. The gate is a separate, much smaller thing.

Read this the way we’d want you to

• It’s one laptop, one run, no traffic. Idle is the easiest thing to measure and the least like production. It tells you what the software costs to have running, not what it costs under load.
• It’s those versions on that day. Both products ship frequently. Re-measure before quoting these against a newer release — we will too.
• The Artifactory image was unlicensed. A licensed instance may behave differently.
• Idle footprint is not a security property. A smaller gate is easier to run and harder to justify skipping. It doesn’t make the verdict better. We’d rather be judged on the verdict.

You can reproduce the Nexus and Artifactory columns today from what’s on this page: the versions, the date, and the conditions — one host, one Docker install, no traffic, readings taken a few minutes after boot. You’ll be able to check our column the same way once Yellow Jack is available, and we’d genuinely rather you did than took our word for it.

Questions or corrections: vineet@yellowjack.io.