DEV Community: Wen Ping

AngusRepo: Enterprise Multi-Format Artifact Repository | Unified Management for Maven/Docker/npm and 10+ Formats

Wen Ping — Sat, 10 Oct 2026 09:45:17 +0000

Development teams often face this challenge: Java project JARs, frontend npm dependencies, container images, and Helm Charts are scattered across different services, each requiring separate repository addresses, access credentials, and caching strategies. Internal components rely on file sharing, public dependencies are downloaded repeatedly, and artifact permissions and security information are difficult to manage uniformly.

AngusRepo provides a unified enterprise-grade artifact repository platform, managing 10+ formats including Maven, Docker, npm, PyPI, NuGet, Helm, Go, APT, YUM, and Raw in a single system. It provides clear storage locations for artifacts, stable access points for dependencies, and makes publishing and governance easier to integrate into team workflows.

What is AngusRepo?

AngusRepo is an enterprise-grade multi-format artifact repository management system within the AngusKit suite, designed to uniformly host, proxy, distribute, and manage software artifacts. It supports 10 mainstream artifact formats and seamlessly integrates with developers' familiar build and package management tools through standard protocols.

10+ — Supported Formats
3 Types — Repository Types: Hosted/Proxy/Group
Unified — Platform Management & Security

For development teams, AngusRepo is more than just a place to upload files. It connects internal artifact publishing, public dependency retrieval, version distribution, access control, and security governance, helping developers, builders, deployers, and managers work around a unified artifact source.

AngusRepo vs Other Solutions

As part of the AngusKit ecosystem, AngusRepo deeply integrates with AngusGit (code repository), AngusGM (project management), AngusSecurity (security scanning), and other products to provide enterprises with a complete DevOps toolchain from source code to artifact delivery. Compared to independently deploying Nexus, Artifactory, or Harbor, AngusRepo's advantages include:

Unified Identity and Permission System: Shares users, organizations, and permission management with other AngusKit products
Native Integration: Works seamlessly with AngusGit CI/CD, AngusSecurity scanning, and other features without additional configuration
Simplified Operations: Unified deployment, monitoring, and upgrade processes reduce multi-system maintenance costs
Optional Cloud-Native Architecture: Supports containerized deployment, horizontal scaling, and high availability configuration

Functional Architecture Overview

The diagram below shows AngusRepo's complete capability system from a product functional perspective, covering the entire workflow from user roles, client access, artifact formats, repository management, security governance to CI/CD integration, as well as typical artifact flow scenarios.

Architecture Diagram Explanation

The architecture diagram is divided into four main functional areas, showcasing AngusRepo's complete capability system:

① Client & Artifact Formats (Left · Green Area)

Displays 10 supported artifact formats, each with dedicated cards and descriptions
Developers use familiar package managers (Maven, Docker CLI, npm, etc.) and build pipelines to access
All formats communicate with AngusRepo through standard protocols without learning new tools

② AngusRepo Core Repository (Center · Orange Area)

Repository Types: HOSTED (internal hosting), PROXY (proxy caching), GROUP (aggregated access)
Artifact Management: Repository creation, version browsing, access control, analytics & audit, REST API/Webhook
Security & Compliance: Vulnerability scanning, license analysis, SBOM export, scanning policy configuration

③ CI/CD & Ecosystem Collaboration (Right · Purple Area)

Seamless integration with mainstream CI/CD tools like Jenkins, GitHub Actions, GitLab CI
Deep collaboration with AngusKit ecosystem (AngusGit, AngusAI)
Connect third-party tools and custom workflows through REST API and Webhook

④ Typical Artifact Flow (Bottom · Yellow Area)

Public Dependency Retrieval: Upstream Repository → PROXY Cache → GROUP Aggregation → Development/Build Pull
Internal Artifact Delivery: CI Build → HOSTED Hosting → Security Scanning → Downstream Consumption

💡 Tip: The architecture diagram supports dark mode and automatically adapts to your system theme preferences.

Core Capabilities: What Can AngusRepo Do?

1. Unified Multi-Format Management

Manage 10 artifact formats in a single platform. Teams can plan repositories by format and purpose without introducing separate management processes for each package or image type. All artifacts use unified permission systems, audit logs, and storage management.

2. Host Internal Artifacts

Through HOSTED (hosted) repositories, teams can store their own built and published packages, images, and other artifacts, and provide access to developers, CI/CD pipelines, or downstream environments based on permissions. Internal artifacts thus have unified, traceable publishing locations without relying on temporary files or personal machine transfers.

Typical Use Cases:

Publish internal Java component libraries to Maven hosted repositories
Push enterprise application Docker images for test and production environments to pull
Host team-developed npm private packages for frontend projects

3. Proxy and Cache Public Dependencies

Through PROXY (proxy) repositories, AngusRepo can proxy upstream repositories for supported formats and cache retrieved dependencies. Development and build processes thus gain unified dependency access points and reduce repeated downloads' direct dependency on external networks.

Key Advantages:

Accelerate Builds: Local caching after first download, subsequent builds don't need to repeatedly fetch from public networks
Improve Stability: Reduce dependency on external repository availability
Save Bandwidth: Team-shared caching reduces duplicate traffic
Offline Support: Cached dependencies can be used in network-restricted environments

4. Aggregate Multi-Source Access

GROUP (aggregated) repositories can query multiple member repositories in configured order, allowing clients to retrieve artifacts from different sources through a single read-only entry point. It's especially suitable for organizing internal artifact repositories and public dependency proxies into a unified pull entry point.

