What a year it’s been at Cloudsmith. As we look back on 2024, it’s hard not to feel a sense of pride - and even a little awe - at how far we’ve come. From a scrappy startup to a trusted partner for some of the biggest names in the world, this year has been a turning point, both for our company and the people who make it special.

In this video, our CEO, Glenn Weinstein, reflects on the highs, the challenges, and the moments that defined this year for us. Here’s a little glimpse into what made 2024 unforgettable.

Coffee with Cloudsmith 2024

Growing Up Without Losing Who We Are 🌱🏢

We’ve doubled our count of Cloudsmithers in 2024! It’s exciting, of course, but also a little bittersweet. It’s harder to fit everyone into a room these days - we’d need a really big room! - and keeping up with all the new names can be a challenge. But growth means something important: we’re helping more people, solving bigger problems, and making a real difference for our customers.

Our mission hasn’t changed - to make developers’ lives easier. What’s shifted is our focus. Over the past 18 months, we’ve zeroed in on enterprises, especially those with massive teams using countless tools, languages, and formats. Cloudsmith’s strength is bringing all that chaos together in one place, making it simpler, faster, and more secure to build great software.

A Team That Feels Like Family 👩‍💻👨‍💻❤️

One of the things that sets Cloudsmith apart is the people. Early on, we were all generalists - pitching in wherever we were needed. But this year, we’ve started to mature, hiring specialists with deep expertise who can push us to the next level.

And while our roots are firmly in Belfast, where Cloudsmith began, we’ve expanded to Dublin, London, other locations around Ireland and the UK, as well as India and the United States, too. Belfast, though, holds something special - it’s become home for many of us, including our New York-born CEO, Glenn Weinstein.

Glenn, who splits his time between the U.S. and Belfast, shares in the video how much he’s come to love the city. “There’s something about walking the streets of Belfast, grabbing dinner, or just soaking up the atmosphere that makes you feel welcome,” he says. “As someone from New York, I never imagined Belfast would feel like home, but it truly does.”

Even though we’re a remote-first team, we believe in the magic of in-person connection. That’s why we bring everyone together three times a year for offsites in Belfast. Those few days - full of laughs, ideas, and even a pint or two - are what fuel the trust and camaraderie that make Cloudsmith such a unique place to work.

For our Engineering team, 2024 has been a year of transformation. What used to be a single team now includes specialized squads like Bytebusters, Sentinel, Platform, and Kronos. These groups allow us to go deeper into what we’re building, whether it’s improving security, expanding formats, or creating a sleek new web app that’s already winning over customers.

Looking ahead to 2025, the roadmap is ambitious - and that’s putting it mildly. From digital signatures to advanced policy management tools, we’re diving headfirst into solving some of the biggest challenges in the software supply chain. It’s a big task, but one we’re excited to tackle.

If there’s one thing that’s really hit home this year, it’s this: our customers don’t just need great software - they need a partner. As we’ve worked with Global 2000 and Fortune 500 companies, we’ve realized that onboarding isn’t just about flipping a switch. It’s about walking alongside them, helping them adapt, and making sure every team - whether it’s five people or 500 - feels supported.

This has been a game-changer for us. We’re not just delivering a product; we’re building relationships. And those relationships? They’re built on trust, understanding, and a commitment to helping our customers succeed.

As we close out 2024, we feel like we’re just getting started. Yes, we’ve grown. Yes, we’ve achieved incredible things. But our dreams are bigger than ever. Glenn Weinstein puts it perfectly: “Cloudsmith isn’t just a feature or a niche. We’re building something foundational, something that will change how enterprises everywhere manage their software supply chains.”

We believe Cloudsmith can be a cornerstone for enterprises - a platform that simplifies, secures, and transforms how software is built. We’re still on the journey, still learning, still growing. And we’re so grateful to everyone who’s been part of it - our team, our customers, and our community.

Watch the video above to hear more from Glenn Weinstein about this incredible year and what’s ahead. And if you’re curious about how Cloudsmith can help your team, we’d love to show you.

Here’s to 2025 and everything it holds. Let’s build it together. 💪✨

Maia Livingstone

Campaign Manager

A Year to Remember: Cloudsmith’s Journey Through 2024  🚀🌍

 is a modern CI/CD platform designed for Kubernetes and microservices applications. It provides developers with fast, powerful pipelines and deep integration with Kubernetes. The platform’s features, such as enhanced caching, parallelization, and flexible triggers, allow teams to optimize their continuous integration workflows.

 to offer a comprehensive GitOps platform for Kubernetes. GitOps helps teams automate their infrastructure and application management, using Git as the single source of truth for deployments. By leveraging Argo within Codefresh, developers can employ advanced deployment strategies such as canary releases and blue-green deployments, improving release quality and reducing risks.

