By submitting this form, you agree to our 

Answer twenty questions about your artifact and supply chain practices. Get a custom report card showing your maturity score against key regulatory and compliance frameworks.

Artifact Security Maturity Assessment

 is scheduled for release on August 26th 2026, and it’s full of really exciting updates for security, DRA, networking and more! We exclude enhancements with the status of “

. What are we looking forward to in Kubernetes 1.37?

The 1.37 release includes 

’ in this Kubernetes release. From these, just 

 enhancement for DRA now graduating to GA.

A long list of 

 enhancements are in the tracker, including the ability to connect to a localhost NodePort service on NFTables (IPv4 & IPv6) using a userspace proxy (

 flag being added to StatefulSet rolling update strategies (

).

As always, let’s jump into all of the major graduations, deferred enhancements and deprecations scheduled for Kubernetes 1.37.

Here are a few of the changes that Cloudsmith team are most excited about in the 1.37 release:

#6072 Standard numaNode device attribute for DRA

Kubernetes 1.37 introduces the standardisation of 

) as a globally recognised DRA device attribute. I’m excited to see this Alpha enhancement in 1.37. It unifies how hardware-specific memory topologies, like the memory controller, are exposed alongside existing attributes like 

. By establishing a single, consistent naming convention and introducing specialised helper functions into the 

 library, Kubernetes users should now be able to achieve seamless, cross-driver co-placement and advanced attribute matching (

 hardware configs where PCIe topologies alone were insufficient. Moving this complexity out of custom code and into a native standard means platform teams can finally guarantee high-performance, low-latency hardware alignment with absolute, cross-cloud portability.

Nigel Douglas - Head of Developer Relations




#5758 Per-container ulimits configuration

I am incredibly excited to see this enhancement land in Kubernetes 1.37 because it finally tackles a long-standing headache for anyone running heavy, production-grade workloads. This new KEP introduces a 

 within the Pod API. This grants users fine-grained, per-container control over 

 resource limits (such as open files and process counts) on Linux nodes. This native support eliminates the need for brittle, non-portable workarounds like modifying host configs or custom entrypoint scripts, allowing high-concurrency workloads and databases to optimise performance securely and in a scalable way in multi-tenant clusters. This change will propagate these limits directly to container runtimes via the CRI, utilising a runtime handler to dynamically detect node support. For years, platform engineers have had to jump through hoops just to prevent too many file open errors. Finally bringing this natively into the Pod API is a massive win for cluster security.

Jason Myers - Technical Content Marketer



#1710 Speed up recursive SELinux label change

) graduating to stable is great from a security standpoint. It fundamentally changes how volumes are attached to containers on systems with SELinux in enforcing mode. Traditionally, the container runtime had to recursively relabel every individual file and directory on a volume before a Pod could even start - a process that was notoriously slow for massive datasets, error-prone on near-full disks, and impossible on read-only filesystems. By switching the default behaviour to leverage the Linux kernel's native “

“ mount option, Kubernetes can now instantly assign the correct SELinux label to an entire volume at the mount point without a time-consuming file-system walk. While this drastically accelerates Pod startup times, its truest impact is defensive. By eliminating the need for the container runtime to dynamically change file permissions on the fly, this enhancement effectively blocks host-path exploitation techniques (like 

) where an attacker attempts to trick the cluster into relabelling and exposing critical host files.

Add Recreate Update Strategy to StatefulSet

 for StatefulSets addresses a long-standing 

 that has plagued users for years. Previously, if a StatefulSet update was triggered with a broken config (such as a non-existent Docker image), the controller would wait indefinitely for the failing Pod to become 

 before proceeding. Even if a user reverted the config to a known-good state, the StatefulSet would refuse to manage or fix the broken Pod because it was stuck in a validation loop, forcing users to manually delete the Pod to unblock the controller.

The new 

 strategy provides a more aggressive alternative to the standard 

. It allows the StatefulSet controller to prioritise reaching the desired state by terminating existing Pods before creating new ones, effectively bypassing the waiting for ready deadlock. This change transforms what was previously documented as a known issue into a manageable configuration, ensuring that automated pipelines can recover from misconfigurations without manual human intervention.



