Registry formats · Maven
Deploy your releases and snapshots, proxy and cache Maven Central, and
resolve both from one URL in settings.xml.
Before an artifact from Central reaches your build, OrbitalReg can hold
brand-new releases back, verify their PGP signatures and match them
against advisories, inside the same self-hosted registry that holds
your images, npm and PyPI packages.
One file to change
settings.xml.
Every repository lives at
/maven/<project>/<repo>/.
Point a mirrorOf * entry at a
virtual repo that federates your internal artifacts with a cached
Maven Central remote, and every dependency resolves through
OrbitalReg.
Deploys go to local repositories: one for releases, one for snapshots, the same split Nexus and Artifactory users already have. Gradle and sbt use the same URLs.
<!-- ~/.m2/settings.xml: resolve everything through OrbitalReg -->
<mirrors>
<mirror>
<id>orbitalreg</id>
<mirrorOf>*</mirrorOf>
<url>https://registry.example.com/maven/acme/all-libs/</url>
</mirror>
</mirrors>
<servers>
<server>
<id>orbitalreg</id>
<username>${env.ORBITALREG_USER}</username>
<password>${env.ORBITALREG_TOKEN}</password>
</server>
</servers>// build.gradle.kts: same virtual repo
repositories {
maven {
url = uri("https://registry.example.com/maven/acme/all-libs/")
credentials {
username = System.getenv("ORBITALREG_USER")
password = System.getenv("ORBITALREG_TOKEN")
}
}
}Maven Central, checked
A remote repository caches Maven Central: the first request for an artifact fetches it, every later one is served locally, and misses are cached too. On the way in, you decide how much a new artifact has to prove.
All three checks are enforced on the server, for every developer laptop and CI runner at once, instead of depending on each machine's local configuration.
Versions younger than N hours are refused, measured from Central's publish time, not from when you cached them. New installs start with a 24-hour global hold. Snapshots and your own deploys are never held, and a security fast-track lets fixes through early.
With verify-on-pull on, the artifact is fetched together with its
.asc and checked against the OpenPGP keys you trust
before it is cached or served. No valid signature from a trusted
key, no artifact.
Every cached artifact is matched against advisories. Security blocks by coordinate or SHA-256 and the optional pull-gate apply on every download. With safe-version on, affected versions drop out of maven-metadata.xml so ranges resolve to a clean release.
# a Central release published 3 hours ago, global hold 24 h
GET /maven/acme/all-libs/com/example/lib/2.4.1/lib-2.4.1.jar
HTTP/1.1 403
X-Orbital-PullGate-Decision: block
Retry-After: 75600
reason: upstream release 3h old, hold 24h for maven (released at 2026-11-02T06:14:09Z)What you get
mvn deploy, Gradle and sbt publish into the standard repository layout. Timestamped snapshot builds are kept under their full coordinate, and maven-metadata.xml is rebuilt on every deploy as byte-reproducible XML, so -SNAPSHOT always resolves to the newest build. .sha1 and .md5 companions are served as clients expect.
A virtual repo federates local and remote members behind one URL. If a local member holds versions of a coordinate, only those are served and Maven Central is not mixed in, so a public artifact with your internal groupId and a higher version number never wins.
Each upload gets an SBOM built from its POM, matched against OSV advisories. A signature scanner also flags known-vulnerable libraries embedded inside JARs, such as a vulnerable log4j-core bundled inside a fat jar. Trivy and Grype add deep scans for the projects you enable them on.
Turn on safe-version for a virtual repo and versions an advisory definitely affects drop out of the coordinate's maven-metadata.xml when a clean replacement exists. Version ranges, Gradle dynamic versions and update bots resolve against the filtered list. An exact version in a pom.xml is never swapped for different bytes.
Deploy snapshots and release candidates into staging repos and promote what passes into releases. Promotion can require approval, and the destination's Rego policies are evaluated for every artifact before it is copied. Bytes are shared, not duplicated.
OrbitalReg accepts build-info in the format JFrog defined and links it to the artifacts by SHA-256, so every JAR shows the commit, branch, CI run and signing identity that produced it, plus a CycloneDX SBOM per build.
Optional and off by default: a policy engine evaluated before every download can block on maximum CVE severity, licence allow- or deny-lists, a missing SBOM or signature, or your own Rego rules. CI runners get a 403 with X-Orbital-PullGate-* headers that explain the reason.
Retention rules can keep the newest N builds per coordinate, filtered to snapshots, and prune the rest on a schedule. Every sweep is audit-logged, and pruned artifacts sit in Trash for 30 days before the bytes are deleted.
Coming from Nexus or Artifactory
Nexus and Artifactory both began as Maven repository managers, and
for many teams the Maven repos are still the core of the install.
Moving them is mostly a URL change, because the layout is the same.
The orbital migrate
CLI imports the repositories, and an nginx rewrite on the old host
lets clients move in batches.
Why the checks matter for Java specifically is documented in the Log4Shell and dependency confusion case studies. For the comparison, see the Nexus alternative and Artifactory alternative pages, and the migration guide for the cutover.
Questions
Add a <mirror> with <mirrorOf>*</mirrorOf> to settings.xml that points at a virtual repository (https://<host>/maven/<project>/<repo>/), and a <server> entry with the same id holding your username and token. For mvn deploy, set distributionManagement to a local release and a local snapshot repository. Nothing else in the pom.xml changes.
Yes. They read and publish the same Maven repository layout, so a maven { url … } block in Gradle or a resolver in sbt pointing at the same URL is all it takes.
Release-hold refuses Maven Central versions younger than a configured number of hours, measured from the upstream publish time, so a freshly published malicious release can't reach your builds in its first hours. New installs start with a global 24-hour hold. Snapshots and your own deploys are never held. With the security fast-track on, a version that an advisory lists as the fix for an older release is let through early, and admins can approve individual releases by hand.
Yes. With verify-on-pull enabled on a remote Maven repository, OrbitalReg fetches the artifact together with its .asc signature and checks it against the OpenPGP keys you trust before the artifact is cached or served. An artifact without a valid signature from a trusted key is refused, never served unverified.
The orbital migrate CLI imports Maven repositories from Nexus and Artifactory, along with the other formats (a commercial-licence feature, available during the 30-day trial). For the cutover, an nginx rewrite from Nexus's /repository/<repo>/ to /maven/<project>/<repo>/ on the old host lets you move clients in batches without touching every settings.xml at once.
For hosting internal artifacts and proxying Maven Central, yes, and the Maven layout is the same, so clients only need a new URL. The difference is what comes with it in the free version: advisory matching on every JAR, release-hold, PGP verify-on-pull, the dependency-confusion rule and the pull-gate, without component or request caps.
Documentation: Maven format reference · pull-gate and release-hold · safe-version delivery · build-info provenance · format support matrix
Free forever · no contract
One Helm chart, one Go binary, Postgres and S3-compatible storage. Advisory matching, release-hold, verify-on-pull and the pull-gate are part of the free version.