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.
Ownership without silos
A single, elegant repo topology replaces duplication, sprawl and confusion
Without CloudsmithDependency sprawl. Critical packages and shared libraries are scattered across multiple teams, so nobody is sure which copy is current or who maintains it.
With CloudsmithOne 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.
Without CloudsmithAccess means ceding ownership. To let teams use a package, platform teams hand over control, and visibility and policy enforcement slip away.
With CloudsmithOwnership and access control stay where they belong. A central team curates the shared packages, and every team resolves them through its own URL.
Without CloudsmithPipelines 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.
With CloudsmithOne 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.
Connected repositories let a primary repository resolve packages from other Cloudsmith repositories. Your teams use one URL, and Cloudsmith handles resolution behind it.
No. Upstreams configured on connected repositories are automatically available through the primary repository, so you configure them once.
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.
Immediately. Packages are available from all connected repositories as soon as they are pushed or updated, with no indexing required.
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.
Not yet. Connected repositories are not currently supported by the cooldown policy feature, which is a known limitation during its early access.
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.