WAS: Integrate Workload APIs with Job controller

 sig-apps

The enhancement is a major step forward for native support to complex batch and AI/ML workloads. Historically, Kubernetes scheduled individual Pods independently, which caused issues for distributed training jobs that require all participants to start simultaneously (

 object to act as a link between high-level controllers (like the Job controller) and the scheduler. By integrating these, the Job controller can now automatically generate a Workload representation of itself, allowing the scheduler to understand the resource requirements and scheduling constraints of the entire group of pods rather than treating them as isolated units.



 sig-apps

This enhancement introduces a 

 parameter (either an absolute number or a percentage) to the 

 strategy for Kubernetes StatefulSets. Currently, StatefulSet updates are limited to processing one pod at a time, which can severely slow down rollouts for large clusters or applications with long startup tasks. By allowing multiple pods to be updated simultaneously, this feature brings StatefulSets closer to feature parity with Deployments, enabling significantly faster rollout times for stateful clustered applications that can tolerate having multiple replicas or followers offline at once.

 sig-api-machinery

This enhancement seeks to optimise the 

 performance and simplify its codebase by eliminating the resource-heavy, traditional internal API types (

) that act as conversion and validation hubs. Because many APIs have matured to a stable v1 version, maintaining these distinct internal types is no longer necessary and incurs significant CPU, memory, and maintenance overhead during request processing and large list operations. The project will execute in two phases. First, it makes internal types memory-identical to preferred versioned types to achieve up to a 

 during conversions. Secondly, it replaces internal types entirely with Go type aliases before eventually removing them altogether.



 sig-api-machinery

This enhancement proposes enabling the 

 feature gate by default to resolve severe API server scaling and timeout issues during CRD version migrations. Currently, when a controller establishes a watch on a cold cache, the 

 fetches the stored CRD versions from etcd and converts them sequentially to the requested version before returning them. At high scale (like, with clusters over 10,000 workloads running Kueue), this sequential conversion process can take several minutes, triggering etcd timeouts and causing the API server to fail with 500 errors. Enabling this feature by default allows the API server to decode and convert these watch events concurrently, drastically reducing processing time and preventing cluster failures during large-scale version upgrades.



 sig-api-machinery

Added in v1.35 as beta (disabled by default), the in-tree Storage Version Migrator (

) controller within the Kube-Controller-Manager (

) is finally graduating to stable in v.1.37. This KEP simplifies and automates data rewrites for at-rest storage. Resource rewrites are essential when a preferred storage schema changes (like 

) or when encryption-at-rest keys are updated. Unfortunately, performing this manually via kubectl is error-prone and scales poorly. By migrating the original out-of-tree SVM migrator controller into the core codebase under a new 

 API group, this proposal allows users to easily trigger efficient data migrations utilising the garbage collection cache. Once a migration successfully completes, the controller also handles updating the CRD status to safely remove references to old, unused storage versions.



 sig-api-machinery

This proposal introduces support for the 

 data format in Kubernetes API servers and clients as a high-performance alternative to JSON. While native Kubernetes resources use 

 to minimise CPU time and heap churn, CRDs cannot easily use Protobuf due to its reliance on compile-time code generation. Adopting CBOR as a self-describing binary format solves this gap. The benchmarks show it can make custom resource encoding up to 

. The rollout includes standard content negotiation (

), support for streaming via CBOR sequences, and client-side feature gates with automatic JSON fallbacks to ensure seamless backward compatibility with older API servers.

 sig-cli

I mentioned back in the 1.34 release how the introduction of KYAML will 

. Finally graduating to Stable status in the 1.37 release, KYAML is a Kubernetes-compliant YAML output format that uses a specific subset of standard YAML (called flow style) that eliminates common syntax pitfalls. By always using curly brackets 

 quotes for strings, it removes whitespace sensitivity and type-coercion bugs while still allowing comments and trailing commas. This will definitely improve the overall reliability of Kubernetes going forward.

Allows setting any FQDN as the pod's hostname



, allowing users to set any arbitrary FQDN up to 64 bytes as a pod's hostname. Aimed at easing the migration of legacy applications (like Kerberos) that relied on specific hostnames for authentication or permissions, this feature bypasses default cluster-suffix restrictions and writes the custom FQDN directly to the pod's 

 file (excluding Windows containers). To mitigate kernel limits, validation will reject strings over 64 bytes or those violating RFC 1123 standards, and the field is strictly mutually exclusive with 

 sig-network

Graduating to Stable in 1.37, this relaxed ServiceName validation feature is an improvement designed to bring the naming constraints of Service resources into alignment with other standard Kubernetes objects. Historically, Services were restricted by a stricter 

), which prohibited names from starting with a numeric digit. This update transitions the validation to the more flexible NameIsDNSLabel standard, finally allowing users to create Services with names like 