Example: A Maven group repository can sequentially query internal releases, internal snapshots, and Maven Central proxy, with developers only needing to configure one repository address.

5. Security and Compliance Governance

AngusRepo provides complete artifact security governance capabilities:

Access Control: Fine-grained permission management based on users, organizations, and projects
Access Tokens: Support for read-only, read-write, specific repository-scoped tokens for easy CI/CD integration
Activity Audit: Records all artifact upload, download, delete operations to meet compliance requirements
Security Scanning: Integrates with AngusSecurity for artifact vulnerability scanning and license analysis
SBOM Generation: Automatically generates Software Bill of Materials
Lifecycle Management: Automatically deletes expired or unused artifacts through cleanup policies to save storage space

6. Integration with DevOps Workflows

Standard Protocol Support: Developers continue using familiar tools like Maven, Docker CLI, npm, pip without learning new commands
REST API: Complete API support for automated operations like artifact queries, version management, repository configuration
Webhook Notifications: Artifact publish, delete events can trigger external systems, such as notifying test environments for automatic deployment
CI/CD Integration: Seamlessly works with Jenkins, GitLab CI, GitHub Actions, AngusGit CI, and more

Supported Artifact Formats and Repository Types

AngusRepo's 10 supported formats cover common development language ecosystems, container delivery, system packages, and generic files. The table below lists supported repository types for each format:

Artifact Format	HOSTED	PROXY	GROUP	Typical Use
Maven	✓	✓	✓	Java/JVM project dependency management, internal component publishing
Docker / OCI	✓	✓	✗	Application image hosting, public image proxy and deployment delivery
npm	✓	✓	✓	Frontend dependency management, internal npm package publishing
PyPI	✓	✓	✓	Python project dependency retrieval and internal package distribution
NuGet	✓	✓	✓	.NET application dependency management and component publishing
Helm	✓	✓	✗	Kubernetes application Chart hosting and distribution
Go	✗	✓	✗	Retrieve and cache Go dependencies through module proxy
APT	✓	✗	✗	Debian/Ubuntu `.deb` package hosting and distribution
YUM	✓	✓	✗	RPM-based Linux environment package distribution
Raw	✓	✓	✗	Installers, binary files, archives, and other files

Notes:

✓ indicates the format supports this repository type
✗ indicates the format does not support this repository type
HOSTED: Store team's own artifacts
PROXY: Cache upstream public repository dependencies
GROUP: Provide unified multi-source query entry point (only some formats supported)

These 10 formats each retain their ecosystem's usage patterns. Developers can still use familiar command-line tools and build systems to access, with repository addresses, authentication methods, and format-specific configurations following respective format guidelines. See the complete format usage guide.

How Do the Three Repository Types Work Together?

AngusRepo organizes different artifact flow patterns using three repository types. Each has different responsibilities, and not all artifact formats support all three types simultaneously.

Repository Type	Main Responsibility	Typical Use
HOSTED	Store team's own artifacts and provide authorized access	Publish internal packages, components, and images
PROXY	Connect to upstream repositories and cache retrieved dependencies	Centrally access public dependencies, reduce duplicate downloads
GROUP	Query multiple member repositories in configured order, providing unified read-only entry	When format supports, organize internal artifacts and public dependencies into a single pull address

For example, in a typical Maven project, a team can place internal releases in maven-releases (HOSTED), configure Maven Central as maven-central (PROXY), and create maven-public (GROUP) for developers to resolve dependencies. Developers pull dependencies through the unified entry point, while CI/CD publishes new versions to the corresponding HOSTED repository.

This division makes "where to get dependencies" and "where to publish artifacts" clear, and facilitates separate team management of publishing permissions, dependency sources, and version strategies. See the Repository Management Manual for more repository planning approaches.

Typical Use Cases: What Problems Does AngusRepo Solve?

1. Unified Artifact Management for Multi-Language Teams

Scenario: An internet company uses Java (backend), React (frontend), Python (data analysis), and Go (microservices), each language with its own dependency management approach.

Problems:

Developers need to separately configure Maven, npm, PyPI, Go proxy repository addresses and credentials
Different repositories have independent permission management, difficult to unify accounts and tokens
Lack of unified audit and monitoring, unable to comprehensively understand artifact usage

Solution: Use AngusRepo to create repositories for corresponding formats, managing all artifacts uniformly. Team members use the same identity system to access different format repositories, and administrators manage permissions, audit logs, and storage quotas through one platform.

2. Accelerate Builds and Improve Stability

Scenario: An enterprise team is in a network-restricted environment, with slow and unstable access to Maven Central, npm Registry, and other public repositories.

Problems:

Builds repeatedly download dependencies from public networks, time-consuming and prone to failure
Multiple developers and CI/CD nodes repeatedly download the same dependencies, wasting bandwidth
External repositories occasionally unavailable causing build interruptions

Solution: Configure AngusRepo's PROXY repositories to proxy upstream public repositories. After the first download, dependencies are cached locally, subsequent builds pull directly from cache, build speed improves by 60%, and no longer affected by external networks.

3. Standardized Publishing of Internal Component Libraries

Scenario: A development team maintains multiple internal common component libraries for use by various business lines.

Problems:

Component publishing relies on manual JAR file copying to shared directories, chaotic version management
No formal version numbers and change records, downstream projects don't know which version to use
Lack of access control, anyone can modify or delete components

Solution: Use AngusRepo's HOSTED repositories to host internal components. Component libraries publish official versions through mvn deploy, downstream projects reference through standard dependency declarations. Combined with access tokens, only authorized CI/CD pipelines can publish new versions, all operations have audit records.

