Kubernetes has become the de facto platform for orchestrating containers. Open standards complement Kubernetes by defining best practices for its implementation. These standards are developed by the open-source Kubernetes community (not a single vendor), ensuring vendor neutrality, easier integration with other tools, and overall system efficiency.

, a Linux Foundation project, was created to establish open, industry-wide standards for container formats and runtimes. It focuses on two core specifications:

: A reference container runtime engine used by most container platforms, including Docker. It serves as the foundation for many modern runtime environments.

: Defines how containers are built, distributed, and executed. While Docker remains widely used, OCI represents the community's commitment to standardized, open container technologies.

, it became possible to use OCI-compliant container registries for storing and distributing chart packages. With the release of 

, OCI support moved from experimental to stable and is now enabled by default.

This shift has driven demand for registries that support Helm chart storage in OCI format. 

Cloudsmith is proud to be one such registry

, fully supporting Helm charts with OCI compliance.

Cloudsmith support moves from EA to GA for OCI

 released today (5th June 2025), we’re announcing full support for Helm OCI. Previously, Cloudsmith offered a Docker registry (

) that was fully compliant with the OCI v1.1 standard. While users could push any OCI artifact to this registry, non-Docker artifacts were still displayed as Docker packages.

This functionality had been marked as Early Access (EA) in our documentation, as the user experience was fully optimized only for Docker. Although users could technically push and pull any OCI artifact, display limitations persisted for non-Docker types.

With today’s update, we’ve significantly improved our support by fully enabling Helm OCI. We've reworked the implementation and introduced a dedicated endpoint (

) which allows users to push and pull Helm charts as OCI artifacts, now correctly identified and displayed as Helm packages.

In addition, we're introducing a compatibility bridge that enables legacy Helm charts and OCI-based Helm charts to coexist. We are now in a unique position to support legacy Helm chart repositories and OCI, allowing our users to push via legacy means and pull via OCI - offering greater flexibility and smoother transitions.

 is a tool that enables pushing, pulling, and managing 

 in OCI-compliant registries. It extends the OCI specification beyond container images, turning registries into general-purpose artifact stores.

 formalizes this approach, allowing for a broader range of artifacts, like SBOMs, Helm charts, and signatures, to be stored and retrieved without being disguised as container images. ORAS has become the 

 highlighted how ORAS is transforming registries into multi-purpose artifact platforms. They demonstrated pushing multi-architecture images along with their security metadata - all as native OCI artifacts.

As the ecosystem matures, there’s a clear trend: 

treating everything (from Helm charts to SBOMs) as first-class OCI artifacts

. At Cloudsmith, we're seeing growing demand for comprehensive support of these use cases, including secure metadata attachments and provenance tracking.

, which allows artifacts to reference related files such as SBOMs, signatures, or provenance records.

Nigel Douglas

Head of Developer Relations

Open Container Initiative (OCI) Support in Cloudsmith

Apache Maven is a popular and widely-used open-source build automation and project management tool primarily designed for Java projects.

We're excited to announce a major enhancement to our Maven repository support at Cloudsmith. As a Java developer, you can now upload and distribute 

 using Maven repositories, unlocking more flexible and powerful workflows for your projects.

Arbitrary files are files that are ignored by Maven unless explicitly included in the Project Object Model (

 configuration. This update means that Cloudsmith can now support unique package names that don't support Maven convention or use arbitrary classifiers or extensions, so really they should be able to upload any file regardless of the extension.

Previously, Cloudsmith Maven repositories only supported standard artifacts that followed the traditional 

). That meant non-standard files (such as custom dependencies, configuration files, or other useful assets) couldn’t be cached from upstream sources or uploaded directly.

you can now cache and distribute arbitrary files

, whether they’re pulled from upstream sources or uploaded directly using your preferred tooling.

Not every project follows the “standard” Maven structure (and that’s okay!). Whether you're dealing with:

