By submitting this form, you agree to our 

A practical guide to AI artifacts and LLMOps

Securing non-deterministic systems

 Dependabot is great at keeping dependencies current, but update automation and ingestion control solve different problems. Cloudsmith acts as an upstream gatekeeper; ensuring packages are verified before they ever enter your environment. Together, they cover more of the supply chain than either does alone.

Let’s frame a scenario: a new dependency version is released. Within hours, Dependabot opens a pull request to upgrade your application.

The change looks routine. The PR is merged.

But this version wasn’t just an update - it was part of a coordinated malware campaign.

Before long, the compromised package has made its way into your build environment, cache layers, and developer workstations. Your security team is pulled into incident response, and a difficult question follows:

How did this get through so quickly, and how do we prevent it next time?

How dependency updates become a supply chain risk

To understand how this scenario unfolds, it’s worth breaking down what actually occurs between a dependency being published and a pull request being merged. When a new version of a package is released by a maintainer (or malicious actor in this case), it becomes immediately available in upstream registries such as npmjs, pypi, Maven Central, or DockerHub.

Tools like Dependabot continuously scan your repository’s dependency files for updates. As soon as a new version is detected, Dependabot compares it against what your application is currently using. If a valid upgrade path exists, it automatically opens a pull request with the updated version. From a developer’s perspective, everything looks normal:

The dependency comes from a trusted source

The version increment appears routine (ie. “It’s probably a patch or security fix”)

The pull request follows a familiar, repeatable workflow

Nothing appears out of the ordinary - which is exactly how these attacks are designed.

At no point in this process is there a built-in mechanism to evaluate whether a newly released version is too new, potentially unverified, or part of a broader security incident without additional manual investigation. To make matters worse, it often takes time for security researchers to identify and report malicious packages, leaving a window where compromised versions can spread undetected.

That's not a criticism of the tool, it's a reminder that no single layer of automation was built to catch everything.

The problem isn’t automation; it’s the absence of an upstream control layer that determines when a dependency can be trusted and safely consumed

Dependabot cooldowns: Helpful, but not a complete safeguard

To address the risk of organizations rapidly adopting new dependencies, Dependabot offers a cooldown feature that allows platform teams to introduce a delay before opening pull requests for newly released dependency versions.

In practice, this means that even if a new version becomes available in the registry, Dependabot will intentionally wait for a defined period of time before suggesting the update through the pull request.

This provides an additional layer of protection:

It gives the ecosystem the time to detect and flag malicious packages

It reduces the likelihood of of immediately adopting unverified releases

It helps avoid 0-Day exposure to newly published vulnerabilities

For many teams, this delay can significantly reduce risk. However, it’s important to recognize what this control does and does not protect against. Dependabot’s cooldown feature operates at the pull request level, meaning that it controls when an update is suggested, but it does not control what is ultimately available to your build systems or developers once a version is accessible in a registry.

Once a dependency version is published and reachable, it can still be:

Downloaded outside of Dependabot entirely

In other words, Dependabot’s cooldown feature only influences one path to consumption, but not all paths. This naturally creates a gap: even with cooldown in place, a malicious package can still be consumed before it is ever flagged or blocked. While Dependabot’s cooldown can help reduce noise and delay exposure, they do not enforce a boundary around what dependencies your organization is allowed to consume.

If Dependabot’s cooldown helps reduce the speed of adoption, the next question becomes:

What controls when a dependency is allowed to exist in your environment at all?

Dependabot's cooldown helps slow the rate of adoption, but it doesn't control what dependencies are reachable in the first place. To close that gap, organizations need a control layer that sits upstream of their build systems entirely - one that determines whether a dependency is even available before any tool can request it.

Introducing an upstream gatekeeper for dependency security

 comes in as your upstream gatekeeper. Instead of allowing direct, unrestricted access to upstream packages, Cloudsmith acts as a controlled gateway. With Cloudsmith Advanced Security, organizations can also introduce cooldown periods as policies to introduce time-based buffers to quarantine newly published dependency versions across a variety of different package formats.

