Hitting the Nexus Community Edition limits: what it means and the short answer
If your Nexus Repository Community Edition instance has reached the 40,000 component or 100,000 requests per day caps, you have three realistic paths: buy Nexus Repository Pro, stay on the EPL-1.0 open-source core with its narrower format set, or move hosted and proxied content to Pulp for packages and Harbor for container images. Pro removes the caps but keeps you on a commercial subscription. The open-source core keeps the license cost at zero but covers fewer formats. Pulp and Harbor give you full control over the platform and its licensing, at the price of migration work and running two services. Which one fits depends on which formats you actually host and how fast your component count and request volume are growing.
Treat Community Edition and the open-source core as two different products. Sonatype describes Community Edition as the successor to the legacy Nexus Repository OSS, and it requires accepting a EULA and enforces the usage caps described above. The EPL-1.0 licensed code on GitHub is a separate Nexus Repository Core codebase that supports Maven, raw and APT formats and uses an embedded H2 database. Moving to the open-source core does not simply mean keeping your current instance running without limits. Npm, Python, Docker and other repositories you may run today are not in that codebase, so you must check your repository inventory format by format before choosing this path.
Before deciding, run a short inventory: count components and requests per day from your instance's own reporting, list every repository by format and type (hosted, proxy or group), and confirm which Nexus features your builds depend on, such as LDAP or SAML integration and the Nexus Firewall. Confirm the current caps and terms directly with Sonatype's Community Edition onboarding page, since they can change. Then ask Sonatype for a written quote for Pro based on your actual component and request counts. That quote is the number to compare against the internal effort of a Pulp and Harbor migration.
What the limits force you to decide
The Community Edition caps, the format list, the licence terms and the exit path all bear on the same question: whether your current Nexus setup can keep running unchanged. Work through the four cards in order, because each answer narrows the options for the next.
Usage headroom against the caps
Community Edition stops accepting new components once you pass 40,000 components, and it caps usage at 100,000 requests per day. Count both figures from your own Nexus metrics over a full month, not from a single busy day. Include CI runners, build caches and container pulls, because automated jobs often generate most of the requests. Ask your team which growth you expect in the next year, since the cap applies to new content, not to existing content.
Format coverage for your ecosystems
The EPL open-source core covers Maven, raw and APT formats only, so npm, PyPI, container and other formats you use may not be available at all. List every ecosystem your builds pull from and publish to, including those used by a single team. Then check each one against the Pulp content plugins and their maturity, because a format that is available may still be at the 0.x stage. Treat any format not on the list as a gap that needs a decision.
EULA and licensing position
Community Edition requires you to accept a EULA, which is a different contract from the EPL-1.0 terms that cover only the Nexus Repository Core codebase on GitHub. Have legal review the EULA against your internal use, redistribution and hosting terms before you rely on it in production. If you fork the EPL core, confirm that its embedded H2 database and its feature set meet your needs. Pulp is GPLv2+, and Harbor is Apache-2.0, so compare the obligations of each licence with your policy.
Exit path without breaking client URLs
Build tools record repository URLs in configuration files, lockfiles and pipeline variables, so a move can break builds even when the artifacts are intact. Inventory every client reference and decide whether the new host will serve the same paths, or whether you will publish a redirect or a proxy in front. Plan a parallel run where both repositories serve traffic until clients have switched. Confirm with your platform team who owns each URL, because a missed reference often surfaces only when a pipeline fails.
Which option fits: Pro, the EPL core, Pulp or Harbor
This table compares four paths away from the Community Edition caps across how each handles the 40,000 component and 100,000 requests per day limits, format coverage, licensing and the main trade-off. Read the first two rows for the caps and format fit, then check the licensing and trade-off columns before deciding. Harbor covers OCI images and Helm charts only, so Maven and npm still need Pulp or another home.
| Option | How it handles the caps | Format coverage | Licensing | Main trade-off |
|---|---|---|---|---|
| Nexus Repository Pro (self-managed) | Lifts Community Edition usage caps, but billing follows components and requests under Sonatype's model | Broad Nexus format set, including Maven, npm, Python, Docker and more | Commercial subscription; confirm current terms on Sonatype's pricing page | Keeps the Nexus workflow and UI, but recurring subscription cost grows with usage |
| Nexus Repository Core (EPL-1.0 open source) | No Community Edition caps in the open-source core, but Sonatype's Community Edition onboarding does not apply to it | Maven, raw and APT only, with an embedded H2 database | EPL-1.0 for the Core codebase on GitHub | Narrow formats and an embedded H2 database leave npm, Python and container content unserved |
| Pulp (multi-format packages) | Self-hosted with no usage caps; capacity depends on your own PostgreSQL, storage and workers | RPM, Python and Debian are past 1.0; Maven, npm, Gem and Ansible are still 0.x; Rust is a tech preview | GPLv2+ | Plugin maturity varies by format, so check each 0.x plugin and its authentication gaps before committing |
| Harbor (OCI images and Helm charts) | Self-hosted with no usage caps; proxy cache serves Docker Hub pulls with HEAD checks that avoid its rate limiter | Container images and Helm charts as OCI artifacts only; no Maven or npm | Apache-2.0 | Strong for containers and Helm, but Maven and npm still need another repository |
| Most teams with Maven or npm plus containers | Split workload: Pulp for packages and Harbor for images, with each cap removed | Pulp covers packages, Harbor covers OCI and Helm | GPLv2+ and Apache-2.0 | Two systems to run, back up and monitor, with separate access control |
| Teams with containers and Helm only | Harbor replaces the container side of the caps; Pulp is not needed for this content | Container images and Helm charts | Apache-2.0 | Harbor v2.15.3 blocks webhooks to internal addresses by default, so confirm integrations first |
| What to confirm before choosing | Ask Sonatype how Pro billing counts components and requests against your current traffic | Inventory every format and repository type in your Nexus instance | Confirm licensing for any bundled plugin or tool you plan to use | Pilot each 0.x Pulp plugin with your real client tooling before cutover |
How to measure your current component and request counts before deciding
The upgrade-or-replace decision turns on two numbers: how many components your Nexus instance holds, and how many requests it serves per day. Community Edition blocks new components above 40,000 components or above 100,000 requests per day, so you need both figures for a representative period, not a single busy or quiet day. Start by listing every repository and repository type in use, then count components per repository and per format. Confirm the counting method (what Nexus treats as one component, and whether proxy cache entries count) with the Sonatype documentation linked from the Community Edition onboarding guide before you trust any total.
Pull the request numbers from your own Nexus request logs rather than estimating them from client counts. Group requests by repository format, by source address and by time of day, and record the peak day as well as the average, because the daily cap is a hard stop, not a monthly average. Keep a weekly window that includes a release or batch build day, since that is when limits are most likely to be hit. Write down which repositories the figures come from so the same breakdown can be reused for the Pro quote or a migration inventory.
Expect Maven and npm traffic from CI to dominate request volume in many estates. A single pipeline that resolves dependencies on every build, across many branches, can outnumber all developer activity combined, and it often hits proxy repositories repeatedly for the same artifacts. Separate CI source addresses or service accounts in your logs so you can see how much of the total they generate. If CI accounts for most of the load, the cheapest first step may be fixing cache reuse in the pipelines, and that change alters the numbers you will decide on, so measure again after it.
How a Pulp and Harbor split is deployed and operated
This sequence moves container and Helm content to Harbor and package formats to Pulp in parallel with Nexus, so each cutover can be checked and rolled back before Nexus is retired.
Inventory formats and repository types in Nexus
The platform team lists every Nexus repository by format, type (hosted, proxy or group), upstream source, and the clients that depend on it, including CI pipelines, cluster image pulls and developer workstations. Container and Helm repositories go to Harbor. Maven, npm, Python, RPM and Debian repositories go to Pulp. Any format without a clear home is flagged for a decision. The check that closes this step is a signed-off inventory where every repository has one target and one owner. Ask the vendor to confirm which Community Edition limits your current component and request counts sit against, since these determine whether the Pro upgrade or a replacement is the nearer option.
Stand up Harbor for container and Helm content
The container platform team installs Harbor in your own infrastructure, choosing the installer or the Helm-based high availability deployment described in Harbor's documentation, and enables Trivy scanning at install time if vulnerability analysis is required. Proxy cache projects replace Nexus Docker proxy repositories for upstream registries, and replication rules bring hosted images across. Helm charts are pushed and pulled as OCI artifacts with oci:// references, because Harbor no longer bundles ChartMuseum. The step is complete when test pulls through each proxy cache project succeed and a sample chart installs from Harbor.
Deploy Pulp with its three services and PostgreSQL
The platform team deploys pulpcore-api, pulpcore-content and pulpcore-worker processes, with PostgreSQL as the database that holds task state, and provides shared storage for published content. Plan these components as one system, since PostgreSQL is the single source of truth for tasks and must be backed up and monitored alongside Pulp. The official images can run as one multi-process container for small tests or as separate single-process images under Docker Compose or Kubernetes. The step is complete when the API responds at the REST API path and a test repository syncs successfully.
Test 0.x plugins before any production traffic
Pulp's Maven and npm plugins, pulp_maven (0.35.0) and pulp_npm (0.10.2), are still 0.x releases, so the team should run them against real build pipelines in a staging environment before cutover. Test pull-through caching for Maven Central and registry.npmjs.org, and test publishing with the Maven Deploy Plugin and npm publish, noting that pulp_maven's deploy feature does not use authentication and does not separate SNAPSHOT and release repositories. Record any client behavior that differs from Nexus. The step is complete when every build that depends on these formats passes in staging and any gaps have a documented workaround or an accepted risk owner.
Re-point clients and run both systems in parallel
Developers and CI jobs are moved to the new URLs in groups, starting with non-production pipelines. Nexus stays online read-only as a fallback during the overlap, and the team watches pull and publish errors, Harbor cache hit behavior and Pulp sync tasks. Docker Hub or upstream rate limits are checked against Harbor's proxy cache, which serves cached copies if the upstream becomes unreachable. The step is complete when each client group has run its normal workload on the new endpoints for an agreed period with no open incidents.
Back up and upgrade Harbor with the release notes
Before any Harbor upgrade, the team takes a full backup of the database and registry storage, following Harbor's guidance. The v2.15.2 release moved the bundled internal database from PostgreSQL 15 to PostgreSQL 18 on container startup and replaced Redis with Valkey, and its notes advise a reindexdb run if index problems appear. The v2.15.3 release blocks webhooks to internal network addresses by default and makes signing unsigned images fail in projects that enforce content trust, so webhook and signing workflows are tested first. Confirm the target version against the GitHub releases before scheduling. The step is complete when a restore from the backup has been tested and the upgrade runs cleanly in staging.
Retire Nexus after evidence of a clean cutover
Once all clients have run on Harbor and Pulp without incident, the team exports the final Nexus configuration, archives the blob store and the database, and sets a decommissioning date recorded in the change log. Access logs for Nexus are kept for the retention period your audit requirements set. The team confirms with the vendor how the Community Edition EULA and usage data apply to any remaining installation before shutdown. The step is complete when the archive has been verified, the Nexus service is stopped, and the owner signs off on the cutover record.
Questions buyers ask before choosing a Nexus replacement
What does Nexus Repository Pro cost, and what drives the price up?
Pro is a commercial subscription, and the price depends on what you deploy and how you consume it, not on a fixed list. Sonatype's self-managed editions are priced by components and requests, so growth in component count and daily request volume is the main driver. Cloud subscriptions bill differently: Sonatype's pricing page counts monthly egress plus storage against 25 GB included on Nexus Repository Cloud Pro, so large artifacts and heavy CI pulls raise the bill. Ask Sonatype for a written quote that states the edition, the component and request counts you expect, the number of instances (including staging and disaster recovery), and whether support is included. Confirm these terms directly with the vendor, since they change.
Does the open-source Nexus core cover the formats we use?
Probably not for every format, so inventory your repositories first. The EPL-1.0 Nexus Repository Core on GitHub covers Maven, raw and APT formats and uses an embedded H2 database. Npm, Python, container images, Helm charts and other formats that Community Edition or Pro provides sit outside that open-source core. If Maven and APT are your only formats, the core may be enough, but you would then run an embedded database and carry the operational burden yourself. Check the repository list in your current instance and compare it with the format list in the open-source core before deciding.
How long does a split migration to Pulp and Harbor take?
The duration depends on the number of repositories, the volume of hosted artifacts, and how many client configurations must change. Hosted artifacts must be re-uploaded or re-published, proxy content must sync again from upstream, and every Maven, npm, pip, and container client needs a new URL. Plugins that are still 0.x, such as pulp_maven, pulp_npm and pulp_ansible, need a pilot run before you commit to a date. Build the timeline from a written inventory of formats, repository types, artifact counts and client teams, then agree the scope and deliverables in writing before work starts.
Can our internal team run this migration without outside help?
A team with Linux, Kubernetes or container, PostgreSQL and object storage skills can often do the work in-house, but the migration touches many clients at once, which raises the coordination load. Pulp and Harbor both publish installation and architecture documentation, and Harbor's installer runs with a bundled database that changes across releases. Decide early which skills you lack, such as Pulp's Django and REST API model or Harbor's replication and proxy cache setup, and whether you need a fixed-scope engagement for those parts. DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted platforms in your own infrastructure, and most engagements are fixed-scope with agreed deliverables.
What infrastructure does a self-hosted Pulp and Harbor setup need?
Plan for PostgreSQL, object storage and, for high availability, several copies of each service. Pulp runs pulpcore-api, pulpcore-content and pulpcore-worker processes, with PostgreSQL as the single source of truth for tasks, and each component can scale horizontally. Harbor needs its own database and a cache backend, and its v2.15.2 release moved the bundled database to PostgreSQL 18 and replaced Redis with Valkey, so take a backup before upgrading. Storage for images and artifacts grows with use. Ask your team to size PostgreSQL, object storage capacity and backup retention against your artifact inventory, and confirm the HA design in each project's documentation.
Which client configurations change when we move off Nexus?
Every consumer that points at a Nexus URL changes: Maven settings and POM repositories, npm and yarn registry settings, pip index URLs, and container image references in Kubernetes manifests and CI pipelines. Harbor serves Helm charts as OCI artifacts from v2.8.0, so chart references move to oci:// addresses. Credentials and role mappings also change, so plan how LDAP or SSO groups map to new projects and repositories. Keep old Nexus endpoints running until clients are switched, and test each team's pipeline before cutover.
Does moving off Nexus change our security and audit posture?
It changes where controls live, so map each one before cutover. Harbor provides role-based access control, LDAP, AD and OIDC single sign-on, vulnerability scanning with Trivy, audit logs and garbage collection. Pulp provides authentication through its own configuration, but its pulp_maven deploy feature does not use authentication, and pulp_rust does not yet support authentication or authorization, so those formats need compensating controls. Confirm that each control you rely on today exists in the target platform, and list which evidence auditors will request. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors issue any audit reports or certifications.
Evidence to keep when you change repository managers
A change of repository manager touches licensing, access, data and recovery at once, and each one leaves evidence an auditor will ask for. The cards below list what to collect before cutover and during the parallel run, so the decision to buy Pro, stay on the open-source core or move to Pulp and Harbor can be defended later.
Licence and EULA position
Record which licence governs each option you are considering: the Community Edition EULA that you accept to run it, the Pro or Enterprise subscription terms, the EPL-1.0 Nexus Repository Core code on GitHub, GPLv2+ for Pulp and Apache-2.0 for Harbor. Keep the dated text you reviewed, and confirm with Sonatype which formats and features the Community Edition and open-source core actually include, since the open-source core covers fewer formats than the commercial product. Ask your counsel to confirm how each licence applies to internal use and any hosted service you plan to offer.
Repository and format inventory
Export a list of every hosted, proxy and group repository, with its format, upstream URL, owner and the number of components and daily requests. This inventory decides which content goes to Harbor, which goes to Pulp, and which stays on Nexus until a plugin is proven. Mark any format whose Pulp plugin is still a 0.x release, because an auditor will ask why that dependency was accepted.
Access control configuration
Export role definitions, privileges, LDAP or OIDC mappings and the users or groups bound to each repository, then map each one to its Harbor project role or Pulp access setting. Note where a permission model does not translate one to one and record the compensating control. Confirm with the vendor how each platform handles group sync and deprovisioned accounts before cutover, since stale access is a common audit finding.
Audit log and retention settings
Capture where audit events are written, how long they are kept, who can read or delete them, and whether they are forwarded to your SIEM. Harbor documents audit logs as a built-in feature, so keep a sample export from both the old and new systems covering the same period. Confirm the retention period you need with your compliance owner, not with the platform default.
Harbor vulnerability scanning settings
Document whether Trivy is enabled through the install option, which scanner version is bundled, the scan-on-push and scheduled scan policies per project, and the severity threshold that blocks pulls. Record the scanner database update schedule, since a scanner with stale data produces false assurance. Confirm with your security team whether a second scanner or an external Trivy instance is required by your policy.
Backup and restore test results
Keep dated records of at least one full restore into a separate environment, covering the PostgreSQL database, blob storage and configuration, and check that repository metadata and image digests match the source. Harbor's release notes recommend a backup before upgrading, and an upgrade across a major database version makes a verified restore a precondition, not an option. Ask your auditor which recovery time and recovery point objectives they expect you to have tested, and record the figures you actually measured.
When staying on the Community Edition or buying Pro makes sense
Staying on Community Edition is the simpler path when your estate fits inside its limits. That means a small number of formats the open-source core supports, a component count well under 40,000, and daily requests comfortably under 100,000. Check these numbers in the Nexus admin, not from memory, and record the trend over the last few quarters. A flat estate with one ecosystem, such as Maven artifacts only, is the clearest case. Also read the Sonatype Community Edition onboarding guide and have legal confirm the EULA terms that must be accepted to run it.
Buying Pro makes sense when the cost of running the platform yourself exceeds the subscription. That is most likely when the team has no appetite for operating PostgreSQL, object storage and upgrades, or when a regulator or internal audit expects a vendor-supported product with a named support path. Pro also covers the formats and features that the open-source core does not ship, so compare the Pro feature list against the formats and integrations you actually use. Sonatype's self-managed editions are priced by components and requests, so ask for a Sonatype pricing quote built on your measured counts and growth, and confirm in writing which features, high availability options and support levels are included.
Treat the Community Edition cap as a planning date, not an emergency. If your counts are rising toward the limits, decide before the block arrives: buy Pro, or start a migration with enough runway to test clients. The trade-off is clear. Pro keeps one vendor and one tool with supported upgrades, while the open-source replacements keep data and operations inside your infrastructure at the cost of your own engineering and operations time. Record the decision, the measured numbers and the review date so the choice can be revisited when the estate changes.
How DeployOpen runs a Nexus exit under your constraints
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Nexus Repository Community Edition limits, we start by measuring your real component and request volumes against the Community Edition caps, then build the replacement path you choose.
How we scope
- Inventory every Nexus repository by format, type (hosted, proxy or group) and consumer before any decision is made
- Record current component count, daily request volume and the formats teams depend on, so the Pro versus replace comparison uses your numbers
- Agree deliverables, timelines and acceptance criteria in writing before work starts, since engagements are fixed-scope
- Confirm with Sonatype the current Pro, Pro+ and Enterprise terms and what each quote includes for your environment
How we build
- Stand up a self-hosted Pulp deployment for Maven, npm, Python and RPM content, checking each plugin's maturity against your formats
- Deploy Harbor for container images and Helm charts as OCI artifacts, with projects, role mapping and proxy cache configured
- Test client configuration for Maven, npm, pip and container runtimes against the new URLs in a non-production environment first
- Document high availability, PostgreSQL and object storage choices and back up the stack before cutover
How we hand over
- Deliver runbooks for installation, upgrades, backup and restore, and client URL changes for each development team
- Provide a repository map showing where each former Nexus repository now lives and which clients were changed
- Prepare evidence for access control, audit logging and vulnerability scanning so your internal or external assessors can review it
- Walk operations staff through monitoring, garbage collection and upgrade procedures before the Nexus instance is retired
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped in writing
- Review Pulp, Harbor and Trivy release notes for breaking changes and schedule upgrades with your change process
- Plan for the Harbor and Pulp upgrade notes that call for backups before major changes, and test them in staging first
- Prepare compliance readiness material for your controls, while independent auditors remain responsible for any formal assessment
