sonatype/nexus-public: the open source core of Nexus Repository, and what the Community Edition adds
Sonatype Nexus Repository Open-source codebase mirror
At a glance
- What is it?
- The public repository holds the core of Sonatype Nexus Repository: Maven, raw and APT formats on an embedded H2 database. The README is explicit that npm, Docker, NuGet and PyPI live in the Community Edition binary instead, so the choice between the two is a format decision before it is a build decision.
- Who is it for?
- Adopt the public core if you need a Maven, raw or APT repository on a single host and you are willing to build from a tagged release with Java 21 and the Maven wrapper. Do not adopt it if you need npm, Docker, NuGet or PyPI proxying, or a PostgreSQL-backed deployment under Kubernetes: the README places those in the Community Edition binary, not in this source tree.
- Can I use it commercially?
- Yes, with conditions. EPL-1.0 is a weak copyleft licence: you can use it inside commercial and closed-source software, but if you distribute changes to its own files, you must publish those changes under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 9 days ago.
- What is it written in?
- Mainly Java, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 24, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What the public core actually covers, and who ends up using it
Nexus Repository is described in the README as a single source of truth for internal and third-party binaries, components and packages, with development tools pointed at one centralized binary repository manager. The public repository is not that whole product. It is the open source core, and the README states plainly that it contains functionality for maven, raw, and APT repository formats and uses an embedded H2 database that is appropriate for small workloads. That sentence does most of the scoping work for you. If your artifact traffic is Maven jars, arbitrary files served over HTTP, or Debian packages, the core is in scope. If it is container images or npm tarballs, it is not.
The intended audience is therefore narrower than the product name suggests: teams that want a self-hosted Maven proxy and release repository, teams publishing APT packages internally, and people who want to read or modify the repository server itself rather than just run it. The README points everyone else at the Community Edition binary, which it says adds npm, Docker, NuGet, PyPI and other format support, and which allows an external PostgreSQL database so the product can be deployed under Kubernetes. Those two capabilities, extra formats and an external database, are the dividing line between the source tree and the binary download.
How the core is put together: Maven build, Yarn frontend, embedded storage
The build is a Maven reactor at the repository root, with a pom.xml at the top level and the source under public/. Java 21 is the stated requirement, and Maven wrapper scripts are included in the source tree, so a separately installed Maven is not needed. The frontend is not a separate download: package.json declares Yarn workspaces over public/common/components/nexus-ui-plugin, public/common/components/nexus-rapture and public/common/components/nexus-coreui-plugin, with packageManager pinned to [email protected] and a resolutions block that pins transitive dependency versions. That means the build has two package managers in the loop, and the README orders them: initialize Yarn workspaces first, then build with Maven. Skipping the Yarn step fails the frontend modules rather than the whole reactor, which is the kind of failure that wastes an afternoon if you have not read the build section.
At runtime the shape is simpler. The build produces an assembly directory containing a runnable jar and a bin/ directory. The README says the application creates a sonatype-work directory under the assembly target path, and that this directory holds the default administrator credentials, the database and the file blobstore. Everything stateful lives in one directory next to the build output. The embedded H2 database is the reason the README calls the core appropriate for small workloads: there is no separate database process to run, and no external database to point at in this source tree. Backups, migrations and disk planning all reduce to that one directory, which is convenient on a single host and awkward the moment you want more than one node.
Building and running the core from a tagged release
Released versions are tagged and branched using a name of the form release-{version}, for example release-3.89.0-09, so the first step is fetching tags and checking out the branch you want rather than working from main.
git fetch --tags
git checkout -b release-3.89.0-09 origin/release-3.89.0-09 --After the checkout, the frontend workspaces have to be initialized before Maven runs. The README notes that corepack ships with Node.js 16.10 and later, so the enable step assumes a recent Node.js on the machine.
corepack enable
corepack yarn installThe build itself uses the included wrapper with the public profile. Expect a long first run: this is a large multi-module Java build plus a frontend bundle.
./mvnw clean install -PpublicTo run it, the README directs you to the assembly target directory and the jar inside bin/. The wildcard matches the versioned jar name produced by the build.
cd public/selfhosted/assemblies/nexus-repository-core/target/assembly
java -jar bin/nexus-repository-core-*.jarAfter startup, look inside public/selfhosted/assemblies/nexus-repository-core/target/sonatype-work. The README states that the default administrator credentials are written there, along with the database and the file blobstore. Those credentials are the first thing to change, and the directory is the thing to keep off any shared or world-readable path.
Where the core is the wrong tool: formats, database and scale
The clearest limitation is format coverage. The README lists maven, raw and APT for the core, and names npm, Docker, NuGet and PyPI among the additional formats in Community Edition. A team that standardizes on container registries or npm workspaces cannot substitute this source tree for the binary; the functionality is described as living in the other distribution. That is a product boundary, not a bug, but it decides the evaluation before any build command runs.
The second constraint is storage. The embedded H2 database is described as appropriate for small workloads, and the external PostgreSQL option is attributed to Community Edition. Anyone planning a Kubernetes deployment with several replicas, or expecting to point the core at a managed database, is outside what the README describes. Single-node with a local disk is the shape this supports.
The third is operational cost of self-building. There is no prebuilt artifact in this repository: you fetch a tag, initialize Yarn workspaces, run a Maven build with the public profile, and end up with an assembly directory. Upgrades mean repeating that against a new release-{version} tag and moving the sonatype-work directory, and the README does not document a rollback path for that directory. If nobody on the team wants to own a Java and Node build pipeline for the repository server itself, the binary download is the lower-effort route.
Compared with running a general purpose artifact store
The obvious alternative in this space is a general purpose artifact repository such as JFrog Artifactory, which is not covered by this repository's documentation and which the README does not mention. The difference that matters here is packaging and scope. Artifactory is distributed as a supported product with its own format matrix and database options; the core in this repository is source you compile yourself, with the format matrix the README states and an embedded database. Choosing between them is less about features than about who owns the build and upgrade of the server.
A second alternative is not a repository manager at all: publishing Maven artifacts to a hosted service, or serving APT packages from a plain static file server with a signed Release file. For a small number of internal artifacts and no proxying of external dependencies, a static host plus signing can cover APT distribution with far less machinery. What that gives up is the proxy and cache behaviour that makes a repository manager worth running: a central place your build tools point at, with third-party components fetched once rather than from the public internet on every build. If you are not proxying external dependencies, the core's main value is not in play.
Licence and the cost of staying current
The project is licensed under the Eclipse Public License v1.0, and the README links the full text at LICENSE.txt. EPL-1.0 is a file-level copyleft licence: modifications to covered files carry obligations when distributed, while separate modules can be licensed differently. The README also carries a trademark notice naming Sonatype and Nexus as Sonatype trademarks and Apache Maven and M2eclipse as third-party trademarks. Redistributing a modified build under the Nexus name is a question for your own legal review, not something this article can settle.
The maintenance picture is straightforward from the repository facts: the last push was on 2026-09-22, matching the release-3.96.3-01 tag, with release-3.96.2-01 on 2026-09-18 and release-3.96.1-01 on 2026-09-12. Releases are landing frequently. For a self-built deployment that cadence is also the upgrade cost: each release-{version} tag is a fresh checkout, a fresh Yarn install, a fresh Maven build with -Ppublic, and a decision about what to do with the existing sonatype-work directory. Pinning to a tag and moving deliberately is cheaper than tracking main, which the README does not present as a supported build target.
Editorial conclusion
Adopt the public core if you need a Maven, raw or APT repository on a single host and you are willing to build from a tagged release with Java 21 and the Maven wrapper. Do not adopt it if you need npm, Docker, NuGet or PyPI proxying, or a PostgreSQL-backed deployment under Kubernetes: the README places those in the Community Edition binary, not in this source tree. Before committing, verify that your required repository formats are actually present in the core, and check which tagged release you intend to build, since the repository tags releases as release-{version} branches rather than shipping a ready artifact.
Frequently asked questions
Is there a free version of Nexus Repository?
Yes. The README describes this repository as the open source codebase of Nexus Repository Core, and points to a Community Edition binary download that includes additional format support and external PostgreSQL. The core source is licensed under EPL-1.0.
What exactly is sonatype/nexus-public?
It is the open source codebase of Nexus Repository Core, containing functionality for maven, raw and APT repository formats with an embedded H2 database that the README calls appropriate for small workloads.
How do I build Nexus Repository Core from source?
Fetch tags and check out a release-{version} branch, run corepack enable and corepack yarn install to initialize the frontend workspaces, then build with ./mvnw clean install -Ppublic. Java 21 and the included Maven wrapper are the stated build requirements.
Does Nexus Repository Core support Docker, npm or PyPI repositories?
No. The README states that the core covers maven, raw and APT formats, and that npm, Docker, NuGet and PyPI support is included in the Community Edition binary instead.
Where does Nexus Repository Core store its database and credentials?
The README says the application creates a sonatype-work directory under the assembly target path, and that this directory contains the default administrator credentials, the database and the file blobstore.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/sonatype-nexus-public)