localhost NodePort userspace proxy for NFtables



 sig-network

This net new enhancement introduces an opt-in userspace TCP proxy to the 

 kube-proxy backend. This proxy bridges a critical feature gap by allowing workloads to access NodePort services via localhost (IPv4 and IPv6) under nftables. This is a capability that currently exists for 

 equivalent. Activated explicitly via the 

 flag, this Layer 4 forwarder supports key features like 

 external traffic policies, while intentionally excluding non-TCP protocols (UDP/SCTP) and leaving the iptables and IPVS backends completely unchanged.



Make NFtables the default kube-proxy backend



 KEP mentioned above, Kubernetes 1.37 is laying the groundwork to eventually make 

 the default backend for kube-proxy. This will ultimately replace the older 

 systems entirely. Because this shift requires newer Linux kernels (version 5.13 or higher) and continuous stability testing, the 1.37 release focuses on preparing users rather than making an immediate switch. Starting in this version, Kubernetes will actively issue log warnings to clusters that rely on the default 

 setting, advising administrators to either explicitly lock in 

 before the official default switch occurs in 

. This all culminates with the removal of IPVS mode in kube-proxy (

 sig-auth

Graduating to beta, this enhancement aims to solve a long-standing issue where a resource that cannot be decrypted or decoded completely blocks Kubernetes API operations like 

 storage to fix it. The proposal introduces more informative retrieval error messages to pinpoint the broken data, along with a new 

 that allows admins to bypass storage checks and safely delete malformed resources directly through the K8s API. While this simplifies recovery in scenarios like lost encryption keys or stuck namespace deletions, it’s worth noting that forcefully deleting a broken resource will bypass finalisers and garbage collection, potentially leaving behind orphaned underlying processes.



 sig-auth

Graduating to stable, this enhancement introduced a secure and automated mechanism to deliver X.509 certificates directly to pods without using bearer tokens, which helps preserve the integrity of mTLS auth. It establishes two key components: a 

 API specifically for pod certificate issuance, and a 

 projected volume source that lets the kubelet provision keys and certs automatically. By shifting the responsibility of enforcing node security boundaries to the K8s API-Server, this mechanism makes it significantly easier and safer for both in-tree and third-party tools (like HashiCorp Vault) to issue client and server certificates via standard 

), a new cluster-scoped Kubernetes API designed to safely distribute X.509 trust anchors (root or intermediate certificates) to workloads. Previously, clusters relied on clumsy workarounds like copying a 

 into every namespace or hardcoding static CA certs.

To complement this, a new kubelet projected volume source allows workloads to easily consume these trust anchors directly from the container's filesystem, automatically updating them on the fly during certificate rotations without requiring application restarts.


 sig-node

This enhancement extends the Pod API to now support Pod-level resource requests and limits (specifically for CPU, memory, and hugepages) alongside existing container-centric settings. By allowing tightly coupled containers within a pod to share a unified resource pool, this feature simplifies resource management and eliminates the need for meticulous, per-container configs. Ultimately, this change enables dynamic intra-pod resource sharing, which reduces waste, improves overall resource utilisation, and better accommodates workloads with unpredictable or bursty demands.



Enable Writable cgroups for unprivileged containers

 sig-node

Introduced as an Alpha stage feature in 1.37, we’re seeing a new 

. This enhancement allows unprivileged containers to securely manage and write to their own sub-cgroups, providing fine-grained resource control directly through the Kubernetes API instead of relying on broad, less-secure runtime-level configurations.



 sig-node