For example, I currently work with a customer who has implemented a 5-day cooldown period for all npm packages with an updated version within that 5 day window. During this time, the customer can:

Check security advisories for any potential malware

Validate the upstream maintainer and perform additional reconnaissance

Only after the 5 day cooldown period is the package unquarantined and made available for download. When combined with Dependabot’s cooldown feature, organizations can layer the Dependabot cooldown with Cloudsmith’s to maximize security. Here’s an example workflow:

On Day 0, a new dependency version is released.

 The version exists upstream, but Cloudsmith intentionally keeps it out of reach in quarantine state. It cannot be pulled by developers or CI/CD pipelines.

 The version becomes available through Cloudsmith after the cooldown period has passed.

 Dependabot is pointed to Cloudsmith, and now detects the newly available version and opens a pull request.

Cloudsmith controls when the version becomes consumable, while Dependabot controls when the version is proposed. Together, they ensure that updates are both safe and timely, without exposing the organization to newly released, potentially risky artifacts.

Modern software delivery depends on automation, and tools like Dependabot have made keeping applications current easier than ever. But automation can only work safely within the boundaries set for it. Without an upstream control layer, every newly published dependency version is immediately exposed to your systems, trusted by default, not by design.

By pairing Dependabot with Cloudsmith's upstream cooldown policies, you create a model where trust is earned over time rather than assumed at the moment of release. Small in implementation, significant in impact: that shift is what allows teams to move fast without leaving the door open.

This layered approach is essential for organizations looking to strengthen their 

 without slowing down development velocity.

Cristian Garcia

Senior Customer Success Manager

Layered defense for dependencies: Why dependabot needs an upstream gatekeeper

The Hybrid Repository Structure: Balancing Control and Flexibility

And now, let’s dive into part three: How 

 keep your multi-format repositories secure, consistent, and developer-friendly.

In the first two blogs of this series, we explored why repository structure matters and how Cloudsmith’s Hybrid Repository Structure balances control with flexibility. While we touched on policies and permissions, we didn’t dive into the 

 mechanics of how access control ensures artifact security, traceability, and consistency, especially in 

, where different packages, languages, and tooling coexist in a single place.

While multi-format repositories allow for more flexibility in how your repositories are set up, they can introduce a new way of thinking about how and when different artifacts can be accessed and by whom. This blog breaks down how Cloudsmith provides fine-grained, flexible, and secure controls for teams of any size.

Cloudsmith provides the following user roles:

These roles help limit access based on organizational need and provide the foundation for more granular permissions.

You can explore the full breakdown of Cloudsmith roles, permissions, and privileges in our documentation.

You can read more about user roles, permissions, and privileges in Cloudsmith 

Every Cloudsmith customer is given the opportunity to set default global privileges. These global default privileges are set for the “Member” user role in Cloudsmith, which is often suited best for individual developers. Within a customer’s global workspace privileges, organizations can choose to grant members the ability to create new teams, invite new users, and even create new repositories. Organization owners can also grant “blanket” repository privileges to all users within Cloudsmith. 

While we offer the flexibility for organizations to shift responsibility and access to the developer, we often see our enterprise customers lean away from blanket permissions and access toward more fine-grained permissions. As an example, we have a semiconductor manufacturing customer that has disabled default workspace global privileges so that only Organisation owners are the only users who can invite new users, create new teams, invite 3rd-party collaborators, and create new repositories. 

In addition, this customer has access control, and privileges are scoped down to specific teams. Default global repository privileges are disabled so that they can choose exactly which team(s) should have access to repository(s). Even Cloudsmith service accounts are grouped together within a team for ease of tracking permissions and access when it comes to build and deployment times. 

If we zoom in once and look at the repository level in Cloudsmith, we can assign a default privilege for organization members for accessing packages within the repository, and we can assign specific privileges for specific teams, users, or service accounts.

