JFrog Artifactory Repository Types: Local, Remote, and Virtual – Capabilities Table
| Feature / Operation | Local Repository | Remote Repository | Virtual Repository |
|---|---|---|---|
| Primary Use | Store organization’s own (first-party) build artifacts | Proxy/cache artifacts from remote third-party repositories | Single aggregated endpoint mapping to one or more local/remote repositories |
| Write (Deploy) Artifacts | Yes – artifacts are uploaded/published by users, CI/CD, build tools | No – direct deploy/upload not supported (only proxy/caching) | No – artifacts cannot be deployed directly to a virtual repo; must target underlying local repo |
| Read (Download) Artifacts | Yes – download by any authorized user or process | Yes – fetches/caches requested artifacts from remote source on-demand | Yes – acts as a unified endpoint for read/download from all mapped repos (local and remote) |
| Caching | No – only contains what is uploaded directly | Yes – caches remote artifacts locally after first access | Inherits cache of mapped remote repositories |
| Direct Sync/Replication | Yes – supports push/pull replication to other Artifactory instances | No – cannot be a source/target for replication (except indirect offline mode) | No – managed at the underlying repo level |
| Content Delete/Modify | Yes – authorized users can move, update, or delete artifacts | No – cannot modify or delete cached artifacts directly; cache can be expired/cleared | No – actions must be performed on the underlying actual repo |
| Retention Policies | Yes – customizable retention, expiration, and cleanup policies | Yes – can expire cached artifacts as per cache policy | Inherited from target repositories |
| Security/Access Control | Full RBAC, permissions, and policy enforcement | RBAC applies to access, but content is as trusted as remote source | Policy enforcement at the virtual repository level (applies RBAC and rules to all mapped repos) |
| Supports Metadata/Tagging | Yes | Limited; some metadata from upstream may be missing | Yes – for artifacts visible through mapped repos |
| Can Serve as Distribution | Yes – recommended for delivery of organizational releases | Yes – improves reliability for up/downstream open source and external dependencies | Yes – virtuals are best for developers and automation: one unified URL for all artifacts |
| Artifact Scanning (SCA/Security) | Yes – full scan on uploaded artifacts with appropriate licenses/tools | Yes – scans on cached artifacts (post-download); risk inherited from original source | Inherits scanning as applied to mapped underlying repos |
| Typical Examples | internal/libs-release-local, docker-local | maven-central-remote, npmjs-remote, pypi-remote | libs-release, all-docker (maps both local “docker-local” and remote “docker-hub-remote”) |
| Best Practice | Use for all builds produced by your teams | Proxy all required third-party remotes for speed, reliability, consistent compliance | Expose a virtual repo per ecosystem (e.g., Maven, npm, Docker) for simplified client configuration and access control |
| Can Aggregate Multiple Repos | No | No | Yes – can aggregate multiple local and/or remote repos, and present as a single logical repository |
| Direct Artifact Promotion | Yes – supports promotion workflows, moves/copies between local repos | No – cannot promote (only cache/clear) | No – must perform artifact promotion on the underlying local repo |
| Requires External Internet | No – fully internal | Yes, to fetch uncached artifacts | Depends on mapped remotes: if only local repos are mapped, no internet needed |
| Can Set as Build Target | Yes | No | Yes – but artifacts end up in mapped local repository, not in the virtual repo itself |
Key Takeaways
- Local repositories are for internal artifact management—store, manage, promote, and distribute your own production artifacts.
- Remote repositories act as trusted proxies/caches for public or third-party dependencies, improving reliability, security, and performance.
- Virtual repositories are powerful logical aggregators: expose a unified URL for developers, automate policy enforcement, and simplify repo configuration by hiding backend complexity.
Each type has a distinct role. Using them together streamlines software delivery, reinforces artifact governance, and ensures robust DevOps security and compliance.
Add to follow-up
Check sources