Graduating to stable in 1.37, the proposed Node Declared Features framework allows Kubernetes nodes to dynamically advertise their active, feature-gated capabilities directly to the control plane. By exposing these features, components like the scheduler and admission controllers can automatically manage version-skew issues. This includes activities like ensuring pods are only scheduled on compatible nodes and blocking unsupported API operations, all without requiring users to manually configure complex taints, tolerations, or node labels.



 sig-node

Kubernetes 1.37 introduces a native 

 and the CRI. This allows users to configure fine-grained POSIX resource limits (like open files and process counts) per container, ultimately eliminating the need for host-level workarounds that could otherwise cause issues. To maintain system stability and cluster security, the proposal restricts the feature to the privileged (

) level, enforces strict validation, and even integrates with newly-graduated node-declared features to ensure pods requiring custom limits are only scheduled on compatible nodes.

 sig-node

By allowing drivers to specify at the 

 level that node-local setup is unnecessary, the kubelet can bypass standard gRPC preparation and unpreparation calls. This bypass speeds up the container lifecycle, allowing container startup & termination to proceed immediately for supported devices.



Resource Claim Status with possible standardised network interface data



 sig-node

Graduating to stable in 1.37, this KEP introduces a new 

 API. This allows DRA drivers to report arbitrary, driver-specific status data, such as operational conditions and standard networking details (IPs, MAC addresses, and interface names) directly to the resource claim. The enhancement improves observability, simplifies troubleshooting, and enables third-party controllers to integrate allocated resources into higher-level network services.



 sig-node

This framework-assisted method exposes DRA device metadata like PCIe addresses and mediated device UUIDs directly to workloads via standard JSON files mounted using the Container Device Interface (

). By allowing DRA drivers to populate a metadata field (either immediately during resource preparation or deferred via NRI hooks during sandbox creation), the framework automatically handles file generation, directory structuring, and container bind-mounting. This design provides proper container-level isolation per resource request, ensures backward compatibility, and eliminates the need for complex, error-prone custom controllers currently required by workloads like 

Scheduler Preemption for In-Place Pod Resize



 sig-scheduling

Updating the Kubernetes Scheduler to automatically actively create space for Deferred In-Place Pod Resizes by preempting (or evicting) lower-priority pods on fully-utilised nodes certainly aligns the behaviour with the preemption logic used for newly created pods. Currently, in-place resizes that exceed a node's capacity do not trigger preemption, resulting in deferred status and requiring manual intervention or risking disruptive external controller behaviours (like OOM-kills or node rescheduling). While the proposal aims to automate resource scaling and reduce workload disruptions, it intentionally keeps broader scheduling tasks (like binding) out of scope and highlights key risks, such as performance overhead from deferred pod queues, double-preemption during scheduler restarts, and the potential for over-preemption. This will all be addressed using aligned resource-fit calculation logic by Beta.



 sig-scheduling

Graduating to Stable in 1.37, this enhancement introduces device taints and tolerations to DRA. This improvement mirrors the existing node taint model to handle hardware issues gracefully. By applying taints via DRA drivers or user-defined 

, clusters can block new pods from scheduling onto degraded or offline hardware (

) or evict currently running pods for maintenance (

). Users can bypass specific taints by adding matching tolerations directly to their 

. This allows workloads to run on degraded devices or during testing at their own risk. All while informational taints can be published for hardware monitoring without altering scheduling.



 sig-scheduling

To eliminate the rigidity of exact attribute matching across different hardware vendors, this net new improvement introduces 

 to DRA. By evaluating scoped CEL expressions on candidate devices to synthesise virtual grouping keys, users can easily pair GPUs and NICs without waiting for vendors to standardise attribute names. Here’s a quick sample of bridging disparate schema within the 

Speed up recursive SELinux label change



 sig-storage

Graduating to Stable in the 1.37 release, speeding-up SELinux volume mounting by replacing the slow, recursive file-by-file relabelling process with the Linux 

 mount option is a huge improvement. This change applies the required SELinux context to an entire volume at once. Having been rolled out across Kubernetes 1.36 and 1.37 through feature gates like 

, the new default applies context mounting automatically while providing opt-out mechanisms (

) for edge cases that rely on traditional recursive relabelling.



 sig-storage

