By submitting this form, you agree to our 

 is right around the corner, and there are 11 clear new Python Enhancement Proposals (PEPs) added to the Python project! There are several over significant changes listed within the 

Python 3.14 brings a whole bunch of useful build improvements, including discontinuation of PGP signatures in 

. Python versions 3.14 and onwards will no longer provide PGP signatures for release artifacts. Instead, Sigstore is recommended for verifiers. Similarly, free-threaded mode (

), which was introduced in the previous version, 3.13, has undergone major enhancements. The implementations outlined in this enhancement are now complete, incorporating updates to the C API, and the interpreter’s earlier temporary fixes have been replaced with long-term solutions.

The Cloudsmith team is really excited about this release and everything that comes with it! Note that some of the statuses may change between the time of this blog being posted and the final release date. Knowing that, let’s jump into all of the new features and improvements in Python 3.14.

Here are a few of the changes that Cloudsmith employees are most excited about in this release:

PEP 761: Discontinuation of PGP signatures

“From my perspective at Cloudsmith, the move away from PGP signatures in Python is a welcome change. PGP has long struggled with usability and the burden of managing long-lived private keys, and while it was the default for artifact signing, it never felt ideal. Sigstore offers a much more practical approach, using short-lived keys tied to human-readable identities, and it’s already gaining traction across ecosystems like PyPI, NPM, Homebrew, and GitHub. We’re also seeing projects we work with, like 

, embracing Sigstore, which reinforces that this shift is a real step forward for security and usability.”

PEP 734: Multiple interpreters in the stdlib

“This was an inevitable development, in my opinion. While the CPython runtime has supported running multiple interpreters, which are independent copies of Python within the same process, for well over 20 years at this point, the feature was still limited to the C-API and thus saw little adoption due to low awareness and the absence of a standard library module. With Python 3.14 introducing the new 

 module, this long-standing capability is finally becoming more accessible, marking a significant step toward mainstream usage. While current limitations remain, their impact will diminish as CPython evolves and the community contributes solutions via 

PEP 784: Adding Zstandard to the standard library

“Python 3.14’s addition of Zstandard (via 

) is an exciting upgrade because it brings one of the fastest, most efficient modern compression algorithms directly into the standard library, alongside a new unified 

, consistently outperforms older formats like 

 by offering both higher compression ratios and dramatically faster decompression speeds, which has made it the de facto standard across filesystems, packaging tools, and industry at large.

By including it natively, Python eliminates the confusion of multiple third-party bindings, enables direct support in core modules like 

, and opens the door for faster, smaller Python wheels and other packaging improvements. The reserved 

 namespace not only avoids naming conflicts with PyPI packages but also creates a clean, future-proof home for compression libraries, much like 

 does for hashing. This change reflects Python’s “batteries included” philosophy while giving developers a state-of-the-art compression tool that is both practical today and well-positioned for long-term usage.”

Free-threaded Python is now officially supported

 this enhancement proposal, which actually sets requirements for advancing 

, which was the larger, ongoing effort to make Python’s 

) optional. PEP 703 outlines a three-phase plan:

First phase introduces an experimental GIL-free build in Python 3.13

Phase two makes this build officially supported - though still optional

While Phase 3 makes it the default. 
This new feature defines the expectations for the second phase, ensuring the free-threaded build is stable, usable, and performant enough for broader adoption.

The motivation behind this shift is to balance the benefits of free-threaded Python, which offers greater concurrency, reduced latency, and expanded threading capabilities against costs such as performance penalties, memory overhead, and ecosystem complexity. Current benchmarks show around a 10% slowdown and 15-20% more memory use compared to the traditional GIL build, both considered acceptable trade-offs for Phase 2.

The APIs introduced so far have proven stable, and further refinements are expected without breaking changes. With growing third-party support and clear criteria for performance, memory use, documentation, and API stability, Python 3.14 is targeted as the point where free-threaded Python becomes an officially supported build.

Standard Library Support for Isolated Python Interpreters

Python 3.14 sees the addition of a new standard library module, 

, to expose CPython’s long-standing support for multiple interpreters in a single process. Each interpreter is strictly isolated, with its own modules, classes, and variables, while sharing only certain immutable or low-level process state. Unlike threads, which share most of the same runtime state, interpreters provide stronger isolation, making them better suited for parallelism, especially now that 

The new module will provide a high-level interface for creating, inspecting, and executing code in interpreters, as well as managing communication through a built-in, cross-interpreter-safe 

. This brings powerful functionality, previously limited to the C API, into Python code. An additional 

concurrent.futures.InterpreterPoolExecutor

 will be provided to simplify concurrent workloads.

The interpreters module defines an Interpreter object with methods like 

 to initialise globals. Interpreters can safely exchange data using 