4. Centralized Container Image Management

Scenario: A team uses Kubernetes to deploy microservices, needing to manage numerous application images and base images.

Problems:

Application images pushed to Docker Hub public repositories pose security risks
Pulling base images from Docker Hub is slow and affected by access restrictions
Lack of image vulnerability scanning and version management

Solution: Use AngusRepo to create Docker HOSTED repositories to host application images, create Docker PROXY repositories to proxy Docker Hub. Combined with AngusSecurity, automatically scan pushed images for vulnerabilities, blocking images with critical vulnerabilities from deploying to production environments.

5. Artifact Governance Meeting Compliance Requirements

Scenario: A financial enterprise needs to meet regulatory requirements for comprehensive software supply chain audit and management.

Requirements:

Record source, publisher, and usage of all artifacts
Regularly scan dependencies for security vulnerabilities and license compliance
Generate SBOM (Software Bill of Materials) for compliance reporting

Solution: AngusRepo records all artifact upload, download, delete operations, and integrates with AngusSecurity for vulnerability scanning and license analysis. Automatically generates SBOM documents to meet compliance audit needs. Configure cleanup policies to automatically delete expired versions, reducing storage costs.

Team Type Applicability

Team Type	Key Benefits
Small to Medium Development Teams (10-50 people)	Quickly build private repositories, simplify dependency management, reduce operational burden
Multi-Language Stack Teams	Unified management of multiple formats, reduce learning and configuration costs
Microservice & Container Teams	Centrally manage container images and Helm Charts, accelerate deployment processes
Enterprise Development Teams (50+ people)	Fine-grained permission control, audit, security scanning, meet compliance requirements
Network-Restricted or Offline Environments	Cache public dependencies, ensure build stability and speed

Quick Start: Configuration Examples

Maven: Publishing and Pulling Java Artifacts

Below shows how to configure a Maven project to use AngusRepo: developers retrieve dependencies from a unified repository entry, CI/CD publishes build artifacts to hosted repositories.

1. Create Repositories in AngusRepo

Repository Name	Type	Purpose
`maven-releases`	`HOSTED`	Store internal release versions
`maven-central`	`PROXY`	Proxy Maven Central
`maven-public`	`GROUP`	Provide unified dependency pull entry for clients

Add maven-releases and maven-central to maven-public.

2. Configure Maven Credentials

Configure publishing credentials in ~/.m2/settings.xml. It's recommended to inject tokens via environment variables, don't commit actual tokens to code repositories:

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0">
  <servers>
    <server>
      <id>angusrepo-releases</id>
      <username>${env.ANGUS_REPO_USERNAME}</username>
      <password>${env.ANGUS_REPO_TOKEN}</password>
    </server>
  </servers>
</settings>

3. Configure Project Dependencies and Publishing Target

Configure in the project's pom.xml:

<repositories>
  <repository>
    <id>angusrepo-public</id>
    <url>https://repo.anguskit.com/maven/maven-public</url>
  </repository>
</repositories>

<distributionManagement>
  <repository>
    <id>angusrepo-releases</id>
    <url>https://repo.anguskit.com/maven/maven-releases</url>
  </repository>
</distributionManagement>

4. Publish Artifacts

mvn deploy

For more configuration methods, see the Maven Format Manual.

Docker: Hosting and Pulling Container Images

Configure Docker to use AngusRepo for hosting and pulling container images.

1. Create Repositories in AngusRepo

Repository Name	Type	Purpose
`docker-hosted`	`HOSTED`	Store internal application images
`docker-hub`	`PROXY`	Proxy Docker Hub

2. Login to AngusRepo Docker Repository

docker login repo.anguskit.com

Enter username and access token (generated in AngusRepo user settings).

3. Push Images to Hosted Repository

# Build image
docker build -t repo.anguskit.com/docker-hosted/myapp:1.0.0 .

# Push image
docker push repo.anguskit.com/docker-hosted/myapp:1.0.0

4. Pull Public Images from Proxy Repository

# Pull Docker Hub image (through AngusRepo proxy)
docker pull repo.anguskit.com/docker-hub/nginx:latest

5. Use in CI/CD

# GitLab CI example
stages:
  - build
  - push

build-image:
  stage: build
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
    - echo $ANGUS_REPO_TOKEN | docker login -u $ANGUS_REPO_USERNAME --password-stdin repo.anguskit.com
    - docker push repo.anguskit.com/docker-hosted/myapp:$CI_COMMIT_SHA

For more configuration methods, see the Docker Format Manual.

npm: Managing Frontend Dependencies

1. Configure npm to Use AngusRepo

# Set npm registry
npm config set registry https://repo.anguskit.com/npm/npm-public/

# Configure authentication token
npm config set //repo.anguskit.com/npm/:_authToken YOUR_ACCESS_TOKEN

2. Install Dependencies

npm install

3. Publish Internal Packages

npm publish --registry https://repo.anguskit.com/npm/npm-releases/

For more format configuration examples, see the complete format usage guide.

Frequently Asked Questions

Q: How to generate access tokens?

Login to AngusRepo → User Settings → Access Tokens → Generate New Token. You can specify token permission scope (read-only/read-write) and validity period.

Q: How do PROXY repositories handle authentication?

If the upstream repository requires authentication (such as private Docker Registry), configure upstream credentials when creating the PROXY repository. AngusRepo will automatically use these credentials when requesting upstream.

Q: How to clean up old artifact versions?