This is the stage where you’ll have to consider what packages the repository is storing and if you want developers and service accounts to have default admin, read, or write permissions to the repository. Continuing to use my customer example, they have chosen to set default read permissions for all repositories; however, specific service accounts have write and 

 to different repositories. You may be okay with your developers downloading artifacts to their local machine for testing or even service accounts requesting stored artifacts tied to staging and production environments.

On the other hand, there are customers that may not want their developers having the ability to write to every repository and would most likely want specific service accounts tied to their CI/CD pipelines to only have write permissions. While this is generally best practice, there are certainly exceptions to this rule, as we also have platform teams that choose to grant specific developer teams write access to specific artifact repositories.

On top of the permission and access control settings we’ve discussed, Cloudsmith goes even further to ensure that, through various additional settings, platform teams can decide exactly what their developers need and don’t need to be reconfigured within a repository.

Platform teams are able to grant or deny developer permissions, such as:

Copying Packages From One Repository to Another

Moving Packages From One Repository to Another

Managing, Using, Or Viewing Entitlement Tokens

If you thought that wasn’t enough, Cloudsmith takes it a step further by scoping down permissions to the individual developer’s generated packages. So while platform teams can restrict tampering of artifacts generated by other developers or systems, they can also decide if they would like to allow developers the ability to scan, move, copy, delete, or resync their own packages.

Most of the enterprise customers I work with allow developers to do as they please with their own packages to avoid a developer mutiny! In either case, these user actions are catalogued in our 

 for enhanced observability across your Cloudsmith environment.

For instances where our customers want to be very particular about what, how, and when users can access specific packages, Cloudsmith offers 

. These scoped tokens are read-access only, so there is never a risk of a user performing a write action against the repository they have limited access to.

Customers are able to restrict access by creating a precise search query to narrow down specific packages within a repository, should they choose not to provide visibility into all the packages within the repository. On top of visibility restrictions, customers can also add token usage restrictions to avoid prolonged access and usage of the token. Parameters include:

Typically, we see our customers use entitlements for 3rd party software distribution or even for systems that don’t require logins to Cloudsmith.

For our security-conscious customers, Cloudsmith also offers the ability to configure 

 based on country, with an easy-to-use preconfigured list of countries to choose from. Choose to deny or allow access from specific countries. Although keep in mind that theoretically, no unauthenticated user should have access to your Cloudsmith workspace in general. This restriction applies more towards open-source repositories that you may be hosting in Cloudsmith, but it’s always a good idea to practice defence-in-depth!

If geo-based restrictions are too broad, you can scope down to IP-based restrictions to either allow or deny client access based on IP address. This added protection ensures that requests coming from clients with an unapproved IP address do not have access to your repositories. 

With all of these configuration options, it can be tricky to decide how you want to best enable your developers while balancing security and flexibility. Not to worry—the Cloudsmith Customer Success team is here to help you in your decisions throughout the onboarding process. We’ve walked through these decisions with many customers and have outlined decision impacts for you so you’re not left wondering “what if”. Learn more about Cloudsmith 

 to get started with us. See you on the other side! 

1. What is access control in a multi-format repository?

Access control defines who can read, write, or administer artifacts across different package formats stored in the same repository. It ensures secure, consistent governance across diverse tooling.

2. How do permissions work in Cloudsmith for multi-format repositories?

Cloudsmith supports global, repository-level, team-based, and user-specific permissions, allowing organizations to tailor access to packages, teams, service accounts, and even individual artifact actions.

3. Why is fine-grained access control important in software supply chain security?

Fine-grained controls reduce the blast radius of errors, prevent unauthorized writes, and help organizations enforce policies required by modern software supply chain frameworks like SLSA and SSDF.

4. What are entitlement tokens used for in Cloudsmith?

Entitlement tokens provide scoped, read-only access to specific artifacts without requiring user accounts, making them ideal for external distribution, automation, or least-privilege workflows.

5. Can developers manage their own packages in Cloudsmith?