Benefits of Using Codefresh and Cloudsmith Together

, a cloud-native artifact management platform, with 

 enhances your CI/CD workflows in several significant ways. This powerful combination automates artifact handling, simplifies deployments, and enables the adoption of GitOps practices for Kubernetes deployments.

By automating artifact publishing within Codefresh pipelines, developers can significantly reduce manual steps, minimizing errors and ensuring artifacts are securely available for deployment. Cloudsmith’s support for multiformat repositories ensures that microservices using different package formats—such as Docker, npm, Helm, and Maven—can be managed and retrieved consistently.

Integrating Cloudsmith with Codefresh streamlines deployment processes by allowing developers to pull artifacts directly into their Codefresh pipelines. Whether deploying Docker images or Helm charts, this integration ensures consistency across all environments, from development to production, reducing deployment discrepancies.

, developers can ensure that only approved and secure components are used in their pipelines. Features like quarantine and upstream proxying add further control over unapproved or vulnerable dependencies. This guarantees a secure, compliant software supply chain.

Adopting GitOps for Kubernetes Deployments

Combining Cloudsmith and Codefresh enables teams to fully adopt GitOps practices for Kubernetes deployments. GitOps ensures that deployments are automated and aligned with the desired state defined in Git repositories. With Argo built into Codefresh, continuous reconciliation of your Kubernetes clusters keeps your infrastructure consistent with what’s declared in your codebase.

By integrating these platforms, you automate artifact handling, simplify deployments, and enhance security—all while adopting GitOps practices for Kubernetes deployments. This empowers your team to focus on delivering value—writing code, innovating features, and improving products—while the integration handles the complexities of artifact management and deployment.

How to Set Up a Pipeline with Codefresh and Cloudsmith

Setting up a CI/CD pipeline that integrates Codefresh and Cloudsmith is straightforward. Below is a guide to configure your pipeline for seamless artifact management and deployment using either 

 and create repositories for your artifacts.

: Ensure you have access to a Kubernetes cluster connected to Codefresh for deployments.

Open your Codefresh pipeline and go to the 

Name the variable (e.g., CLOUDSMITH_API_KEY), input your API key, and toggle 

Reference the API key in your pipeline YAML using ${{CLOUDSMITH_API_KEY}}.

 in Cloudsmith (required for OIDC to work with Cloudsmith).

Claims: For example add your Codefresh account ID to restrict access. For more information on claims consult the 

Assign the service account you created earlier.

In Codefresh, set up OIDC authentication by configuring your pipeline to request OIDC tokens during execution.

Add steps in your pipeline YAML to obtain and use the OIDC token for authenticating with Cloudsmith.

Modify your pipeline YAML to include steps that push build artifacts to Cloudsmith after successful builds.

To publish Helm charts, you need to use the Cloudsmith CLI. Ensure that the CLI is installed in your pipeline environment. For more details, refer to the Cloudsmith Helm documentation.

Deploying Artifacts from Cloudsmith Using Codefresh

Codefresh offers several ways to deploy your Docker images and Helm charts to your Kubernetes cluster using artifacts stored in Cloudsmith:

Using the Codefresh GUI to Deploy on Demand

: Choose Docker images from your connected Cloudsmith Docker registry.

: Select Helm charts from your added Cloudsmith Helm repository.

: Use Docker images stored in Cloudsmith within your pipeline steps.

: Utilize the Helm step in your pipeline to deploy charts from your Cloudsmith Helm repository.

Kubernetes Templating (cf-deploy-kubernetes)

: Employ templated deployments for consistent configurations.

: Execute custom kubectl commands within your pipeline, referencing artifacts from Cloudsmith.

: Directly deploy Helm charts to your Kubernetes clusters.

: For advanced GitOps deployments, integrate 

 with Codefresh. This allows automated deployment of applications to Kubernetes clusters using Cloudsmith as your artifact source.

Example of Pulling a Docker Image Using OIDC

Below is an example pipeline demonstrating how to authenticate with Cloudsmith using OIDC and deploy a Docker image:

: Retrieves an OIDC token required for authentication.

: Uses the OIDC token to obtain a Cloudsmith-specific token.

: Logs into the Cloudsmith Docker registry using the obtained OIDC token and pulls the desired Docker image.

: Verifies the successful pull by checking the Docker image's history.

: Ensure that the Cloudsmith CLI is installed in your pipeline environment if you plan to publish Helm charts or perform other CLI-based operations. Refer to the Cloudsmith Helm documentation for more details.