, which supports pickle-based transfers and special handling for buffer objects like 

. This queue acts as a synchronisation and communication mechanism, enabling patterns like worker coordination across interpreters. For example, the below snippet taken from the PEP documentation shows multiple interpreters sharing a 

 of large data, synchronised with a queue token:

Making Parentheses Optional in Except and Except Blocks

 blocks in Python, users can now catch multiple exception types, so long as the “

” operator clause is not used. Currently, parentheses are mandatory around multiple exception types, a requirement carried over from Python2.

Removing this requirement simplifies the syntax, improves readability, and makes it more consistent with other comma-separated constructs in Python, such as function arguments and tuple literals. Parentheses will still be required when using as to capture the exception instance to avoid ambiguity. The change is purely syntactic, fully backwards compatible, and does not alter exception handling semantics.

Deferred Evaluation Of Annotations Using Descriptors

Python annotations let developers attach type information and metadata to functions, classes, and modules. Traditionally, annotations were evaluated eagerly when the object was defined, which led to common problems with forward references and circular dependencies. 

 attempted to fix this by “stringizing” annotations (storing them as strings), solving the forward-reference issue but breaking runtime use cases where actual objects were expected instead of strings.

A new proposal introduces a third, more flexible approach: lazily evaluating annotations through a dedicated 

 method. At compile time, Python generates a helper function that constructs the annotation dictionary, then attaches it to the object as 

. Accessing these annotations triggers this function, evaluates the annotations only when needed, and caches the results. This design eliminates circular-reference issues, preserves runtime usability, and allows for new introspection capabilities. Furthermore, 

 gain a new format parameter, letting users choose between evaluated values, forward-reference proxies, or source-code strings for annotations.

Here’s a simplified illustration of how this lazy evaluation model works:

With this change, annotations retain their runtime meaning while still avoiding forward-reference pitfalls, which supersedes the enhancement #563 string-based approach mentioned earlier, as well as offering a unified solution for both static and runtime use cases.

Safe external debugger interface for CPython

This introduction of a zero-overhead debugging interface for CPython should allow debuggers and profilers to safely attach to running Python processes. By providing well-defined safe execution points within the interpreter’s evaluation loop, external tools can request code execution without modifying normal execution or introducing runtime overhead.

This mechanism enables scenarios like attaching pdb to live processes by PID, similar to 

, allowing developers to inspect, evaluate, and step through running Python code interactively without stopping or restarting applications. Current approaches to live debugging in Python are risky because they rely on unsafe code injection, which can execute at arbitrary points in the interpreter, leading to crashes, memory corruption, or deadlocks. By integrating a small support structure into each thread state and extending the debug offsets table, this proposal ensures that debugging code is executed only when the interpreter is in a consistent and safe state.

The interface works by having debuggers write control information, such as the path to a Python script, into dedicated memory locations in the target process. The interpreter checks for pending debugger requests at existing safe points (via the 

), executing the provided code without interrupting critical operations like memory allocation or garbage collection.

 API simplifies remote execution for external tools, while environment variables and build flags allow redistributors and administrators to disable the feature if desired. Multi-threaded considerations are handled naturally: injected code runs under the normal GIL, ensuring thread safety, and can target individual threads or all threads as needed. This approach aligns Python with other major languages in live debugging capability while maintaining safety and zero runtime overhead during normal execution.

Deprecating PGP signatures for CPython artifacts

Again, this PEP isn’t merely a deprecation announcement. Instead, we see the introduction of an entirely new security model through Sigstore. Since 

, CPython artifacts have been signed with both PGP and Sigstore. PGP relies on long-lived private keys, which release managers must maintain and protect for many years, creating ongoing risks and burdens. In contrast, Sigstore uses short-lived keys tied to human-readable identities via OpenID Connect, greatly simplifying the signing process while providing stronger ergonomics. Sigstore is already gaining wide adoption across ecosystems like PyPI, NPM, Homebrew, and GitHub.

This new feature will not only deprecate, but will eventually discontinue the PGP signatures for CPython altogether, transitioning fully to Sigstore. Current stable releases (3.11 through 3.13) will continue offering PGP signatures until end-of-life, but new release managers (starting with Python 3.14) will not be required to generate them. Maintaining dual systems has slowed adoption of newer methods, creating a “

” that discourages verifiers from moving forward.

By dropping PGP, CPython can encourage downstream ecosystems to fully adopt Sigstore, while still providing flexibility for extraordinary delays if needed. Though this change shifts reliance to Sigstore’s centralised infrastructure, it aligns with the security practices already expected of release managers and leverages services better suited for long-term key management. Documentation will guide integrators, such as Linux distros and package managers, on verifying artifacts with Sigstore.