Yes. Cloudsmith allows permissions that let developers manage only the packages they personally created—without putting others’ artifacts at risk.

6. How does Cloudsmith support secure CI/CD pipeline access?

Service accounts can be granted precisely the permissions needed for pipeline operations (like write or admin) while keeping developers and collaborators restricted to read-only or scoped access.

7. What’s the difference between global and repository-level privileges?

Global privileges affect the entire workspace, while repository-level privileges enable granular control over specific teams, users, or service accounts interacting with a particular repository.

Repository Structure

Access control & permissions for multi-format repositories

We often advise our customers to consider a “Hybrid” repository structure, which incorporates both the development environment (dev, staging, prod) and the specific team/application/service for artifact repositories in Cloudsmith. This is essentially just adding another layer to the team/application/service specific repository structure that provides better visibility and traceability of different environments. 

It might help to visualize the hybrid approach (we’ll discuss what we mean by “automated promotion” below).

Why Choose a Hybrid Repository Structure?

You might consider a hybrid repository structure if you find that a purely environment-based or purely team-based model leaves gaps in your workflow. For example, if your artifact repositories are currently team-based (set up solely by teams/services/applications), it can be difficult to put the right artifact promotion workflows in place without leveraging very strict artifact tagging practices. It also makes it harder to view artifacts across your various development stages. On the other hand, if you use an environment-based model group by development environment) without clear distinctions between teams/services/applications, you might run into visibility and traceability issues across artifacts.

We often see Cloudsmith customers that have outgrown single-model repository setups and are beginning to feel growing pains. As your organization grows, so does the demand for more efficient software development practices. The “simpler” repository model runs the risk of ultimately creating confusion, duplication, and lack of accountability. The hybrid approach contains that complexity in a clear and concise way that aligns with your development environments and organizational structure.

When To Choose a Hybrid Repository Structure?

Different compliance requirements across applications and environments is often a trigger for moving to a hybrid repository structure. For example, if your production environment for your government-facing application needs stricter security controls than your development environment for an internal application, a hybrid approach lets you apply different vulnerability policies to each.

Another reason to choose a hybrid structure is when you start getting into different product lines, diverse tech stacks, or growing sets of microservices. If you need to ensure that each product or service can move through specific stages of development independently, the hybrid approach makes that possible without sacrificing consistency.

It also rewards organizations that value observability. For instance, there may be times where you may need to investigate rogue image downloads from specific client requests within your staging environment that are causing a spike in package delivery demand. Or consider what happens when a pipeline has ingested a malicious package and you need to trace back to the originating repository. If the hybrid approach is adopted correctly, both of these situations can be addressed a lot more easily and quickly by security and observability teams.

At Cloudsmith, we partner closely with SRE’s and infosec teams early in the onboarding process to ensure our customers are well equipped to handle these situations.

One of the more popular topics we discuss during customer onboardings is the practice of artifact promotion across repositories. Package promotion workflows can be the place where artifact management breaks down in less structured setups.
In the hybrid model, environment based repositories act as quality gates that artifacts must pass through before reaching production. This ensures that only vetted, tested, and approved artifacts move forward, reducing the risk of instability, untested code, or vulnerable code being deployed into customer-facing applications. Development teams can still own and manage their artifacts independently, while the environment boundaries guarantee a consistent, auditable path throughout the artifact lifecycle.

The other significant benefits of the hybrid approach are visibility and governance. With a purely environment-based structure, it can be difficult to quickly identify who “owns” a package or service, while a purely service-based approach risks muddying the waters when promoting artifacts across environments.
The hybrid approach solves this tension but allows teams to retain clear ownership of their artifacts, while environment-based repositories enforce quality “gates” as well as access controls as packages move from development to staging, to production.

A hybrid repository structure strikes the balance between order and flexibility. By combining environment-based repositories (development, staging, and production) with service, application, or team-specific segmentation, organizations gain more control over how software flows through their pipelines without losing sight of ownership or accountability.
This approach creates clear boundaries between environments while still aligning repositories with the way development teams actually build and ship software.