Binary assets like .zip, .tar.gz, .exe, or .dmg

Configuration files, templates, or scripts

You can now fully embrace these flexible workflows without needing to hack around repository limitations. Cloudsmith's improved Maven support now includes:

: Cache and serve arbitrary files that don’t follow Maven’s strict packaging rules (even from external sources).

 Upload arbitrary files manually or automatically as part of your CI/CD pipeline.

 Use native tooling like Maven, Gradle, or SBT (or the Cloudsmith 

Java developers - we get it. Your workflows matter. Your tools should keep up.


That's why we're making Maven repository management smarter and more flexible - just for you. With Cloudsmith, your Java packages have never had it so good.

Are you ready to simplify your build and deployment workflows? 

Get started with Cloudsmith Maven repositories

 and explore our new arbitrary file support today!

Full Support for Arbitrary Files in Maven Repositories with Cloudsmith

As containerized environments evolve, effective artifact management is crucial for any organization using Kubernetes or similar ecosystems. Cloudsmith’s container registry now fully complies with the Open Container Initiative (OCI) distribution specification, allowing customers to store, secure, and distribute images and artifacts with greater efficiency.

This release marks an evolution in how Cloudsmith supports organizations, enabling streamlined workflows while ensuring compatibility with current and future industry standards.

With this update, Cloudsmith offers robust support for the OCI storage protocol and API format, including:

: Cloudsmith now supports the OCI storage protocol and API format, bringing greater flexibility and alignment with industry standards for artifact management.

Early Access for OCI Images and Artifacts

: With early access support, Cloudsmith customers can store, secure, and distribute generic OCI images and artifacts, including Helm V3 charts. Using ORAS, users can push and pull artifacts like SBOMs and attestations, strengthening control over containerized workflows.

: The Referrers API allows you to query an OCI registry for artifacts linked to a specific image or artifact, typically through reference or association. This feature is especially helpful for retrieving metadata such as attestations, SBOMs, signatures, or other security-related artifacts, offering a streamlined way to manage dependencies and related security information.

Key Benefits of Cloudsmith’s OCI-Compliant Registry

With Cloudsmith’s OCI-compliant container registry, organizations can unlock the following advantages:

: Integrate seamlessly with any OCI-compliant tools and services, enabling you to choose the right tools to fit your workflows and achieve optimal outcomes without compatibility issues.

: Rely on industry-standard specifications for container formats and image distribution, providing greater consistency, reliability, and peace of mind as you scale operations.

: As more technologies and ecosystems adopt the OCI specification, Cloudsmith’s platform will continue to support them, ensuring your workflows stay relevant and adaptable.

As we continue expanding support for OCI, expect updates on advanced Helm capabilities and additional security features for all supported artifact types.

Maia Livingstone

Campaign Manager

Securely Store and Distribute OCI Artifacts

As software complexity advances, understanding what’s happening across every part of your software supply chain becomes crucial. You need to see where artifacts are used, how secure they are, and whether they meet compliance standards.

The ability to capture this is known as observability. Observability goes beyond data collection to provide essential insights that help teams understand, troubleshoot, and enhance complex systems. It enables engineers to ask critical questions, anticipate issues, and respond proactively—fostering resilience and reliability.

Overcoming the Challenges of Limited Observability

Without good observability, teams are often left in the dark, relying on incomplete data and reactive troubleshooting when issues arise. This can lead to longer downtime, unexpected costs, and missed security risks, as there’s no clear visibility into where problems occur or why. The lack of insights also makes it harder to anticipate trends, manage resources efficiently, and ensure compliance, ultimately compromising system reliability and customer trust.

Knowing this, we wanted to take a step forward and create a solution that provided a quick turnaround on insights that drive immediate corrective action. As a result, Cloudsmith has launched an advanced observability suite, offering enterprises unparalleled insights into their software supply chain. With a fully redesigned user experience, customers can now make data-driven decisions more effectively, managing artifacts with greater precision and control.

Enhanced Observability for Usage Management

Cloudsmith’s advanced observability features give engineering managers and DevOps teams the insights needed to monitor and manage artifact quality and usage across their systems. These tools are built to handle complex, large-scale environments, helping teams track trends, accurately attribute costs, and proactively address risks—essential for maintaining control over a dynamic software supply chain.

"Cloudsmith's analytics and alerts are instrumental in helping us manage our usage more effectively and plan for increases in demand for software artifacts,...We can catch unexpected spikes in artifact consumption, improving our security posture and avoid usage surprises at the end of the month" Dave Bresci, Senior Manager, SRE, PagerDuty.

Cloudsmith’s new observability suite offers several key features geared to upgrading observability:

: Granular dashboards and reports provide a clear view of consumption patterns over time, enabling informed resource management.

: A centralized dashboard for policy violations, vulnerability data, and license tracking offers a straightforward way to assess and address organizational risks.

: Real-time notifications ensure that critical information on usage and policy adherence reaches the right teams when it’s needed most.

These features equip teams with the context and control required to navigate complex, large-scale environments effectively.

The new suite comes with a fully redesigned user experience, featuring streamlined navigation, enhanced performance, and a data-rich interface packed with deeper insights. Cloudsmith has tailored these improvements to ensure smooth, efficient access to critical data, making it well-suited for large-scale enterprise operations.

With this suite, organizations are empowered to navigate challenges confidently, drive smarter decision-making, and ensure their software supply chain remains both agile and secure.This isn’t just a tool - it’s a strategic advantage.

Unlock the full potential of your software supply chain with Cloudsmith’s advanced observability suite. See firsthand how our powerful analytics and real-time insights can help you optimize artifact usage, anticipate risks, and maintain compliance across your systems. Schedule a demo today to explore how Cloudsmith can give your team the visibility and control needed to drive smarter, data-driven decisions.

 and discover how Cloudsmith’s observability suite can transform your software management process and help you stay ahead of potential issues in your supply chain.

Introducing Cloudsmith’s Advanced Observability Suite for Enterprise Artifact Management

It’s a fairly common perception that a package repository is basically a file share or file storage, and perhaps for some of the most simple implementations, this is a reasonable analogy.

However, when thinking of Cloudsmith, this analogy misses a lot of important details that make Cloudsmith package repositories rather unique.

If you have used Cloudsmith, you may have noticed that when you publish/upload a package to Cloudsmith or fetch a package from a public package repository (Like Maven Central or PyPi) into Cloudsmith, the first thing that happens is that the package enters a “Synchronizing” state. What exactly is synchronizing?Put simply, synchronization is where Cloudsmith processes the uploaded/ingested package. But that still belies a lot of the detail. What possible processing could a package need? Well, quite a lot actually!

Some of the steps that synchronization/package processing involves are:

 - Setting up the initial state, tools and environment for synchronization.

 - Getting the package files from the upload storage location.

 - Extracting the package files and package assembly (layers and configs for Docker images, for example)

 - Once we have the complete package file set, we scan the files for trojans, malicious content etc.

 - Verify and generate package checksums and signatures, as well as parse and verify package metadata and licenses.

 - Local and Distributed Storage synchronization.

These processes are automatic, require no user interaction and run asynchronously on Cloudsmith's global infrastructure. They are a large part of what empowers Cloudsmith users to implement effective package controls. As they say, knowledge is power - and it’s by the process of synchronization that we gain the knowledge of packages.

Once a package has been synchronized, we can then use the metadata generated to apply things like Vulnerability, Licence and Package Deny policies, create a scoped access token, add tags to the package, or fire a webhook for specific packages/versions. The data generated from synchronization drives a lot of the subsequent actions and workflows that you can perform.

Also, you may encounter occasions where a package fails synchronization:

This is typically a good thing (contrary to initial impressions!) because it can alert you to a problem with the package itself such as invalid/missing/incorrect metadata (the package not meeting the specification for the package type, for example), the presence of Malware in the package, or that you are attempting to upload/publish a package that already exists in the repository (as above). Package synchronization is an essential step in verifying the “correctness” of a package and It’s always better to catch things earlier in your processes than later, as the cost of remediation rises dramatically the later issues are identified.

Cloudsmith Package Repositories do far more than just store your packages, and they have a lot more functionality than just storing your packages in an AWS S3 bucket or Azure Blob Storage, or spinning up a simplistic instance of a package repository. Packages in Cloudsmith repository are so much more than just “bits on disk”, and treating them as such is really doing them a disservice!

Dan McKinney

Solutions Engineer

What happens when you upload a Package?

Package promotion workflows are a great way to isolate and protect production repositories, allowing progressive levels of security and permissiveness for development, staging, and production environments.

Once a binary is uploaded to Cloudsmith, it can move from development -> staging -> production, maintaining the integrity of the asset and its provenance trail. This migration takes place entirely within Cloudsmith; there’s no package delivery cost.

The differences between Dev, Staging and Production environments.

Cloudsmith's package promotion instructions- package copy/move actions

Complementary features that play nicely with package promotion, including webhooks, quarantining, policy management and upstreaming. These can be used together to create workflows and drive actions.

A Potential workflow for package promotion

Policy management that lets you set up policies that serve as prerequisites to package promotion.

Differences between Dev, Staging, and production environments

Typical software development organizations maintain three types of environments: development, stage, and production.

environment is used for developers early in the software process to see how new features will work, to try out improvements and pull in new dependencies or update existing dependencies.

 environment is used for testing integration and is a production-

environment that allows user creation without impacting production data. Only whitelisted IPs typically have access to Staging.

 environment is what end users are using on a live system.

Cloudsmith's package promotion workflows are powered by features to copy and move packages between repositories, usually for promoting immutable versions of packages between separate build, test, staging and production pipelines. The package that was verified in build is the same package in production when it gets promoted to there. Cloudsmith facilitates the automation of copying and moving packages using our command line interface (CLI).

 for vulnerabilities and license issues. This ensures that only secure and compliant artifacts are promoted through the pipeline, with policies applied to block or quarantine packages that fail these checks.

Let's see an example of moving a package in action:

 package was moved (or "promoted") from the source repository to the destination repository. Copying packages works the same, except it duplicates the package rather than moving it from the source to the destination.

In addition to moving and copying packages, you can also resync packages via the CLI, whereby the CLI will retry packages that have failed (for whatever reason) up to a configurable amount of attempts.

To see the full list of help for actions, run the following commands:

Package promotion on its own is great, and you can couple it with other features to create workflows and drive actions. Let's talk about tagging, webhooks, multiformat repos, vulnerability scanning, and setting up upstream.

 feature allows you to label your packages with tags like "dev", "staging", or "prod" as they move through your pipeline. These tags help in tracking packages across different environments, and enable targeted searches, filtering, and control over what artifacts are accessible. By using 

, you can automate package promotions based on tag transitions, such as promoting a "staging" package to "prod" once it passes certain tests). This enhances visibility and governance within your pipeline and simplifies the overall package management process.