This Beta improvement proposes extending the Kubernetes 

 plugin to score nodes during dynamic persistent volume provisioning based on available storage capacity. Users can configure this global policy to either prioritise nodes with the most free space (the default, to allow for future volume expansion) or nodes with the least sufficient space (to pack workloads and reduce node count/costs).



Add user fields to atomic write volumes



 sig-storage

Graduating to Alpha in 1.37, we’re seeing optional 

) to allow setting custom owner UIDs on mounted files. This solves a long-standing issue for apps with strict file-ownership requirements (like MongoDB or SSHD) that currently default to root ownership. It’s also worth noting it enables non-root pods running under restricted security policies to set correct file permissions without needing privileged 

Configurable tolerance for Horizontal Pod Autoscalers



 sig-autoscaling

The Horizontal Pod Autoscaler (

) currently uses a fixed, cluster-wide default tolerance of 10% to prevent rapid scaling churn - called "

". Unfortunately, this is a global setting and is often too coarse. Especially for large or sensitive workloads where minor percentage shifts represent hundreds of pods or delay critical scale-ups. This KEP adds an optional, per-HPA tolerance field (within 

) that allows users to override the global default on a per-workload basis. By letting devs fine-tune scaling thresholds independently for scale-up and scale-down actions, HPAs can become significantly more responsive without altering the core scaling algorithm or introducing major operational risk.



Support scaling to/from zero pods for object/external metrics



 sig-autoscaling

In the Kubernetes 1.37 release, there were improvements to the existing Beta release, natively allowing the HPA to scale workloads down to zero replicas (

) and back up based on object or external metrics (such as message queue length). The key change to Beta introduces an explicit 

 status condition on the HPA object. This enables the controller to differentiate between an automated scale-to-zero event and a manually paused deployment. The changes here also expanded end-to-end and integration test suites to ensure safe cluster behaviour.

Native Histogram Support for Kubernetes Metrics



 sig-instrumentation

Graduating from Alpha status to Beta in 1.37, this KEP introduces a 

 feature gate to expose Prometheus Native Histograms across Kubernetes control plane components alongside existing classic metrics. By transitioning from fixed bucket boundaries to dynamic exponential buckets, Native Histograms deliver a ~10x reduction in time series storage overhead and significantly sharper latency resolution for detecting performance issues. The dual-exposition model ensures full backward compatibility, allowing team-level migration without breaking existing dashboards or alerts.

 sig-network

Kubernetes 1.37 outlines the deprecation and eventual removal of the under-maintained 

, steering users instead toward the newer 

 backend as older kernels phase out of LTS by the end of 2026. Rather than archiving the code in a separate repository, the project plans a clean, multi-release removal via the 

 feature gate. The transition spans five stages: starting with deprecation warnings and documentation updates back in v1.35 (Stage 1), introducing the current feature gate in v1.37 (Stage 2), before disabling IPVS by default in v1.40 (Stage 3), and fully removing the IPVS codebase in v1.43 (Stage 4). The release team cleaned up the feature gate itself in v1.46 (Stage 5).

Add Resource Health Status to the Pod Status for Device Plugin and DRA



, with past milestones including the start of the cycle back in May and the 

 on June 16th. Upcoming technical milestones involve the 

 on July 22nd - the week before Kubecon Japan. The official v1.37 release comes out on Wednesday the 26th August.

Kubernetes 1.37 – What you need to know

Kubernetes 1.36 – What you need to know

Kubernetes 1.35 – What you need to know

Kubernetes 1.34 – What you need to know

Kubernetes 1.33 – What you need to know

Nigel Douglas

Head of Developer Relations

Every container inherits its base image. If that image carries unpatched CVEs, your application does too – before you've written a line of code. Hardened images fix the baseline: compiled from source with SLA-backed patching that keeps them clean after day one.

Distribution of these hardened images becomes a challenge. Security teams can pick a better image source, but making that image the default for every developer and build agent means new registry credentials per team and changes to how they pull. Adoption rollout becomes its own project, and it compounds across every team building containers. That's where adoption stalls.

 and Cloudsmith address the security and distribution aspects of using hardened images. WizOS compiles hardened container base images from source in an auditable pipeline, backed by strict remediation SLAs and cryptographic provenance. Cloudsmith puts those images behind the registry URL your teams already use, authenticated with credentials they already have.