Configure cleanup policies in repository settings to automatically delete artifacts according to these rules:

Keep the most recent N versions
Delete artifacts unused for more than X days
Delete old versions of specific version patterns (such as SNAPSHOT)

Q: Does it support anonymous access?

Yes. You can enable anonymous reading in repository settings, allowing unauthenticated users to pull artifacts. However, publishing artifacts always requires authentication and authorization.

Integration with Development Workflows

AngusRepo can serve as the artifact entry point in build and delivery processes:

Development Phase: Developers resolve dependencies locally, retrieve public dependencies from PROXY repositories, and internal components from HOSTED repositories
Build Phase: CI/CD publishes artifacts to HOSTED repositories after build completion, triggering Webhook notifications to test environments
Testing Phase: Test environments pull corresponding artifact versions from controlled repository addresses for deployment
Release Phase: Production environments pull deployments from approved artifact versions, all operations have complete audit records

Combined with permission management, cleanup policies, audit, and security governance, teams can more easily unify artifact flow patterns and continuously maintain understandable, reusable delivery processes.

Implementation Recommendation: For teams already using automated pipelines, start with the most commonly used formats like Maven, npm, or Docker, verify basic processes, then gradually expand to other formats based on project and team needs.

Originally published at anguskit.com.

Replace Harbor, npm Registry, and Nexus with One Repository: AngusRepo vs Nexus vs Artifactory

Wen Ping — Sat, 10 Oct 2026 09:39:38 +0000

Why repository selection still matters in 2026

Ten years ago, an artifact repository was just "the place where jars live." Today it is the chokepoint of your software supply chain:

Every dependency enters the company through it (PROXY caching upstreams)
Every deliverable leaves through it (HOSTED publishing, image distribution)
The security team sets up checkpoints here (vulnerability scanning, admission blocking)
Finance reads the bill here (storage cost grows linearly with artifact volume)

The cost of choosing wrong is no longer "inconvenient" — it's a day slower on vulnerability response, double the storage bill, and a weekend of downtime to migrate away.

This article compares the three mainstream options — Sonatype Nexus Repository, JFrog Artifactory, and AngusRepo — across the six dimensions engineering teams actually care about.

The conclusion first: recommendations by team profile

Team profile	Recommendation	Core reason
Deeply invested in the JFrog ecosystem, ample budget	Artifactory	Broadest formats, mature enterprise features, complete ecosystem
Just need basic Maven/npm hosting, security handled by separate team	Nexus OSS	Free, abundant community material, simple deployment
Want "repository + supply chain security" in one, open source and self-controlled	AngusRepo	Scanning/SBOM/blocking built in natively (GPL-3.0), one platform replaces multiple systems

Now the details.

Core replacement logic: How one repository replaces multiple systems

Traditional enterprise artifact management landscape:

Current architecture	Operational burden	Pain points
Harbor for Docker images	Separate deployment, backup, permissions	Images and dependencies siloed, scattered security governance
Nexus/Verdaccio for Maven/npm	Another account system, another storage	Cross-format dependency tracking difficult
File server + manual management	No version control, no permission audit	Security compliance black hole

AngusRepo's replacement approach:

✅ Unified identity & permissions: One account system manages access control for all formats
✅ Unified storage & cleanup: Object storage deduplication, cross-format cleanup policies
✅ Unified scanning & governance: Images and dependencies scanned by the same Trivy engine, SBOM exported uniformly
✅ Unified operations: One monitoring stack, one backup, one upgrade window

Docker format special note:

AngusRepo's Docker repositories support HOSTED (hosting) and PROXY (proxy), but not GROUP (aggregation)
This doesn't affect the ability to "replace Harbor": Harbor doesn't offer GROUP either
The key difference: AngusRepo can manage images and Maven/npm on the same platform, while Harbor only handles images

💡 Typical scenario

Frontend team builds with npm, backend with Maven, test environment deploys with Docker → Configure one AngusRepo instead of Harbor + Nexus + Verdaccio three systems

Dimension one: format coverage

All three cover the mainstream formats; the differences lie in the long tail and the pricing:

Format	Nexus OSS	Artifactory	AngusRepo
Maven / Gradle	✅	✅	✅
Docker / OCI	✅	✅	✅
npm / yarn / pnpm	✅	✅	✅
PyPI	✅	✅	✅
NuGet	✅	✅	✅
Helm	✅	✅	✅
Go Module	✅	✅	✅
APT / YUM	✅	✅	✅
Raw / generic files	✅	✅	✅

Format support itself is no longer a moat. The real questions: for a given format, are all three repository types (hosted, remote proxy, aggregation group) supported? Is the group's resolution order controllable?

AngusRepo's GROUP repositories use explicit first-match priority: members resolve in order, and a lower order number wins. Developers configure a single GROUP entry point in their build tool, while the policy behind it — "internal releases first, then snapshots, finally the Central cache" — is centrally controlled by repository admins.

Dimension two: security — this is the watershed

The reality of 2026: an artifact repository without admission gating is an undefended one.

Capability	Nexus OSS	Artifactory	AngusRepo
Vulnerability scanning	Paid IQ Server	Paid Xray	Built in (Trivy engine)
SBOM generation	Paid	Paid	Built in
VEX false-positive management	—	Partial	Built in
Blocking downloads of critical artifacts	Paid	Paid	Built in (autoBlock)
Vulnerability intelligence sync	Paid	Paid	Built in

Both Nexus and Artifactory keep security behind a paywall in their free/base tiers. AngusRepo's stance: scanning, SBOM, VEX, and blocking are the repository's core duty, not an upsell.