How to Implement the Ideal Hybrid Repository Structure?

There isn’t a “one-size-fits-all” approach to implement a hybrid repository structure, but there are a few patterns that work especially well depending on how your organization is structured. One common approach is to segment by team and environment. For example, you might have repositories like frontend-dev, frontend-staging, and frontend-prod, alongside backend-dev, backend-staging, and backend-prod. This approach works well when you have dedicated frontend and backend teams who need clear ownership of their artifacts, while environment-based repositories provide the quality gates required to promote code safely through your organization’s environments.

Another variation is to organize by product/service and environment, such as payments-dev, payments-staging, and payments-prod for services. This model is particularly effective for organizations running microservices or multiple customer-facing products. Each service has a self-contained promotion pipeline making it easier to test, release and troubleshoot independently without impacting other teams. Larger organizations sometimes prefer a department or function-based hybrid model, where repositories are grouped for example by mobile-dev, mobile-staging, mobile-prod for a mobile app focused engineering team, while a data focused team might have their own set of similar repositories. Again, this keeps things scalable and avoids proliferation of repositories, while still ensuring environment-based control.

Finally, a useful approach includes a shared dependency repository alongside service and environment repositories. For example, you might have a shared-libs repository where internal SDKs, libraries, and external dependencies might live to be used across multiple services or applications. The Cloudsmith customer success team often recommends enterprise customers adopt this approach for both deduplication of dependencies as well as ensuring there is a dedicated “ingress” repository that acts as a security gate for proxied dependencies. This avoids having multiple “development” repositories having multiple upstream configurations and helps greatly with auditability.

Companies with just a few major products often do best with a product + environment structure, while those running many microservices benefit from a service + environment structure. Smaller, more agile teams might lean towards a team + environment approach to meet their specific needs. In most enterprise environments, it’s actually common to mix multiple hybrid patterns within a single artifact registry. Your teams might use all 3 of the above approaches depending on specific workflow requirements. We call this “multi-pattern hybrid repository structure”.

For each of the above hybrid structures, our customers have the ability to automate the creation of these repositories on behalf of their development teams using our REST API and Terraform provider, with some customers even creating golden paths or secure self-service workflows to enable development speed and freedom. Overall, the key to getting the hybrid approach just right for your organization is to align your repositories with how your development teams are organized as well as how your CI/CD pipelines actually operate.

Cloudsmith’s Support for Hybrid Repository Structures

Cloudsmith is the modern way to store and distribute your software at scale, securely. With Cloudsmith’s multi-format support and build-in scale, we are able to meet the needs of the largest enterprises building and distributing software today. Gone are the days of language formats bound to repositories and limits on how many repositories you can create.

With Cloudsmith, your developers are able to spin up new globally distributed repositories with just a few clicks or commands to meet their needs. All of this comes out of the box with Cloudsmith. The Cloudsmith Customer Success team is here to help you navigate repository configurations, especially the hybrid approach given the amount of customers we have benefitting from this approach.

If you haven’t already, check out our previous post, 

, where we break down the foundational principles behind effective repository organization and how the right structure can shape your software delivery success.

In the world of artifact management, a repository structure refers to how software artifacts—such as Docker images, Python packages, npm modules, and more—are organized, stored, and accessed. It defines how repositories are named, grouped, and managed, often aligning with how software development teams build, release, and consume software binaries across an organization.

Repository structure is a fundamental foundation of secure, efficient artifact management practices. Your goal is to create the right structure that meets the needs of your developers.

Cloudsmith has an intrinsically flexible approach to repositories. We don’t force you to have a separate repository for each format type, like most other artifact management systems do. This presents you with an opportunity to define a more meaningful structure for your repositories, and this means you have many more interesting options!

We see some common patterns among Cloudsmith users that fall into the following groups:

We’ll be covering each structure in greater detail in our upcoming blogs as part of our Repository Structure Best Practices series.