: Prefer OIDC over API keys for enhanced security and simplified credential management.

 when deploying artifacts from Cloudsmith. This ensures that deployment pipelines only have the necessary access to pull artifacts without the risk of modifying or deleting them, thus improving the security of your deployment process.

: Store sensitive information like API keys or OIDC tokens securely using Codefresh's encrypted variables or secret management features.

: Leverage Codefresh pipelines and GitOps practices to automate deployment steps, reducing manual intervention and potential errors.

: Utilize Codefresh's dashboards and integrations to monitor deployment status and health, ensuring quick identification and resolution of issues.

: Maintain your deployment manifests in Git repositories for version control, traceability, and easier collaboration.

Integrating Cloudsmith with Codefresh optimizes your CI/CD pipelines by providing secure, automated artifact management and simplifying deployments. With Cloudsmith’s support for multiple package formats and Codefresh’s robust CI/CD capabilities tailored for Kubernetes and microservices, this integration is ideal for modern, distributed applications.

Ciara Carey

Solutions Engineer

GitOps Pipelines with Codefresh and Cloudsmith

products lies in their architecture, design philosophy, and how they leverage cloud infrastructure. Let’s break down the key distinctions:

A Cloud Native product is specifically built for the cloud from the ground up. It is designed to fully utilize cloud computing capabilities such as scalability, elasticity, and high availability.

Microservices / Distributed Architecture:

 The application is often broken down into microservices and/or leverages Cloud-Provider managed services, with each service independently deployable, scalable, and manageable.

: They can automatically scale up or down based on demand, making them more efficient in handling fluctuating workloads. Also, the scaling can be more fine-grained, to specific parts of the service/platform

: Cloud-native applications are built to use cloud-specific databases (e.g., AWS Aurora Postgres, DynamoDB or Google Cloud Spanner etc) and services designed to take full advantage of cloud features. They are “Infrastructure Aware”.

: Cloud-native appliications typically support rapid development cycles, using CI/CD pipelines to automate deployments seamlessly with zero downtime. This means faster updates, releases, improvements and fixes.

Example: A cloud-native SaaS product like Netflix or Slack is architected specifically for dynamic cloud environments, offering high availability, multi-region support, and easy scaling.

A Cloud Hosted product is typically a legacy or traditional software application that was originally built for on-premise environments but has since been moved to the cloud. Instead of being designed with cloud-native principles, it's hosted on virtual machines or cloud infrastructure and usually does not fully leverage cloud-native features.

: These products are often built as large, single applications that run as an instance rather than being divided into smaller, scalable services.

: Rather than using containers or orchestration, these apps may be hosted on traditional virtual machines or cloud servers (e.g., AWS EC2 or Azure VMs).

: Cloud Hosted products may not scale as efficiently or dynamically as cloud-native products, requiring the entire instance to be scaled up or additional whole instances spun up and clustered/replicated, making them less responsive to real-time demand compared to cloud-native apps.

: These products often still rely on traditional infrastructure or databases (Like MySQL or Oracle), with those databases hosted in the cloud on a virtual machine.

An example could be older CRM systems like SAP or older ERP software moved to the cloud but without restructuring/re-architecting the core software to fully utilize cloud-native principles.

In essence, "Cloud Native" means that an application is inherently designed to take full advantage of cloud computing, whereas "Cloud Hosted" applications are more of a legacy or traditional application that's been minimally adapted to run on cloud provider infrastructure. Cloudsmith is a true Cloud Native Artifact Management product.

It’s just not easy to take a traditional application and make it Cloud Native, it’s much less development effort just to host that application on a cloud provider’s infrastructure. To be truly Cloud Native requires Cloud technologies and services to have been considered when an application was architected. To do this with a traditional application that can be installed on a server on-prem or a VM in the Cloud is essentially a rewrite of the application, and that is a monumental effort for a vendor, especially when they have an installed base of users. Ultimately, it would be an entirely new product.

Dan McKinney

"Cloud Native" - Why it matters?

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.

How to Manage Your Package Promotion Workflows with Cloudsmith

Choosing the right software package for your project can sometimes feel like finding a needle in a haystack. Package registries do a great job at being comprehensive, but they can’t necessarily guide you to the best package for your project. What is a “high quality” package anyway? This is a problem the OSS community 

We’re proud to announce the full public release of 

. Navigator is designed to help software engineering teams select the highest quality packages early in their development lifecycle. Navigator integrates and analyses data on 

40,000 of the most popular open source packages 

across NPM, PyPi, RubyGems and Maven, assigning each one a unique quality score based on adherence to security standards, good maintenance metrics, and thorough documentation.