Disallow return/break/continue that exit a finally block

Nigel Douglas

Head of Developer Relations

Python 3.14 – What you need to know 

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.

Cristian Garcia

Senior Customer Success Manager

Why Repository Structure Matters

Regulatory compliance in the software supply chain is a moving target that shifts with every dependency, security advisory, and regulatory update. Cloudsmith’s EPM puts control back in your hands by enabling development and operations teams to create real-time policy enforcement, right where it matters: at the package level.

By leveraging OPA and Rego, EPM lets you define precise, programmatic policies that determine how packages are evaluated, tagged, or quarantined before they’re ever promoted downstream. That means compliance policy enforcement is built directly into your distribution pipeline rather than being left to chance, or worse, post-release audits.

For development teams out there, the last thing we want to do is slowing you down with red tape security features. We want to help shift compliance left in the supply chain so issues are caught early, consistently, and transparently. Whether it’s blocking unlicensed packages, quarantining vulnerable builds, or ensuring artifacts meet naming conventions, EPM ensures that policies are applied automatically and uniformly through your own unique policy-as-code configurations.


Copy-Left policy that matches license strings

This policy is important from a compliance perspective because the use of 

 in production environments can create significant legal and operational risks if not properly managed. Many of these licenses impose obligations, such as requirements to disclose source code, distribute derivative works under the same license, or provide attribution, that may in some cases be incompatible with an organisation’s business model, intellectual property strategy, or contractual commitments.

By proactively detecting both free-text and standardised System Package Data Exchange (

) variants of these licenses, the policy ensures that potentially problematic code is flagged before it reaches production, enabling the necessary legal review or approval. This not only reduces the risk of inadvertent license violations but also demonstrates due diligence in open-source governance, which is often a key expectation in audits, customer contracts, and regulatory environments.

The license trigger conditions are highlighted in our detailed schema which is available towards the bottom of 

 v.3.1.1 package that we know has a GNU Lesser General Public License (

) license that should trigger the policy:

 If you have a tagging response action attached to your policy, you could tag the package with 

This policy checks whether a package includes specific 

 descriptors in the filename. This could be the simplest way for an organisation to state whether a package is a debug package, and therefore should not be ingested into, say, the 

The policy will trigger on these kind of wildcard examples:


Cloudsmith EPM allows users to easily match package filename metadata based on Regular Expression (RE) string matching patterns. Once ready, you can download the 

 Python package and push it to Cloudsmith to cause the policy violation:

From a compliance perspective, preventing debug, test, or temporary builds from entering production is critical because these artifacts often contain unverified code, verbose logs, or experimental features that were never intended for public release. If deployed, they may expose sensitive internal information, introduce security vulnerabilities, or degrade system performance, any of which can result in regulatory noncompliance, contractual breaches, or audit findings. Enforcing this control at the ingestion point ensures that only vetted, production-ready packages flow downstream, reducing the likelihood of costly incidents while demonstrating due diligence in software governance.

The use of RegEx strengthens this control by providing a highly adaptable mechanism for detecting noncompliant naming conventions across diverse development and CI/CD practices. Instead of hardcoding rigid checks, RegEx allows compliance teams to define broad yet precise patterns that evolve alongside the organisation’s software ecosystem. This flexibility enables policy enforcement to remain effective without creating excessive operational overhead.

This policy exists to ensure that packages coming from upstream sources are explicitly reviewed and marked as "

" before being allowed to proceed in the pipeline.

You could think of this as an advanced use-case for tagging. When both conditions are true, the policy will trigger. Note: There is also a commented-out condition for restricting it to specific repositories, if you’d prefer to whitelist certain repositories that are not under the same level of regulatory scrutiny.

From a compliance perspective, this policy enforces a controlled workflow for handling externally sourced or upstream packages, which are often beyond the direct control of the security team. By requiring an explicit "

" tag before these packages are considered safe, it creates a checkpoint where security, licensing, and quality reviews can be performed. This helps prevent unverified or potentially malicious code from entering production systems. It also encourages consistent documentation of the approval process, which can be important for compliance frameworks such as SOC 2, ISO 27001, or internal governance policies.

From a risk management perspective, the policy reduces the chance of introducing vulnerabilities, licensing conflicts, or compatibility issues from upstream sources. Operationally, it gives teams the flexibility to integrate valuable external software while maintaining a robust safeguard against unvetted changes. Over time, this approach can significantly improve software supply chain security, maintain regulatory compliance, and protect the organisation’s reputation by ensuring only reviewed and trusted packages make it into critical environments.


 architecture packages and blocks others like 

To trigger the above policy (which blocks all architectures 

), you'd want to upload or sync a Python package that is built for a 

 architecture - like arm64. However, pip by default fetches packages built for your local system architecture, so you typically won't download architecture-specific wheels unless they're explicitly tagged.