Now that we’ve identified the “what” behind repository structures, we can dig into the “why” a little bit.

We address repository structure at the beginning of our onboarding process for new customers. If you get the repo structure wrong, then over time, artifact repositories can become a ‘dumping ground’ for all manner of software artifacts. When platform engineering teams are migrating to Cloudsmith, we find that there’s often a newfound interest in organization and consolidation of software artifacts, in order to ‘do better next time’ than they were able to with their legacy solution.

Perhaps the number one question we get at this point is, “How do we balance software supply chain security best practices with a great developer experience?”

While there isn’t really one simple answer to this question, the good news is that the flexibility Cloudsmith offers in choosing the repository structure can help you to check both boxes – security AND productivity.

Key benefits of the right repository structure

Choosing a clear, intuitive structure removes significant friction for developers. If they are able to easily locate the packages they need, pull the open-source dependencies for their builds in a central location, and integrate quickly with CI/CD pipelines, you’re winning as a platform team already.

Many enterprise customers of Cloudsmith leverage a dedicated repository for all ingress packages, where open-source dependencies are proxied and cached for developers and pipelines to begin accessing. This centralized repository makes it easy for developers to remember the direct path URL for pulling on their local machines and even easier for updating their CI/CD pipelines.

With our API and UI, a developer can quickly review what packages are within a specific repository. No digging through countless folders and subfolders to find what you’re looking for!

You’ll want your developers to be able to pull dependencies, create repositories, and configure upstream sources easily. But you also want to ensure developers are working securely. Repository structure directly influences how platform teams will be able to configure repository access controls, set permissions, review vulnerabilities, and inspect audit trails for suspicious signals.

In Cloudsmith, platform teams can restrict repository access by designating only specific developer teams to have access to specific repositories. At the permissions level, you can set read/write/admin permissions for each repository. This allows for granular access control, self-serve ownership, multiformat flexibility, and better visibility into team-by-team usage.

Observability and auditability of packages within your artifact management environment are directly correlated to how fine-grained your repositories are structured. The more segmented you configure them (i.e., by specific team, application, or environment), the clearer an observability team is able to view when a package was pulled and by whom. On the contrary, if an organization just has “non-prod” and “prod” repositories with many different service accounts and users pulling packages, it might be more difficult to pin down a specific action or event.

The right repository structure really impacts an organization’s CI/CD pipelines. When pipelines are tightly coupled to poorly structured repositories, the result can be pipeline failures due to ambiguous package resolution, security risks from pulling artifacts from the wrong stage, and even increased build times due to inefficiencies in caching.

As your organization grows, what originally worked for your first few developers will often break at scale. Without a flexible, scalable repository structure, you will quickly become susceptible to artifact sprawl, naming collisions, and access control issues. Cloudsmith’s fully cloud-native architecture helps enterprise customers scale tremendously while also maintaining order and consistency across repositories.

Managing Artifacts Across Multiple Formats

Your organization is building all kinds of software, with software development across many different language formats, development teams, and environments to consider. It helps to have an artifact management platform that can support multi-format repositories, flexible upstream configurations to open-source registries, and easy-to-use package tagging.

Balancing Security With Developer Velocity

Tighter security controls and a lack of freedoms can oftentimes frustrate developers, while open policies may create security gaps. A well-thought-out repository structure strikes a balance by allowing autonomy with clear guardrails. This is part of the developer “golden path” that can be architected by a platform team. 

How the right repository structure delivers business value

Faster Software Delivery & Reduced Operational Overhead

When artifacts are easy to find, manage, and deploy, your development teams spend less time figuring out where their artifacts are and more time building great software. Reducing toil and time to market is critical for any business creating software.

Improved Agility for New Development Teams

A well-structured repository architecture supports growth by paving the way for new teams – which may include contractors – to spin up new environments (repos, teams, service accounts, tokens, etc.) by enabling replication across teams. A clear, concise, repeatable structure that only requires a few API calls makes it easier to scale without worrying about the underlying infrastructure to support globally distributed teams.