Like most software engineering teams, we regularly look for software packages to help us get our work done. Finding and selecting the right open source package for a project is not straightforward. It's a balancing act. You need to find something that helps you get the job done, but often a package's functionality is just the starting point.

Many packages accomplish similar objectives. Some are more secure than others. Some have better documentation than others. Some are new to the ecosystem, while others are tried and tested.

 We regularly wonder what constitutes a high quality package, and this is something that has been a source of discussion and debate for as long as open source software has existed.

?” then it backs it up with detailed information.

 It cuts through noise for engineering teams. We have developed our own unique perspective on what constitutes a great package. We have expressed this in three essential metrics:

. This is where you'll find information about the essential security and community uptake of a package. If a package has no open CVE's, good test coverage, current dependencies, and is widely used in the open source community- it’s likely to score highly on Navigator’s quality metric.

The next metric is designed to capture a package's 

. A package will score highly if it is regularly maintained by a wide pool of contributors, underpinned by a code of conduct.

The final metric in our Navigator scorecard describes a package's 

. There is nothing mysterious here, we score packages highly where they have a Readme, a documentation website, and a changelog.

 can analyse the quality of package dependencies. 

If a package looks good on the surface, you really should try to understand what packages it relies on at Runtime and Buildtime. Navigator analyses these dependencies where possible, so it's never been easier to understand the trade-offs involved in consuming an OSS package.

For the first time, we as a team have somewhere to go where we can quickly assess package quality. It's no longer a scavenger hunt. We no longer need to overinterpret the number of stars a package has on GitHub, or trawl through multiple sources of information, just to understand if a package is documented, or currently maintained.

We think this is something that all software engineering teams will use, so we’re making it available to the community. After an initial beta in late 2023, we're happy to announce that 

Over time, we’ll add many more packages, and enhance quality scores to include real-world usage data, something that is only possible with Cloudsmith. Thanks to our cloud architecture - we have a unique understanding of the way software is built today. We’re excited to incorporate some of our unique insights into future versions of 

Paul May

Senior Director, Product & Customer Experience

Cloudsmith Navigator: The Trusted Guide to OSS Package Quality

When a headhunter reached out to me about the CEO role at Cloudsmith (where I started in August!), one of the first things I did was sign up for a trial account. The product's depth and sophistication really impressed me, and contributed to my decision to go ahead with the interviews. (Glad I did.)

But after I started, I found out that my fellow Cloudsmithers actually thought the experience we offer - especially through the web browser (at https://cloudsmith.io) - was in need of a fresh coat of paint. They were right; our web interface is still largely a Django web app, tightly coupled to the back end, and you can see the Bootstrap showing everywhere. Not much has changed about our web app since Cloudsmith's early days, except for piling on more features.

It's a good time to re-examine the way customers use our web product. Honestly, the current UI is a little too much "let's throw everything at the user, and they can figure out what to configure." Instead, we should be guiding users through a coherent experience, using all the knowledge we have in our platform. Right now we're burying important information that to a seasoned Cloudsmither might seem merely interesting, but is actually critical for customers to get the most out of our tools.

Our default stance for Cloudsmith.io is to put the customer's experience first - and to value your time as a precious commodity. We're starting to think of Cloudsmith.io as not just a front end to our internals, but a critical product in its own right. The web experience needs to nurture new trial users, nudging them towards the fastest and best ways to get value. Things like setting up your first repo. Connecting your first upstream. Firing off your first downloads into a build. Setting up other users with the right permissions. All of this needs to be much easier than it is today. Even for experienced customers, there's more we can do to help you be more secure, more productive, and more in control of your software IP.

So, we've launched a project to basically rewrite 

 Well, a lot of it, anyway. I've seen the initial prototypes, and they're impressive. It's a cleaner look, and it's designed 100% for developer productivity.

We're still several months away from launching, but I'd like to invite customers and supporters to get in touch for a first look. If you're interested in trying the new cloudsmith.io, and you'd like to give us some feedback, shoot me an email today at 

Cloudsmith Blog

A Year to Remember: Cloudsmith’s Journey Through 2024 🚀🌍

GitOps Pipelines with Codefresh and Cloudsmith

"Cloud Native" - Why it matters?

How to Manage Your Package Promotion Workflows with Cloudsmith

Cloudsmith Navigator: The Trusted Guide to OSS Package Quality

Re-Imagining Cloudsmith.io

Hi. I'm the new CEO :)

Welcoming new leadership at Cloudsmith - a note from Alan Carson

Cloudsmith's Enhanced Security with Policy Management

Scaling Software Delivery: Continuous Delivery, Overcoming Challenges, and the Power of Cloudsmith

The Essentials of Cloud Package Management

Cloud-Based vs Cloud-Native: What’s the difference?