Webhooks let apps send automated messages or information to other apps. 

 are great for integrating Cloudsmith with other systems in your build pipeline, by sending data or notifications to other tools in your stack and helping to enable automation across your workflows.

Cloudsmith has webhooks for vulnerability scanning. Anytime a scan is completed, Cloudsmith can dispatch a corresponding vulnerability webhook to trigger some action, like creating a Jira ticket.

Cloudsmith's vulnerability scanning is particularly effective when combined with upstreams. Upstream proxying and caching allow you to upload and use the packages you author in-house directly, while Cloudsmith fetches and caches your dependencies from public repositories like Maven Central or NuGet.org.

This enables you to use Cloudsmith as a first-class cache and a central source of truth for packages, to protect you from issues related to use of external services, such as downtime, rate limiting, or non-availability of a previously available package.

Packages fetched from a caching-enabled upstream will be automatically scanned for vulnerabilities for Ultra customers.

Multi-format repositories allow you to store artifacts of different formats in the same place. Organize your packages by environment, project, package type, or whatever way you see fit.

Package vulnerability scanning is a key step in securing your software delivery pipeline and reducing the risk of releasing insecure software into production.

Cloudsmith automatically scans every supported package format pushed to a Cloudsmith repository or fetched from a caching-enabled upstream.