Reduced Risk With Better Visibility And Controls

Platform teams are tasked with enabling development teams to write software efficiently and securely. By having a well-defined repository structure that every development team can follow, platform teams can create clear access control policies, artifact retention policies, and user permissions. Having this visibility and control lowers the risk of shipping insecure or unverified software.

Cloudsmith’s approach to repository structure

 is a trusted advisor, helping customers design and implement the optimal repository structure that balances security, scalability, and developer productivity to support their software delivery goals.

Stay tuned for the next part of the blog series, where we will discuss the “hybrid” repository approach that factors in an organization’s services, teams, and environments in Cloudsmith.

Why does repository structure matter for developers?

A clear repository structure saves time for developers by making it easy to find and pull the right packages. It also helps avoid confusion in CI/CD pipelines and improves overall productivity.

How does repository structure improve CI/CD pipelines?

When repositories are well-structured, pipelines resolve dependencies faster, reduce build failures, and pull the right artifacts for each stage (dev, test, prod) — making delivery more reliable.

How does repository structure affect security?

Repository structure impacts how access controls, permissions, and audit logs are managed. A good structure ensures that only the right people or services can access sensitive packages.

How does Cloudsmith support flexible repository structures?

 and supports multi-format repositories, fine-grained access controls, upstream proxying for open-source, and automation via API — making it easy to design the structure you need.

How do I choose the right repository structure for my organization?

The right structure depends on your scale, security needs, and workflows. Many teams use a hybrid approach, combining team, environment, and service-based structures for flexibility and control.

Why Repository Structure Matters

Over the past few years, Platform Engineering has gained traction as more enterprise organisations adopt the practice of creating centralised, self-service platforms that give developers easy access to the tools they need to focus on what they do best: building great software.

At the heart of every Golden Path lies the ability to reliably produce, store, and consume build artifacts, from container images to internal libraries. Without artifact management platforms, even the best developer workflows quickly break down under the weight of inconsistency and manual overhead.

If you haven’t already heard the term “Golden Path” in relation to Platform Engineering, you’re sure to encounter it along your journey through the modern software development ecosystem.

a preconfigured, paved road that provides an end-to-end workflow for developers, typically enabled via an Internal Developer Platform (IDP).

Without Golden Paths, each team is left to build their own workflows and pipelines from scratch. This results in:

: Teams reinvent the wheel, spending valuable time wiring up their CI/CD, security scans, and deployment steps instead of focusing on product work.

: With no shared templates, security, compliance, and operational practices become fragmented, which introduces risk and makes governance harder to achieve.

: Developers moving across teams face steep learning curves, as every team’s stack and practices are different.

: Introducing platform-level improvements such as security updates, new tooling, and organisation-wide polices become slow and error-prone because there’s no consistent delivery mechanism.

: Finally, without centralised artifact management practices, teams duplicate efforts, store untracked builds, and rely on manual conventions that lead to debugging nightmares and deployment inconsistencies.

Golden Paths addresses these challenges by providing a pre-defined, paved route for delivering software, backed by self-service templates, sensible defaults, and secure, reusable components. This self-service approach not only accelerates development cycles but also reduces cognitive load, promotes consistency, and allows developers to focus on building value rather than maintaining the infrastructure.

There is more to Golden Paths than just combining tools and services - it’s also about intentionally understanding the needs of your developers and crafting a path that will actually benefit the developer’s day-to-day tasks. Below are the core pillars of Golden Paths:

A golden path should empower developers to operate independently by providing automated, well-documented, and secure self-service tooling. This means developers can provision everything they need, such as infrastructure, repositories, pipelines, environments, and service templates, all without relying on manual interventions from platform, DevOps, or infrastructure teams. By reducing the need to open tickets or wait in queues, teams can move faster, experiment safely, and maintain momentum. This not only improves developer productivity but also reduces bottlenecks and operational overhead for supporting teams. A strong golden path makes the right way the easy way to self-serve by default and scalable by design.