Security capability in action

Scenario 1: Log4Shell critical vulnerability discovered (CVE-2021-44228)

Product	Free version capability	Response workflow
Nexus OSS	❌ Cannot auto-scan	Manual check of each JAR's pom.xml → Manual notification to developers
Artifactory OSS	❌ Cannot auto-scan	Same as above
AngusRepo Community	✅ Auto-scan and flag	Scan identifies → SBOM export → autoBlock stops new downloads → Webhook notifies team

Scenario 2: False positive handling (an internal package incorrectly flagged as critical)

Nexus/Artifactory: Need to upgrade to paid tier for VEX functionality
AngusRepo: Built-in VEX management, mark as false positive and no more alerts or blocking

Real cost comparison:

Product	Annual cost (with security scanning)	Notes
Nexus IQ Server	~$30,000/year and up (50 applications)	OSS has no scanning, must purchase IQ Server
JFrog Xray	~$18,000/year and up	Artifactory OSS has no scanning, must purchase Xray
AngusRepo Community	$0	GPL-3.0 free to use, scanning/SBOM/blocking built in
AngusRepo Team	$360/year ($30/month)	Adds HA/LDAP/SSO/SLA on top of Community, 200 repositories
AngusRepo Enterprise	$1,440/year ($120/month)	1000 repositories, higher specs and enterprise support

Cost advantage is clear: AngusRepo Team edition is only 1.2% of Nexus IQ Server's cost (saves 98.8%), and Enterprise edition is also 95%+ cheaper than Nexus/Xray, while the Community edition already includes core security capabilities.

Note: autoBlock is a double-edged sword. Our docs are explicit — finish deploying the scan engine and syncing intelligence, clear false positives via VEX, and only then enable blocking. Don't be the team that blocks everyone on day one.

Dimension three: storage cost

An artifact repository is the textbook "grows forever" system. Three questions determine your bill five years out:

Does it support object storage? All three support S3. AngusRepo additionally supports Azure Blob and GCS natively, and is compatible with MinIO/OSS via Path-Style access.
Is there deduplication? Identical content stored once. AngusRepo has a built-in Deduplication switch; Artifactory's checksum-based storage dedupes by design; Nexus OSS has none.
Is cleanup actually usable? Nexus's Cleanup Policies are scattered and weak on preview — a years-old community complaint. AngusRepo makes cleanup a first-class citizen: four condition types (age / count / size / name regex), a mandatory pre-execution preview including a sample list of what will be deleted, and a Dry Run mode for repeated rehearsal.

Real storage cost comparison

Example from an internet company's real data (1 year accumulated):

Project	Artifact count	Before dedup	After dedup (AngusRepo/Artifactory)	Nexus OSS (no dedup)
Maven dependencies	8,500 JARs	850 GB	320 GB (-62%)	850 GB
Docker images	1,200	2.4 TB	1.1 TB (-54%)	2.4 TB
npm packages	6,000	120 GB	65 GB (-46%)	120 GB
Total	-	3.37 TB	1.49 TB	3.37 TB

At $0.023/GB/month for object storage:

Nexus OSS: $933/year
AngusRepo/Artifactory: $412/year (56% savings)

💡 Cost note: This only calculates storage cost. For security scanning, Nexus requires additional IQ Server purchase (~$30k/year), while AngusRepo Community edition has built-in scanning at no extra cost; commercial editions also have significantly lower annual fees than Nexus IQ + Artifactory Xray combinations.

Dimension four: operational burden

Item	Nexus OSS	Artifactory	AngusRepo
Deployment shape	Java monolith	Multiple services	Java 21 monolith + full-stack Docker Compose
Resource footprint	Medium	High	Medium
Upgrade complexity	Medium	High (aligning multi-component versions)	Low
Built-in monitoring	Basic	Comprehensive	System status + metrics API, pluggable into external monitoring

AngusRepo ships a ready-to-run Compose stack (nginx + MySQL + app) — one command brings up everything, a good fit for mid-size engineering orgs without a dedicated platform team. The interface uses a modern React tech stack, with repository details pages featuring built-in access configuration and one-click copy, reducing the team's learning curve.

Dimension five: permission model

All three support repository-level ACLs. The difference is how smoothly they integrate with the enterprise directory:

AngusRepo's authorization subjects are three-tiered — user / group / department — with permissions inherited automatically along the org structure (indirect authorization), plus four repository roles: Admin / Delete / Write / Read.
CI uses access tokens uniformly: clients put the token in the Basic Auth password field, and tokens can be revoked individually — no more "one password to rule them all."

Dimension six: openness and ecosystem

Webhooks: AngusRepo offers 7 event types (upload / download / delete / scan complete / vulnerability found / repository created / deleted) for driving external scan queues, deployment gates, and IM notifications.
Public Portal: AngusRepo ships an anonymous read-only portal (/explore) where the community or your intranet can search public artifacts, browse them, and copy install commands — a shape neither Nexus nor Artifactory offers.
API: full REST API with OpenAPI specs for custom development.

Dimension seven: licensing and business model

Product	Community/Open Source edition	Commercial edition	Key differences
Nexus	OSS edition (Eclipse Public License 1.0)	Pro edition	Security scanning, LDAP, HA in Pro
Artifactory	No true open source edition	OSS/Pro/Enterprise	OSS is only free, source code not open
AngusRepo	Community edition (GPL-3.0)	Team/Enterprise editions	Scanning/SBOM/blocking in Community, commercial adds HA/LDAP/SLA