Wiz doesn't pull pre-built packages from upstream public repos and assemble them. Wiz compiles its WizOS images from source in a controlled, auditable pipeline they own. You benefit from strict remediation SLAs that guarantee near-zero CVEs: 7 days for criticals, 14 days for highs and mediums. These builds also produce cryptographically verifiable provenance and signatures, so you can confirm exactly what shipped and where it originated. WizOS images have a minimal footprint, using only the components an image actually needs and 

 for broad compatibility with existing applications.

Hardened images writ large have the same goal: trust a maintained baseline instead of public open source upstreams. Wiz backs its WizOS hardened images with its own vulnerability and runtime data.

Cloudsmith treats the WizOS Registry like any other upstream (e.g., Docker Hub, npm, PyPI), as a source you proxy and cache behind your existing Cloudsmith repository URL. Developers don’t need to change how they pull images.

 In your Cloudsmith repository's Upstream Proxying settings, create a new Docker-format upstream pointing at 

, set your priority, and choose Cache and Proxy.

. Grab your Wiz Registry credentials from your WizOS tenant (Profile > Tenant Info > Wiz Registry Credentials) and configure them on the upstream. From here, Cloudsmith handles authentication on behalf of every developer and build agent, so nobody else needs a WizOS login.

 and pull images using their existing Cloudsmith repository path, for example:

Cloudsmith resolves the image, caches it on the first pull, and serves it from Cloudsmith's edge network on every subsequent pull.

Once you configure WizOS in Cloudsmith the one remaining manual step, 

, becomes optional. The Cloudsmith CLI's new Docker credential helper (added in 

) lets Docker authenticate to Cloudsmith registries automatically, using credentials your CLI already has.

 against your Cloudsmith registries, WizOS included, just work. You don’t need to worry about a login step, copying a token into CI secrets, or risk having credentials sitting in a config file that can expire or leak.

The helper also discovers any custom Cloudsmith registry domains on your account via the API and caches them locally, so it isn't limited to the default 

 host. If you need to point it at additional hostnames, pass 

 to preview what it would change before it changes anything; and skip the auto-discovery step with 

 if you'd rather manage the domain list yourself. When you need to back the help out, 

cloudsmith credential-helper uninstall docker

The Cloudsmith credential helper gives you one line in your provisioning script for all your build agents instead of a 

 call (and a credential) in every pipeline.

What the WizOS/Cloudsmith combination gives you is a pattern, not just a configuration. Your WizOS credentials live in Cloudsmith's upstream config once. No developer or build agent ever handles them directly. The credential helper removes the last manual authentication step, so pipelines authenticate using CLI credentials they already have. The initial base image pull caches in Cloudsmith, so every build after that comes from your own repo and upstream availability stops affecting your pipeline.

The credential handling and image caching are the operational wins. The broader payoff is that Cloudsmith becomes the control plane across your entire software supply chain. The same policy engine that applies to your application dependencies applies to WizOS images sitting in the same repository. Vulnerability scanning, environmental policies, and access controls run consistently from the base image through to the finished artifact, without separate tooling at each layer.

When your upstreams converge on a single Cloudsmith endpoint (e.g., WizOS, Docker Hub, npm, PyPI), security teams have one governed URL to apply policy to, and development teams have one URL to pull from. Nobody manages a separate credential per upstream, and policy coverage doesn't have gaps between the container layer and the application layer.

WizOS gives you a hardened starting point: images compiled from source, with SLA-backed patching that protects from CVEs. Cloudsmith makes that starting point the default across your org. Developers pull from the same URL with the same credentials. The secure path is also the easiest one.

Want to see how WizOS hardened images and your existing registries can all sit behind one Cloudsmith endpoint? 

Colin Moynes

Senior Support Engineer

Start secure, stay secure with WizOS and Cloudsmith

Shipping software requires two kinds of trust. The first is trust in what you build – that the artifact is secure, compliant, and approved for use. The second is trust in how you deliver it – that the right artifact moves to the right environment, with the right controls, every time.

