MOTOSHARE 🚗🏍️
Turning Idle Vehicles into Shared Rides & Earnings
From Idle to Income. From Parked to Purpose.
Earn by Sharing, Ride by Renting.
Where Owners Earn, Riders Move.
Owners Earn. Riders Move. Motoshare Connects.
With Motoshare, every parked vehicle finds a purpose.
Owners earn. Renters ride.
🚀 Everyone wins.
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