What does AngusRepo's GPL-3.0 mean?

✅ Free to use, modify, and distribute: No license purchase needed for production deployment
✅ Source code fully open: Can audit code, customize features, contribute to community
✅ Core capabilities not crippled: Scanning, SBOM, VEX, blocking all in Community edition, unlike Nexus keeping security behind paywall
⚠️ Modified versions must be open: If you modify and distribute AngusRepo, must share source under GPL-3.0

When do you need to upgrade to commercial editions?

Need high availability deployment (active-standby/multi-active architecture)
Need enterprise-grade LDAP/SSO integration
Need 7×24 technical support with SLA guarantees

Commercial edition pricing reference

Team edition: $360/year ($30/month) - 50 users, 200 repositories, basic HA, standard SLA
Enterprise edition: $1,440/year ($120/month) - 200 users, 1000 repositories, enterprise SLA
Enterprise Custom: Contact sales - large scale, multi-node, customized support

Cost advantage:

vs. Nexus IQ Server ($30k/year+), saves 98.8% (Team) / 95.2% (Enterprise)
vs. JFrog Xray ($18k/year+), saves 98% (Team) / 92% (Enterprise)
Community edition GPL-3.0 free to use, core security capabilities built in

💡 Recommended path: Start with Community edition to verify the replacement approach (setup, format access, scanning tests), then evaluate commercial features only after confirming it meets your needs → View complete pricing

Frequently asked questions

Q1: Can AngusRepo fully replace Harbor?

A: Core image hosting, proxying, and vulnerability scanning can all be replaced. Harbor features such as project-level permissions, image replication, and Robot Accounts have equivalents in AngusRepo through department-level permissions, access tokens, and the API. The important difference: AngusRepo can manage images and Maven/npm on the same platform, while Harbor only manages images.

Q2: Why don't Docker repositories support GROUP?

A: This is a limit of the Docker Registry V2 protocol. Harbor and Nexus Docker repositories do not support GROUP either. In practice a PROXY repository covers most needs, including proxying public registries such as Docker Hub.

Q3: Is the Community edition enough? When do you need a commercial edition?

A: Scanning, SBOM, blocking, and cleanup are all in the Community edition. Consider a commercial edition when you need high availability (HA), enterprise LDAP/SSO, or 7×24 support.

Q4: How do you choose between a cloud vendor's artifact service and self-hosting?

A: Cloud services bill by traffic; self-hosting bills by storage. When artifacts are large but accessed infrequently, self-hosting costs less. Privatization and cross-border delivery usually require self-hosting. See Choosing among Alibaba Cloud, Huawei SWR, and a self-hosted repository.

Summary

Format coverage is commoditized; security capability and storage cost are the real watershed in 2026.
If your security budget can't cover IQ Server / Xray subscriptions and you refuse to run undefended, AngusRepo ships scanning, SBOM, and blocking as built-in repository capabilities, so you don't buy a separate security subscription.
Whatever you choose, run a two-week PoC with real traffic: import your three largest projects, run one full scan, rehearse one cleanup. The numbers will speak for themselves.

About this comparison: This comparison is based on each product's public documentation as of this post's publication date, together with our own hands-on notes. It does not represent any vendor's official position. Capabilities and pricing change over time, so verify against official documentation and quotes before you decide; trademarks belong to their respective owners. This is an independent reading by the Angus team and is not procurement advice.

Originally published at anguskit.com.

Connect 10 formats to one artifact service: Maven, Docker, npm, PyPI, and Helm

Wen Ping — Sat, 10 Oct 2026 09:30:41 +0000

A team often runs Java, frontend, Python, .NET, and containers at the same time. Instead of keeping a separate private registry for each stack, manage the artifacts in one AngusRepo service.

This guide covers Maven, Docker, npm, PyPI, NuGet, Helm, Go, APT, YUM, and Raw. For each format you do three things: authenticate, publish one artifact, then pull it back to verify.

A common mix-up: “one artifact service” means one AngusRepo deployment, not one repository that accepts every format. Create a HOSTED repository for each format, such as maven-releases or docker-releases. Repository names and hostnames below are examples. Use the Setup tab on the repository detail page.

Three minutes of setup

If you use only one stack, read only that section. The first time, verify in the order publish → pull. A successful upload does not prove the client can download.

1. Account, token, and repository

Sign in

Open the AngusRepo console. On a self-hosted instance, use the console URL from your administrator.

Create a token

Go to User Settings → My Tokens and create a token, for example local-macbook. The token is shown only once. Save it immediately. If you lose it, revoke it and create another.

Create a HOSTED repository

Under Repositories, create a HOSTED repository for the format you need, and confirm your account can upload to it.

Copy the setup values

Open the repository Setup tab. Use the repository name, URL, distribution, and component shown there.

Put the login name and token in environment variables for the commands below. export lasts only for the current terminal, so keep running commands in that same window.

export REPO_USER="your-username"
export REPO_TOKEN="your_access_token"

REPO_USER is the login name, not the token name. For Maven, Docker, npm, NuGet, and the other protocols, the token is the password. Every --password, --api-key, and _authToken in this guide takes REPO_TOKEN, not your login password.

Security: A token written into a URL lands in shell history or local config. Use these examples only on a machine you control. On a shared machine or in CI, use a secret store, and remove the temporary config after you verify.

2. Address cheat sheet