Golden Paths should embed security, compliance, and governance controls directly into the desired developer workflow - automatically and invisibly. This means that secure defaults, access controls, audit logging, policy enforcement, and regulatory compliance are all baked into the tooling and templates provided. Developers shouldn’t have to worry about configuring these aspects manually or remembering compliance checklists afterwards. The golden path handles it all for your teams, reducing the risk of human error and ensuring consistency across teams. By baking these controls into the system instead of relying on external gates, golden paths help teams meet compliance or security standards by default, because it’s already handled in those paths.

Golden Paths should be highly repeatable and standardised, serving as the “blessed” or recommended approach to solving common problems. This consistency helps ensure that developers across different teams are using the same tools, patterns, and workflows, which reduces cognitive load, lowers onboarding times for new engineers, and minimises error or inconsistencies in implementation. By following a well-defined golden path, we avoid variation between teams and can instead focus on delivering value. We want to avoid repeatedly making the same foundational decisions.

Golden Paths are designed not just for individual use cases, but to operate reliably and efficiently at organisation-wide scale. This means the recommended patterns, tools, and platforms can handle high volumes of usage, large teams, and complex systems without degradation in performance or user experience.

For example, a Golden Path might define a standard CI/CD pipeline that includes automated testing, security scanning, and deployment to production. Rather than each team building their own version, hundreds of teams can adopt the same pipeline template, which is backed by a shared, scalable build infrastructure like Github Actions runners or a managed ArgoCD setup.

They should be resilient by default, fault-tolerant, and implement redundancy to ensure it performs consistently across geographies, teams and workloads. Whether deployed in a single region or across global environments, golden path solutions should maintain predictable reliability, ensuring fast feedback loops even under high load.

One of Cloudsmith’s own pillars, tooling is intuitive, fast, and well-documented so developers stay in flow and don’t need tribal knowledge.

Golden Paths require tooling that is flexible, secure, and invisible when it needs to be. Cloudsmith’s cloud-native, fully managed architecture supports Platform Engineering teams in building paved roads with minimal friction.

Where and how Cloudsmith enables Golden Paths

Now that we’ve covered each of the core pillars, let’s explore how Cloudsmith best enables Golden Paths:

Cloudsmith’s architecture was designed from the ground up to prioritise speed and simplicity. These are core pillars of Golden Paths. There’s no need to manage infrastructure, patch servers, or wrestle with upgrades.

With a streamlined golden path, developers can:

Create and manage artifact repositories for multiple formats

Configure upstream proxies for public dependencies

Create, manage, and rotate Entitlement Tokens

Create and manage service accounts with OIDC

Bootstrap a full microservice project with a dedicated repository with upstream proxy

This self-service approach makes it easier for Platform teams to build repeatable workflows that scale across dev squads. Next we’ll look at how Cloudsmith’s multi-format repositories make automation easier while improving self-service for developers. They’re a perfect fit for how we scale our internal platform and support modern delivery workflows.

At a high-level, Cloudsmith allows businesses to host all supported package types in a single repository (npm, Docker, Python, Maven, NuGet, Ruby and more) without sacrificing compatibility with native tooling. This flexibility opens a door to unified, scalable, and an automated approach to artifact management.

This enables flexible repo structures where platform teams can organise based on environment (such as dev, staging, prod), product lines, teams, or any kind of structure that fits your workflow, without being constrained by package formats. The very nature of centralising artifacts allows teams to monitor, and more importantly audit all formats from a “single source of truth” with detailed stats, versioning, tooling compatibility and entitlement token controls.

Cloudsmith Blog

Layered defense for dependencies: Why dependabot needs an upstream gatekeeper

Access control & permissions for multi-format repositories

The Hybrid Repository Structure: Balancing Control and Flexibility

Why Repository Structure Matters

Golden Paths Made Easy With Cloudsmith