--- title: "Connected repositories | Cloudsmith" description: "One governed URL per team. Connected repositories give developers instant access to every package while platform teams keep ownership and control." canonical_url: "https://cloudsmith.com/product/connected-repositories" last_updated: "2026-10-19T11:41:05Z" --- # Connected repositories | Cloudsmith Connected repositories ## One URL per team. **Instant availability.** No failed pipelines. One governed URL for everything the teams need, without asking anyone to change how they work. [Book a demo](/book-a-demo) [Read the documentation](https://docs.cloudsmith.com/repositories/connected-repositories) Ownership without silos ## A single, elegant repo topology replaces duplication, sprawl and confusion | Without Cloudsmith | With Cloudsmith | | --- | --- | | Dependency sprawl. Critical packages and shared libraries are scattered across multiple teams, so nobody is sure which copy is current or who maintains it. | One home for shared libraries and packages. The libraries multiple teams and products depend on live in a single central repository, connected to every team repository and never copied. | | Access means ceding ownership. To let teams use a package, platform teams hand over control, and visibility and policy enforcement slip away. | Ownership and access control stay where they belong. A central team curates the shared packages, and every team resolves them through its own URL. | | Pipelines depend on hardcoded URLs and duplicated packages. Each update has to be rolled out repository by repository, and builds fail when a copy falls behind. | One URL per team. Packages are available as soon as they are pushed or updated, existing configuration keeps working, and velocity holds as the organization grows. | What connected repositories deliver ## One governed URL means engineering can scale and the supply chain stays under control One governed URL means engineering can scale, the supply chain is provably under control, and the platform cost curve bends down instead of up. ### Standardization becomes structural One URL replaces Slack-thread policing. Standardization becomes structural. Stop being the bottleneck. ### Control enforced by architecture Centrally curated packages, enforced by architecture. One place to audit and enforce policy, one answer when the CISO asks what’s in prod, one answer for SBOMs, compliance, and enterprise procurement. ### A cost curve that bends down Faster resolution means lower CI/CD spend. Platform teams stop firefighting. There is zero rollout cost, and it’s built on what teams already used. ### Repo count stays flat as headcount grows Repo count doesn’t grow with headcount. You tell your CTO how you kept control while engineering scaled. Shared packages and libraries ## Store your important shared libraries once and share them with every repository Keep the open source libraries, vendor images and internal packages that many teams rely on in one central repository. Connect it to your other repositories, and every team gets them without a copy. ### One home for shared packages A central team curates and owns the shared packages in a single repository. Ownership and access control stay where they belong. ### Available to every connected repository Connect the shared repository to your team repositories and its packages resolve through each team's own URL. Packages are available as soon as they are pushed or updated. ### Upstreams come along Upstreams configured on the shared repository are automatically available through the repositories connected to it, with no packages duplicated. ### Update once, everyone benefits When a shared package is updated, every team resolving it through a connected repository sees the change. One place to audit and enforce policy. Already in your workspace ## Built on Upstreams. Results inside a sprint. Connected repositories build on what your teams already use, so there is nothing to roll out. ### No migration Connected repositories are built on Upstreams already in your workspace, so there is nothing to move. ### No new credentials There is nothing new to issue or manage for your teams. ### No hardcoded URLs to change Teams point at one governed URL, and existing configuration keeps working. ### No training Developers keep using the package managers they already know. ## Frequently asked questions Here is what platform teams ask us most when they evaluate connected repositories, from how upstreams are inherited to what shows up in the package list. ### What are connected repositories? Connected repositories let a primary repository resolve packages from other Cloudsmith repositories. Your teams use one URL, and Cloudsmith handles resolution behind it. ### Do I need to configure upstreams on each repository? No. Upstreams configured on connected repositories are automatically available through the primary repository, so you configure them once. ### Are packages duplicated in the primary repository? No. The primary repository does not cache or duplicate packages. It inherits the upstreams and pulls packages straight through from the repository that holds them. ### How quickly do new packages become available? Immediately. Packages are available from all connected repositories as soon as they are pushed or updated, with no indexing required. ### Will connected packages appear in the primary repository's package list? No. In the Cloudsmith web app and API, packages from connected repositories do not appear in the primary repository's package list or search results, although they still resolve for your package managers. ### Does a cooldown policy work with connected repositories? Not yet. Connected repositories are not currently supported by the cooldown policy feature, which is a known limitation during its early access. ### Does Cloudsmith have virtual repositories? Connected repositories are Cloudsmith's equivalent of virtual repositories. In JFrog's model, virtual repositories re-resolve metadata on every pull and are restricted to a single package type per virtual repo. Connected repositories are built on Upstreams, so packages are available instantly and one URL serves every format. Helpful resources ## Related resources These resources help your platform team plan a cleaner repository structure and move to Cloudsmith with confidence. ### [Migrating to Cloudsmith: A Comprehensive Guide to Modern Artifact Management ](/campaigns/cloudsmith-migration-guide) Legacy artifact management systems are slow, costly, and difficult to scale - leaving teams frustrated and slowing software delivery. In this guide, Cloudsmith shares a proven, enterprise-tested framework to help organizations migrate to Cloudsmith: a fully managed, cloud-native artifact management platform designed to simplify DevOps pipelines, improve security posture, and accelerate release velocity. ### [The 2026 Artifact Management Report](campaigns/2026-artifact-management-report) The 2026 Artifact Management Report examines the structural vulnerabilities now embedded in modern development pipelines, and the operational, regulatory, and architectural responses required to address them. ## Scale engineering **without losing control** Talk to a Cloudsmith expert about putting one governed URL in front of every team. [Book a demo](/book-a-demo) [Pricing options](/pricing)