Format	Pull address or identifier	Publish
Maven	`https://host/maven/<repo>/`	Same URL, `mvn deploy`
Docker	`host/<repo>/<image>:<tag>`	Same image name, `docker push`
npm	`https://host/npm/<repo>/`	`npm publish`
PyPI	`/pypi/<repo>/simple/`	`/pypi/<repo>/legacy/`
NuGet	`/nuget/<repo>/v3/index.json`	Same source, `--api-key` is the token
Helm	`/helm/<repo>/` or `oci://host/helm/<repo>`	HTTP upload or `helm push`
Go	`/go/<repo>/`, set `GOPROXY`	Console or management API
APT	`/apt/<repo>/`	Upload to `pool/<filename>`
YUM	`/yum/<repo>/`	`POST .../upload`
Raw	`/raw/<repo>/<path>`	Same path, `curl -T`

The rest of this guide uses repo.anguskit.com as the host. On a self-hosted instance, replace it with your address.

Maven

Run these commands from a project root that already has a pom.xml. The repository id in settings.xml and pom.xml must match exactly.

Authenticate

Save the following as settings.xml in the project root. If you already have ~/.m2/settings.xml, merge the <server> block into it. Do not overwrite the existing file.

<settings>
  <servers>
    <server>
      <id>angusrepo-maven-releases</id>
      <username>${env.REPO_USER}</username>
      <password>${env.REPO_TOKEN}</password>
    </server>
  </servers>
</settings>

Publish

Add the publish URL to pom.xml, then deploy. A successful run logs BUILD SUCCESS.

<distributionManagement>
  <repository>
    <id>angusrepo-maven-releases</id>
    <url>https://repo.anguskit.com/maven/maven-releases</url>
  </repository>
</distributionManagement>

mvn -s settings.xml clean deploy

Verify the pull

Add the same repository to another project, then request the groupId, artifactId, and version you just published.

<repositories>
  <repository>
    <id>angusrepo-maven-releases</id>
    <url>https://repo.anguskit.com/maven/maven-releases</url>
  </repository>
</repositories>

mvn -s settings.xml dependency:get \
  -Dartifact=yourGroupId:yourArtifactId:yourVersion

Docker

Run this from a directory that contains a Dockerfile. The image name is host/repo/image:tag. Do not insert /v2 yourself.

Authenticate

echo "$REPO_TOKEN" | docker login repo.anguskit.com \
  -u "$REPO_USER" --password-stdin

Continue after you see Login Succeeded.

Publish

docker build -t myapp:1.0.0 .
docker tag myapp:1.0.0 repo.anguskit.com/docker-releases/myapp:1.0.0
docker push repo.anguskit.com/docker-releases/myapp:1.0.0

Verify the pull

docker pull repo.anguskit.com/docker-releases/myapp:1.0.0

npm

Run this from a directory that contains package.json. Keep the trailing / on the registry URL, and leave ${NPM_TOKEN} unchanged in .npmrc.

Authenticate

Create or update .npmrc in the project root:

registry=https://repo.anguskit.com/npm/npm-releases/
//repo.anguskit.com/npm/npm-releases/:_authToken=${NPM_TOKEN}
always-auth=true

Then, in the same terminal:

export NPM_TOKEN="$REPO_TOKEN"

Publish

name and version in package.json are the package you publish. If that version already exists, bump version first.

npm publish

Verify the pull

npm install your-package

For an @scope package, also add this to .npmrc:

@scope:registry=https://repo.anguskit.com/npm/npm-releases/

PyPI

Run this from a directory that contains pyproject.toml. Upload to /legacy/ and install from /simple/. The package name is name in pyproject.toml.

Prepare the environment

python3 -m venv .venv
source .venv/bin/activate
python3 -m pip install build twine

Publish

dist/ is created by the build. You do not create it by hand.

