Why We Built Trunx: One Registry to Rule Them All
Nexus costs six figures. JFrog costs more. Both require a dedicated platform engineer to keep alive. We asked: what if the registry was just boring infrastructure?
The $100k problem every team ignores
Ask any engineering team how much they spend on their artifact registry. Most don't know. The ones who do know usually wince.
JFrog Artifactory Enterprise starts around $30k/year. Nexus Lifecycle adds another $50k. Add the cloud hosting, the ops time, the dedicated engineer who's the only person who understands why the proxy cache is corrupted again — and you're looking at six figures of annual spend on infrastructure whose job is to store files.
That's before the security incidents. Log4Shell happened in December 2021. Most companies with Nexus or JFrog still had no idea which internal packages contained the vulnerable version a week later, because their registry didn't track that.
The three things a registry should do
We spent three months interviewing engineering teams before writing a line of Trunx code. What we heard was consistent:
Store packages reliably. Every format, every ecosystem. npm, Maven, PyPI, Helm, Docker, Go, Rust, R — managed teams shouldn't need a separate tool per language.
Know what's inside every artifact. CVEs, licenses, secrets, dependencies. Not as an afterthought report — as a gate before the artifact reaches production.
Get out of the way. No six-week procurement cycles. No XML configuration. No dedicated ops engineer. A developer should be able to create a repository, push a package, and be done in under two minutes.
What "knowing what's inside" actually means
When an artifact lands in Trunx, before it's available for pull, it goes through an automatic pipeline:
PUSH → CVE scan (Grype + Trivy) → SBOM generation → Sigstore attestation → available
The CVE scan compares every dependency in the artifact against the NVD, OSV, and GitHub Advisory databases. The result is attached to the artifact — not stored separately, not emailed to someone — attached, permanently, to that exact version.
The SBOM (Software Bill of Materials) is generated in SPDX or CycloneDX format. Every package, every transitive dependency, every license. When your auditor asks "what's in your production artifacts?" in three years, you have the answer — for every version, of every package, going back to day one.
The Sigstore attestation means every artifact has a cryptographic proof of who pushed it, when, and from which pipeline. You can verify any artifact's provenance with a single CLI command:
trunx verify @my-org/payment-service@2.4.1
# ✓ Signed by ci@company.com
# ✓ Built from commit a3f8b12 on 2026-03-10T14:32:01Z
# ✓ No HIGH or CRITICAL CVEs
# ✓ SBOM attached (47 packages, 0 GPL-contaminated)
One registry, every format, your storage
Trunx is a single service. One deployment, one URL, one set of credentials. Your npm packages live at registry.company.com/npm/frontend/. Your Docker images live at registry.company.com/docker/services/. Your Helm charts live at registry.company.com/helm/platform/. All managed from the same dashboard, all backed by the same storage bucket.
Your data never leaves your cloud. Trunx connects to the S3 bucket, Azure container, or GCS bucket you already have. The registry layer is our problem. Your artifacts are yours.
Why now
The supply chain attack surface has never been larger. The node_modules problem is real — the average npm package has 77 transitive dependencies. The average Docker image has 400+ packages. Nobody manually audits these.
Automation is the only answer. But automation requires that every artifact, at every stage, is scanned, attested, and governed by policy before it reaches production. That's what Trunx does — and that's why we built it.