Cloudsmith's vulnerability scanning feature is available for the following package formats:

Cloudsmith's Security Scanning page shows a breakdown of the number of packages scanned/not scanned, the age of scans, the pass/fail count overall and the maximum severity of those found.

Setup your Dev repository with upstreams and your Staging repos with no upstream

Push your package to Dev repository and tag the package with ‘dev’.

Automatically tag the package with ‘staging’ and move the package to the Staging repository when the results return with no vulnerabilities.NOTE: you may want to run more manual tests against this package before promoting it.

 for the examples below. The CLI interfaces with Cloudsmith's API and allows users, machines and other services to access and integrate smoothly with Cloudsmith without requiring explicit plugins or tools.

Setup your Dev repository with upstreams and your Staging repository with no upstreams

Create 2 repositories Dev and Staging by following the instructions 

.

Set up an upstream for the Dev repo by following the instructions 

A vulnerability scan is automatically triggered for supported packages every time they are pushed into a Cloudsmith repository. If you set up an upstream, your 3rd party dependencies are also scanned for vulnerabilities.

Cloudsmith supports over 30 different types of packages. 

Upload via the package-specific native CLI / tools e.g. using Maven's 

Upload via the API using tools/integrations (such as the official Cloudsmith CLI).

To upload a package via the Cloudsmith CLI, use the cloudsmith push command:

Setting up webhooks so Cloudsmith can send automated messages to alert another system when a package had been scanned is great for setting up vulnerability workflows.

 in your repository and then create a new webhook. Then:

 with the tool you want to receive your webhook like 

You can test out the Webhook by selecting to 

The webhook is triggered when the scan is finished and will have a payload in the HTTP req with information about the package and any vulnerabilities, including:

This information can drive actions such as tagging and promoting a package based on the maximum severity reported.

, use the command cloudsmith tag as follows:

cloudsmith tag add OWNER/REPOSITORY/PACKAGE TAG1, TAG2

 promote a package use the Cloudsmith CLI command cloudsmith cp or mv as follows:

For example, using the data from the snippet above where 

 is the package identifier or the package 

cloudsmith cp demo/examples-repo/IB6FYhIvaoAy

Enhance your Workflows with Policy Management

To further secure and streamline your package promotion workflows, Cloudsmith’s 

 features can be used to automate and enforce critical security measures. With 

, you can automatically block or quarantine packages that violate license rules, while 

 scan for potential risks, quarantining packages based on severity. 

 enforce API-key rotation to ensure secure access.

These policies make your workflows more secure, compliant, and automated—minimizing manual intervention and reducing risk across your software supply chain. To explore these features in more detail, check out our blog on 

Looking ahead, Cloudsmith’s Enterprise Policy Manager will further enhance promotion workflows with advanced controls.

 It will allow policies to be applied at any decision point, ensuring real-time enforcement of security and compliance rules like “should we allow this action?”
Key features include:

: Create custom policies tailored to your specific needs, from access control to package promotion.

: Manage and trace policies at scale for better compliance.

: Integrate data like Cloudsmith Navigator and security scanners for more informed decisions.

: Speed up implementation with best-practice policy templates.

: Leverage your existing security tools within Cloudsmith.