python3 -m build
twine upload \
  --repository-url https://repo.anguskit.com/pypi/pypi-releases/legacy/ \
  -u "$REPO_USER" -p "$REPO_TOKEN" dist/*

Verify the pull

pip install your-package \
  --index-url "https://${REPO_USER}:${REPO_TOKEN}@repo.anguskit.com/pypi/pypi-releases/simple/"

NuGet

Run this from a directory that contains a .csproj. The NuGet source URL must end with /v3/index.json.

Authenticate

This command stores the credentials in the local NuGet config.

dotnet nuget add source https://repo.anguskit.com/nuget/nuget-releases/v3/index.json \
  --name angusrepo \
  --username "$REPO_USER" \
  --password "$REPO_TOKEN" \
  --store-rest-token

Publish

dotnet pack -c Release
dotnet nuget push bin/Release/Your.Package.1.0.0.nupkg \
  --source https://repo.anguskit.com/nuget/nuget-releases/v3/index.json \
  --api-key "$REPO_TOKEN"

Use the .nupkg file name that dotnet pack actually printed.

Verify the pull

Run this in another existing project:

dotnet add package Your.Package --version 1.0.0 --source angusrepo
dotnet restore

Helm

Helm speaks HTTP and OCI. Pick the one shown on the repository Setup tab: helm repo add means HTTP, oci:// means OCI. Do not mix the two flows. The current directory should contain a chart with Chart.yaml.

HTTP

helm repo add angusrepo https://repo.anguskit.com/helm/helm-releases \
  --username "$REPO_USER" --password "$REPO_TOKEN"

helm package ./mychart
curl -u "$REPO_USER:$REPO_TOKEN" \
  -F "chart=@mychart-1.0.0.tgz" \
  "https://repo.anguskit.com/helm/helm-releases/api/charts"

helm repo update
helm install my-release angusrepo/mychart

Replace mychart-1.0.0.tgz with the file name helm package printed.

OCI

echo "$REPO_TOKEN" | helm registry login repo.anguskit.com \
  -u "$REPO_USER" --password-stdin

helm package ./mychart
helm push mychart-1.0.0.tgz oci://repo.anguskit.com/helm/helm-releases
helm install my-release oci://repo.anguskit.com/helm/helm-releases/mychart --version 1.0.0

Go

go get only downloads modules. Upload from the console or the management API. Do not send the upload to repo.anguskit.com/api. The module path comes from go.mod, and the version must start with v, for example v1.0.0.

Configure the pull

A private module needs GOPROXY and the module domain. Replace GONOSUMDB with your module domain, or checksum verification can fail.

export GOPROXY="https://${REPO_USER}:${REPO_TOKEN}@repo.anguskit.com/go/go-releases"
export GONOSUMDB=example.com

Publish

Run this from the module root. The top directory inside the zip must be module-path@version/ and must contain go.mod. The cloud API base is below. On a self-hosted instance, ask your administrator for the management API base.

export API_BASE="https://bj-c1-prod-apis.anguskit.com/repo"
export MODULE="$(go list -m)"
export VERSION="v1.0.0"
export PREFIX="${MODULE}@${VERSION}"
STAGE="$(mktemp -d)"
mkdir -p "${STAGE}/${PREFIX}"
cp go.mod *.go "${STAGE}/${PREFIX}/"
(cd "${STAGE}" && zip -qr "${OLDPWD}/module-${VERSION}.zip" "${PREFIX}")
rm -rf "${STAGE}"

curl -u "$REPO_USER:$REPO_TOKEN" \
  -F "repositoryName=go-releases" \
  -F "version=${VERSION}" \
  -F "modulePath=${MODULE}" \
  -F "zip=@./module-${VERSION}.zip" \
  "$API_BASE/api/v1/go/upload"

You can also open that Go repository and upload the zip from the upload page.

Verify the pull

go get example.com/go-demo@v1.0.0

APT

Start from a .deb you have already built. Install by the package name inside the archive, not by the .deb file name. stable and main must match the repository distribution and component. If Setup shows different values, use those.

Publish

curl -u "$REPO_USER:$REPO_TOKEN" -T ./my-package_1.0.0_amd64.deb \
  "https://repo.anguskit.com/apt/apt-releases/pool/my-package_1.0.0_amd64.deb"

Verify the pull

The index can take a few seconds after upload. Replace my-package with the package name inside the deb:

echo "deb [trusted=yes] https://${REPO_USER}:${REPO_TOKEN}@repo.anguskit.com/apt/apt-releases stable main" \
  | sudo tee /etc/apt/sources.list.d/angusrepo.list
sudo apt-get update && sudo apt-get install my-package

YUM

Start from an .rpm you have already built. Install by the RPM package name, not by the file name.

Publish

The upload must use the form field file:

curl -u "$REPO_USER:$REPO_TOKEN" \
  -F "file=@./my-package-1.0.0-1.noarch.rpm" \
  "https://repo.anguskit.com/yum/yum-releases/upload"

Verify the pull

The command below writes /etc/yum.repos.d/angusrepo.repo. If the package is missing right after upload, wait and try again.

sudo tee /etc/yum.repos.d/angusrepo.repo >/dev/null <<EOF
[angusrepo]
name=AngusRepo YUM
baseurl=https://${REPO_USER}:${REPO_TOKEN}@repo.anguskit.com/yum/yum-releases/
enabled=1
gpgcheck=0
EOF
sudo dnf clean all && sudo dnf install my-package

Raw

A Raw repository stores files that do not belong to a package format. Pick a clear path, such as project/version/filename. Upload and download must use the same URL.

Publish

curl -u "$REPO_USER:$REPO_TOKEN" -T ./my-app-1.0.0-linux-amd64.tar.gz \
  "https://repo.anguskit.com/raw/raw-releases/my-app/1.0.0/my-app-1.0.0-linux-amd64.tar.gz"

Uploading to the same path again overwrites the file.

Verify the pull

Download from another directory so the file does not collide with the local source:

mkdir -p /tmp/raw-check && cd /tmp/raw-check
curl -u "$REPO_USER:$REPO_TOKEN" -O \
  "https://repo.anguskit.com/raw/raw-releases/my-app/1.0.0/my-app-1.0.0-linux-amd64.tar.gz"

Troubleshooting

What you see	Check first
Publish returns 403	The account behind the token has write access to that repository.
Docker push fails	The image name must not contain `/v2`. `docker build` must succeed locally first.
npm returns 401 or 404	The registry URL and the `_authToken` path match, including the trailing `/`. `NPM_TOKEN` is set.
PyPI upload or install fails	Upload goes to `/legacy/`, install uses `/simple/`. Run `python3 -m build` first.
NuGet restore fails	The source URL ends with `/v3/index.json`, and the local credential store has the right token.
Helm returns 401	Do not mix the HTTP and OCI flows. Run `helm registry login` before an OCI push.
APT or YUM cannot find a package you just uploaded	Wait for the index, then refresh the cache. Install by the name inside the package, not the file name.
Go upload fails	The top directory in the zip is `module-path@version/`, and the upload URL is the management API.

How authentication works

Protocol paths such as /maven/, /npm/, and /v2/ use Basic Auth: the username is the login name, and the password is the access token. The management REST API uses a Bearer token where the API reference says so. If authentication fails, check that you did not swap the two.

Originally published at anguskit.com.