This architecture-specific allow list policy plays a critical role in compliance by ensuring that only packages built for the approved amd64 architecture are permitted in production and testing environments. In organisations standardised on x86-based servers, containers, and CI/CD pipelines, introducing packages built for other architectures, such as the case with arm64, can create hidden risks such as runtime failures, inconsistent behaviour across platforms, or the inability to reproduce builds reliably.

From a compliance perspective, these risks undermine key principles of software assurance, reproducibility, and auditability, all of which are essential for demonstrating control over the software supply chain. Blocking non-amd64 packages at enforcement ensures that software deployed downstream aligns with documented infrastructure baselines, reducing the likelihood of noncompliant system configurations.

Additionally, different architectures may introduce unique vulnerabilities, require distinct patching procedures, or fall outside the scope of validated security tools and compliance checks. Allowing multiple architectures without proper governance complicates vulnerability management, weakens evidence for audit trails, and can create gaps in regulatory coverage. By restricting deployments to a single, vetted architecture, this policy simplifies compliance verification, strengthens the integrity of vulnerability scanning, and provides assurance that all deployed software is consistent with approved security and operational standards.

Build your own compliance policies with Cloudsmith EPM

These four examples illustrate just a handful of the ways Cloudsmith EPM can be applied to enforce regulatory compliance across your software supply chain. From licensing governance to architecture restrictions, debug-build quarantines to upstream approvals, each policy demonstrates how compliance controls can be codified, automated, and enforced consistently.

But this is only the beginning. Because EPM is powered by OPA and Rego, it offers almost limitless flexibility to address the unique compliance challenges your team is facing. Whether you’re aligning with industry standards like ISO 27001 or SOC 2, meeting customer contract requirements, or simply reducing operational risk, you can design policies as code that fit your exact environment.

The power lies in treating compliance as part of your pipeline rather than an afterthought. With Cloudsmith EPM, you can move fast without breaking trust, ultimately ensuring that every package that flows downstream has already been checked, validated, and approved against the rules that matter most to your business. Check out our official documentation on how to 

Compliance policies in EPM

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.

Security shouldn’t slow you down - and with Cloudsmith, it doesn’t.

Golden Paths can bake governance into the developer experience, enabling teams to move fast without bypassing standards. Rather than embedding artifact verification logic inside individual pipelines (which quickly becomes unmanageable at scale), platform teams can use Enterprise Policy Management (EPM) to abstract these controls into centrally managed, observable policies as code.

For example, rules about which artifacts can be ingested - based on origin, signature, license type, or vulnerability status - can be codified as reusable policies, enforced consistently across all teams and environments. These policies are versioned, auditable, and deployable via Terraform, just like the infrastructure that serves the artifacts.

With Cloudsmith, teams can also enforce fine-grained RBAC, set global privileges, apply OIDC-based auth scopes, and define deny-by-default rules that can be codified without the need for manual setup. The result: every team benefits from hardened defaults and automated compliance without having to write custom pipeline logic or wait on security tickets.

This means every team follows the same standards - with no extra work required.

Golden Paths depend on tools that fade into the background: tools developers barely notice because they “just work.”

Most of our customers interact with Cloudsmith through our developer-friendly CLI, language-native tool support (e.g. npm, twine, docker), or API-first workflows. However, when the UI is needed, it matters, and Cloudsmith delivers a clean, unified, format-agnostic interface that developers actually enjoy using.

No more clunky dashboards or having to consult internal wikis just to navigate a repository. Cloudsmith’s UI reflects the same principles as a great platform: clarity, consistency, and control.

Golden Paths are only golden if they work for every team, wherever they are.

Cloudsmith delivers artifacts via a powerful, CDN-backed architecture with global edge caching, so developers around the world experience the same speed and reliability. Whether developers are pulling containers, Helm charts, or Python wheels, the experience is consistent and fast, without the need for custom cloud infrastructure or replication setup.

Customer success story through Golden Paths

One of our enterprise customers, a global semiconductor and signal‑processing leader, has implemented multiple Cloudsmith‑powered Golden Paths to streamline onboarding for development teams. Using a combination of our 

, they created self‑service workflows that provision Cloudsmith repositories, teams, service accounts, and OIDC configurations in minutes.

Currently, we’re helping them automate token rotation and upstream source creation for open‑source dependencies with streamlined self service cards in Backstage, which further reduces manual effort and boosts developer productivity. This customer is just one of many who are taking advantage of Cloudsmith’s global scale to meet the needs of their developers.

Cloudsmith Blog

Python 3.14 – What you need to know

Why Repository Structure Matters

Compliance policies in EPM

Golden Paths Made Easy With Cloudsmith