Pipelines tend to handle the mechanics of both. Where they struggle is maintaining trust across the handoff between the two – and at scale, that gap is where risk compounds. Risk may include untrusted packages slipping through, environment-specific guesswork, manual steps under pressure, or reconstructing audit trails after the fact. Securing the handoff point requires both artifact governance 

 is designed to solve. A golden path makes the secure path the default path – governance baked into the delivery workflow from the start, not added as an afterthought. The Cloudsmith and Octopus Deploy integration is built on that principle.

Continuous trust doesn't emerge automatically from good tooling. Continuous integration (CI) systems build and test. Artifact registries store packages. Deployment tools ship to environments. Each does its job well in isolation. But the connections between these stages – the handoffs – are where governance tends to break down.

Artifacts accumulate in registries without clear signals about which are approved, safe, or compliant. Environment promotion logic gets buried in scripts few people fully understand. Approval processes drift into inboxes and informal agreements. When something goes wrong – or an auditor asks a direct question – there’s a scramble to reconstruct evidence rather than retrieve it.

The problem isn't the tools. It's that no single tool owns the full journey from "is this artifact trustworthy?" to "how, when, and where does it get deployed?" Continuous trust requires answering both questions, and connecting the answers.

Cloudsmith and Octopus Deploy cover that full journey. Each tool owns a distinct half, with a clean policy handoff between them.

Cloudsmith: Artifact trust before deployment

Cloudsmith is a universal artifact registry built for the enterprise. But its role in the delivery lifecycle starts well before an artifact is ready to deploy.

From the moment a dependency enters your environment, Cloudsmith enforces trust. Vulnerability matching, license compliance checks, access controls, and policy management govern what gets in, what gets promoted, and what earns approval for use – consistently, across every team and package format. By the time an artifact reaches Octopus Deploy, the governance work is already done. Trust hasn't just been verified at the gate; it's been maintained throughout.

This answers the question every pipeline needs to resolve: 

Is this artifact safe and approved to deploy?

Octopus Deploy: Controlled delivery from build to production

Octopus Deploy is a dedicated continuous delivery (CD) platform, purpose-built to take over where your CI server ends. It handles the full release orchestration process: environment promotion, approval gates, role-based access control (RBAC), deployment automation, and operational runbooks.

Where CI tools give you a place to run a deployment script, Octopus Deploy gives you a model for how software actually moves through your organization. The same artifact promotes from dev to test to production. Environment-specific variables are scoped without hardcoding. Deployments use strategies like rolling, blue/green, or canary depending on your risk tolerance. A single dashboard shows exactly what version is running in every environment.

This answers the other question your pipeline needs to resolve: 

How, when, and where should this trusted artifact ship?

When Cloudsmith and Octopus Deploy work together, the result is a clear division of responsibility:

Teams configure Octopus Deploy to consume only approved artifacts from Cloudsmith. An artifact is built, stored, and validated in Cloudsmith – with trust enforced at every step. Octopus Deploy picks it up and governs its promotion across environments. The same artifact moves through every stage: no rebuilds, no drift, no manual selection.

End-to-end traceability and audit-ready evidence

Security checks in Cloudsmith and deployment records in Octopus Deploy capture every stage of the journey by design, not after the fact. That means audits stop being fire drills.

Removing manual artifact selection and environment-specific guesswork eliminates a significant source of production incidents. When every team knows what's been approved and exactly how it gets deployed, releases become predictable rather than stressful.

As organizations grow across teams, regions, and infrastructure types – containers, VMs, Kubernetes, hybrid environments – delivery standards tend to fragment. This integration lets platform teams define policies once and reuse them across every infrastructure variation. Legacy workloads and cloud-native services follow the same governed path.

A delivery pipeline is only as trustworthy as its weakest handoff. A golden path fixes that by making governance the default – not a gate teams pass through, but a road built that way from the start.

Using Harness to deploy packages from Cloudsmith

More articles

Kubernetes 1.37 – What you need to know

Start secure, stay secure with WizOS and Cloudsmith

From trusted artifact to controlled deployment: Cloudsmith and Octopus Deploy

Cloudsmith’s take on Chainguard Repository

Kubernetes 1.36 – What you need to know

Intelligence and governance in the software supply chain with Endor Labs and Cloudsmith