Ciara Carey

How to Manage Your Package Promotion Workflows with Cloudsmith

Cloudsmith CLI Overview

An overview of the Cloudsmith CLI, showing how to install, configure, and some of the commands available.

Speed is very important to us at Cloudsmith. As a cloud-native solution we believe that every team member and every build system - no matter where they are on the planet - should have low-latency access to packages and assets whenever they need them. And we never stop working to make that happen!

If you’re a Cloudsmith customer you’ll already know that we allow packages to be stored in a location of your choosing. We also offer delivery across a CDN and edge-caching to minimize latency when accessing packages from the Cloudsmith platform.

We’ve now gone beyond simple storage to add global infrastructure in two more new locations: Oregon (US) and Sydney (AUS). These are just the first of many, of course, but together these two new locations allow all traffic via the Cloudsmith API to greatly benefit from the nearest geographic location - or at least more local than before. This also has a direct impact on download requests.

Even better, Cloudsmith automatically calculates which location is best in terms of performance at any given moment in time, and for any individual or process no matter where they are located. You don’t have to second guess, we’ll ensure packages are processed as fast as possible in all circumstances.

The differences can be significant. On average, response times of 480ms were reduced to 235ms for a flat request in the wake of this roll out, and in some instances latency improvements were more impressive again: from 800ms to 40ms in Sydney, for example.

The visuals below show precisely the impact of these changes - hopefully you notice the difference too!


Product Update: More Global Infrastructure

There is a paradox at the heart of modern software development processes.

those processes are more collective than ever before

. The old days of the lone genius are long gone. In the modern world of DevOps, continuous integration and continuous delivery, extensive teams work together as seamlessly as possible. Every cog in the machine plays a vital role.

As individuals in that process, we are used to sharing our own work and building on the work of others. Software delivery is a broader, more cooperative process than ever before.

. Modern software teams are rarely in the same building, and in some cases, there is no ‘building’ at all. Even large developer organizations such as 

 either have no office at all or let employees work wherever they feel like.

Of course, most of us will be well aware that a range of technologies help square that circle and enable highly distributed teams to work closely together. From tools such as GitHub that help us collaborate on code in a constructive way, to messaging platforms such as Slack that keep everyone in the loop, there are a multitude of products that support co-working across physical barriers.

In fact, the very existence and adoption of those tools - by the open-source community, in particular, can be said to have driven the adoption of distributed development.

Where Do Software Assets Live In A Distributed World?

Let’s talk about software assets. In the collective processes we described above, packages are the essential building blocks of software. What we create is a collection of packages and dependencies, and is in turn packaged and made available for use by others within and outside the organization.

So centrally important are these packages that for reasons of security, availability and reliability most organizations are by now well-aware that these packages need to be stored within a private repository. In addition, of course, if we wish to protect our own intellectual property it will be absolutely essential to do this.

The standard answer to that question today is (or certainly was) ‘on-premise in my development headquarters or datacenter’. As a simple answer to an apparently simple question, this has its merits.

First, locating packages and assets on-premises means that in theory, they are fast to integrate into build processes. Given that these processes can integrate thousands of packages and dependencies, and occur dozens of times a day, even marginal performance issues can quickly escalate into significant (and frustrating) increases in build times.

Second, as noted above it gives us control over the software assets within the organization. On-premises means under our watchful eye, or at least that is the theory.

Of course, you’ve probably guessed what the issue with this approach is. Which premises? 

At Cloudsmith we increasingly work with clients who have teams and individuals distributed all across the globe in dozens or even hundreds of individual sites.

And even beyond that reality, the growing rise of cloud-native continuous integration, for example, means that many of the processes that packages feed into (and emerge from) are not based on any premises anyway.

 for the majority of the organization even whilst it looks great to the CTO and the rest of the team in HQ! To counter this issue, many organizations attempt to mirror repositories across multiple locations.