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 

Cloudsmith Navigator: The Trusted Guide to OSS Package Quality

One of our core motivations in building Cloudsmith is to make software developers' lives easier. We want Cloudsmith to be one of those great products that feels intuitive and automates everything.

As we’re picking up more and larger customers, we’re seeing an increased need for migration tools. We want to make it as easy as possible for teams who are stuck using JFrog Artifactory, or Sonatype Nexus, or other legacy tools to move over to the joy of SaaS artifact management using Cloudsmith.

In theory, anyone can migrate their own repos and data to Cloudsmith, using our APIs, CLI, and webhooks. But we really want to make this 

So, we’ve established a new team at Cloudsmith called 

. The mission of Customer Engineering is to build migration and integration tools that extend Cloudsmith. This will include migration tools, GitHub Actions, and extensions to our Terraform provider.

We want to let the Cloudsmith community contribute to and extend the tools we build, so we’re going to make all the source code available in GitHub and invite anyone to make improvements, submit pull requests, and take these tools wherever they need to go.

Our first project is a Cloudsmith Migration Toolkit. The Toolkit provides repository structure mappings, upstream/remote source configurations, and ETL-style data migration, specifically targeted at teams migrating off JFrog Artifactory. The Toolkit will securely create your Cloudsmith repos, let you decide which Artifactory repos you want to migrate, transfer artifacts, and preserve metadata and versioning.

If you are interested in trying out the Toolkit, 

 (we just need your name + email address), and the Customer Success team will be in touch.

Coming Soon: Cloudsmith Migration Toolkit

The team at Cloudsmith is excited to build upon our past support and integration with Hashicorp Terraform to include managing teams, update repository settings, and manage services (API Keys) via the Terraform Provider Module. And we are an official Partner, check out the fancy handshake badge!

While Cloudsmith and Terraform are nothing new to each other, the capabilities continue to grow based on community and customer feedback.

For a few years now, Cloudsmith has included Terraform 

 capabilities to help manage both public and private modules or packages. Cloudsmith delivers on the promise of being truly universal and offering a variety of packaging formats in a consistent and secure way. Review the 

 has long been the industry standard for infrastructure and application provisioning via code.

Why not manage Cloudsmith with Terraform?

, users can quickly and easily provision Cloudsmith resources and realize the benefits of Infrastructure-As-Code for creating and managing repositories and access control.

Overview of the Cloudsmith Terraform Provider

 allows Cloudsmith users to automate the provisioning of resources using Terraform. New capabilities are highlighted below.

Users can:

Create and manage repositories, including 

Create and manage entitlement tokens, granting read-only access to end users

Create and manage services (API keys for machine-to-machine or programmatic access) for a Cloudsmith organization

Create and manage teams within a Cloudsmith organization

Create and manage webhooks for a given Cloudsmith repository

The trend to manage every aspect of the infrastructure lifecycle is expanding with each and every revision. Databases and database schemes are even being managed with Terraform and infrastructure as code. DevOps and Platform teams are attempting to realize the goal of a platform-as-a-service, and the Cloudsmith team wants to help everyone reach that potential.

provider "cloudsmith" {
api_key = "my-api-key"
}

data "cloudsmith_namespace" "my_namespace" {
slug = "my-namespace"
}

resource "cloudsmith_repository" "my_repository" {
description = "A certifiably-awesome private package repository"
name = "My Repository"
namespace = "${data.cloudsmith_namespace.my_namespace.slug_perm}"
slug = "my-repository"
}

resource "cloudsmith_entitlement" "my_entitlement" {
name = "Test Entitlement"
namespace = "${cloudsmith_repository.test.namespace}"
repository = "${cloudsmith_repository.test.slug_perm}"
}

Terraform plus Cloudsmith is a powerful combination. It allows you to automate the creation of your package repositories and associated access tokens in a controlled, reproducible way. Also, as you have now defined these resources as code, you can version them and treat them as you would any other source code that you have.

The Terraform Module Registry is the home for the validated Terraform provider; find out about the latest enhancements in the 

. If you like to test things out on your own, sign up for a 

 to realize the value and benefits of Terraform and Cloudsmith together!

Terraform Provider Enhancements


With the introduction of the Package Activity API and accompanying CLI command, you can now quickly and easily check your entire repository for packages' activity status or even take a detailed approach and view packages individually (per day/per package).

You can save on your storage costs by eliminating inactive packages and retaining only the packages you or your users derive value from storing and distributing via Cloudsmith.

The excellent news is that once you identify those inactive packages, you can make use of Automated retention/lifetime rules (available on the Velocity plan and above). These rules allow you to automatically manage storage for packages by deleting or moving packages that fall outside of the defined retention rules.

Assets can be expired based on the number of packages (count), size of packages (bytes), or by the number of days (time); however, to first create these rules, you first need to understand how your users are interacting with your existing packages. However, understanding when to delete the packages was challenging, until now!

Every package has an aggregated count of the number of total downloads for a given package calculated daily. A package is considered active when there have been downloads for that package for a given range. If there are no downloads during a specified period, then it's deemed to be inactive.

The easiest way to get started exploring these metrics is to check out the metrics command within the Cloudsmith CLI. Alternatively, to get more fine-grained metrics, you can implement a programmatic solution using our API or one of the API binding libraries published in various languages.

For example, to check if a package has ever been "active" and received downloads, you can request the "packages" metric for an entire repository and use the --inactive=true flag to display a list of inactive packages to identify candidates that will help you create a retention rule to automate the removal in future.

Using the Cloudsmith CLI you can quickly and easily query the total number of active/inactive packages for your repository by running the following command with your organisation/repository.

If you want to specify a specific package, you can also supply one or more packages as a comma separated string.

cloudsmith metrics packages cloudsmith/example --packages=ZGCV58VqT8Sl

Querying between a range is easy using ISO 8601 formatted datetimes. Supplying a start and finish helps drilling down to answer specific questions like:

Has package activity increase or decreased since last month?

Has the number of inactive packages increased since last year?

How many active packages has been added this week?

cloudsmith metrics packages cloudsmith/example --start=2019-01-01T00:00:00Z --finish=2019-12-31T00:00:00Z

Although the summary overview provides a general feel for the increase/decrease of inactive/active packages, it can be useful to drill down into what those packages are by using the 

 flags to identify what's been added or what can potentially be removed.

cloudsmith metrics packages cloudsmith/example --active-packages=true

The package slug has been omitted from these screenshots but when running the command you can use the slug to identify the package uniquely.

cloudsmith metrics packages cloudsmith/example --inactive-packages=true

Monitor your Package Activity and Save on Storage!

Webhooks, so what are they good for? Well, quite a lot as it turns out! Webhooks are great for integrating Cloudsmith with other systems that you use, by sending data or notifications to other tools in your stack and helping to enable automation across your workflows.

I know what you’re thinking, this sounds a lot like an API right? Well, not quite. Webhooks are almost like a sibling of an API call. So, what’s the real difference?

A webhook is what you would use to notify another system (i.e, not the same system that performed the API Call) that such an event had taken place.

When you make an API call to retrieve some information or perform an action, the API will typically check that you are authorised and then if so, perform the action or return the information you requested. A webhook, on the other hand, is a message that is pushed in response to a change or an event on a system.

So, if you used the Cloudsmith API to upload a package, if you were authenticated you’d then get a response from the API confirming your action was successful.

Cloudsmith webhooks can trigger on events that occur for packages in a repository, so for example, when a package has been uploaded, is synchronizing, has synchronised or has failed.

Here are some great examples on what you can do with webhooks to help automate different workflows.

You could use a webhook to notify your CI/CD pipeline when a new package has arrived at a Cloudsmith repository. So, for example, if you had a repository that you used for packages destined for a production environment, you could combine a webhook with repository access controls to control who was able to promote packages to production, and then use the webhook to automate the deployment process itself.

You can use a webhook to push a notification to a chat application such as Slack or Microsoft teams when any of the supported events occur. You can customise the message to include details about the package or provide a link to it. In this way you and your teams can stay fully notified about activity on your Cloudsmith repositories without having to manually log in and check.

You can use a webhook to push notifications to your monitoring and alerting platforms. You could, for example, then get notified and alerted if a specific package was deleted, and trigger further automated processes in response to your monitoring. In this way, your monitoring platform is “aware” of activity on your Cloudsmith repository, and can take action.

distribute your packages to your own customers

, you could create a webhook that notifies your mail system or CRM system that a new package has been uploaded to your repository. You can then automate the process of informing your customers that a new or updated package is available for them to download.

But really, all this is just scratching the surface. If a component of your stack is capable of receiving HTTP POST requests and can handle a JSON or Handlebars template payload, then you can receive and process a webhook. A lot of platforms offer out-of-the-box functionality for accepting incoming webhooks, but even if yours doesn’t, you can be confident that you can put something together quickly in most cases.

For more information, including details of the webhook payloads and a worked example, see our 

We've also written up another handy guide on 

how to configure Webhooks with Cloudsmith

And if you make something awesome that you’d love to show off, please do 

 – we just love to see what our users can create with Cloudsmith.

Level up your DevOps, expand your integrations, and have fun building great processes with our webhooks.

Repository Webhooks: Notifications for DevOps

At Cloudsmith, helping fledgling startups grow from a single person operation to enterprise-level organisations is a constant joy! In those early stages, startups need all the help they can get to survive, and even veteran organisations experience similar challenges when scaling up rapidly.

Cloudsmith can help with our self-service approach to managing and defining storage and bandwidth limits to keep costs under control while allowing you to scale when needed. After all, no one wants to be caught between an unexpected bill for overages or any interruption to their business, no matter how minor.

The fantastic news is that now you have a new tool in your arsenal, as you can track your bandwidth and storage programmatically via the Quota API. It's easy to miss an email when your busy or a prompt within the Cloudsmith UI (if you haven't needed to log in recently); but you will always want to know if you're near/over a limit or even if you're over-provisioned.

Now you can automate a solution that works for you using either our API or CLI to always stay on top of your storage and bandwidth limits.

Using the Cloudsmith CLI, you can quickly and easily view the usage, limits, and maximum allocation of bandwidth and storage for your plan.

cloudsmith quota limits your-organisation

Alternatively, if you want to view the entire history for your organisation:

Finally, to view the OSS usage for an organisation, you can add the 

 flag to any command to view only OSS limits and history.

If you identify a limit that is over-provisioned or quickly approaching a threshold, then you can quickly and easily adjust your limits at anytime within the Cloudsmith UI.

Organizations | CloudsmithCreating an Organization (Org) in Cloudsmith gives you the ability to configure access for teams, individuals and machines that map to your companies organizational structure. Building security and resilience into the management of teams and workflows is essential in today’s ecosystem. This is a qui…Cloudsmith Developer Hub

Additionally, if you wish to automate a solution, you can also check out the 

 or the Cloudsmith API Bindings (available in multiple languages) and connect it to your favourite CI/CD or monitoring service to alert internally within your organisation.

Track your Bandwidth & Storage limits with our Quota API

 is an awesome tool, created by Hashicorp, with a vibrant community of open source modules for multiple cloud providers. It’s not hard to understand why it’s a favourite amongst developers; especially when it's often faster at supporting new features than some of the cloud providers!

Terraform enables its users to manage components in their architecture, ranging from the configuration of the services used in their chosen cloud provider (such as 

Amazon Web Services, Google Cloud Platform, or Microsoft Azure

), to software run on those services (like 

). Terraform even supports configuring some SaaS services you may interact with (for example, 

Using Terraform to define your desired configuration means that not only will you offload the work of creating the components you need, but also make the creation of these instances reproducible, allowing you to create, update and destroy components of your architecture as needed, all with one command (and a review of the changes before executing them!).


To make modules created by the Terraform providers available to all Terraform users, Hashicorp runs the 

 which allows users to upload modules, making them publicly available to all Terraform users.

Cloudsmith's private module registry fully supports the 

, allowing users to access both private modules available via Cloudsmith and public modules via the public registry.

Cloudsmith's private module registry also enables developers to:

Share custom modules for managing infrastructure among their team

Utilize private modules in your organization without the overhead of managing their storage

Distribute private modules as a commercial offering

Make modifications to public packages while having control of how you publish them (publicly accessible, private to your organization or open-source)

Capture the exact state of modules you depend on at a particular version

Control (allow list/deny list) at an organization, repository, and module level

Getting started with Cloudsmith and Terraform only takes a few steps. First, you need to create a Cloudsmith account and a repository to which you can upload your modules (a terraform provider for doing just this coming soon!).

If you need to install Terraform, you can find a getting started guide on the 

.

Cloudsmith's private module registry should work with all supported versions of Terraform, however, we recommend using version 

. You can check the version you have installed by running:

For this example, we'll create a module which prints out "Hello, world!".

First, we need to create the directory which will contain the module:

 file, this is the entry point for your module and will contain the code required to generate our message. To generate this message we must add the following to the 

Now that we have the code necessary for our module, we need to package and upload it to Cloudsmith. To achieve that we need to make use of the *nix tool 

To ensure we don't upload some unnecessary files, we exclude your terraform state file(s) along with 

 which can contain authentication credentials.

The name of the terraform module is critical here, as the 

terraform registry API requires this specific format

, along with several other requirements that you should review when creating modules.

To upload the module to Cloudsmith, you can use either the application's UI, or the Cloudsmith CLI. For this example, we'll be using the CLI, which has steps for installation available 

With the CLI installed and configured to authenticate successfully with Cloudsmith, we can upload our module by running:

Once uploaded, you can view your module in Cloudsmith.

Cloudsmith provides fully featured Terraform module repositories on all plans, flexible enough for use whether you’re hosting public packages for a public or open-source project, or private packages for your company’s internal needs. We're extremely proud to be able to support the Terraform ecosystem with this tooling.

You can find further, context-specific information, including detailed setup and integration instructions inside each Cloudsmith repository.

Announcing Private Terraform Registry Support in Cloudsmith

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

Cloudsmith is all about giving developers the tools they need to deliver great code as efficiently as possible. And that includes ensuring that to the greatest extent possible they don’t need to learn new tools and approaches to get the full benefit of our platform.

we’re delighted to announce improved support for Rust and the associated Cargo package manager

. Specifically, we now support the upload of Cargo packages to the Cloudsmith platform using the native Cargo publish command.

Whilst we’ve supported Rust and Cargo for some time, until now uploading to the Cloudsmith platform has been either through the Cloudsmith UI or via the Cloudsmith CLI. Support for Cargo publish now means that developers can stay within the Cargo / Rust environment they know when pushing packages to Cloudsmith.

Below is a very short video that shows exactly how this works:

Native Cargo Uploads In Cloudsmith

Once there, of course, they are available within a private ‘single source of truth’ for software assets, that:

Can be managed, secured and controlled in a systematic way

Is available to teams and individuals within the organization anywhere in the world via a ‘web-scale’ cloud infrastructure

Can be distributed on a commercial/licensed basis if necessary on the same basis

Supports assets all common languages and formats (Rust and Cargo being just one of dozens of supported formats)

Our aim is to make getting to this point as simple and intuitive as possible for developers. We want to support existing workflows and existing environments, not replace them. So it’s important for us to ensure that for every format, publishing to the Cloudsmith repository can be done without having to use Cloudsmith itself.

This is one further step on that journey.

Announcing Native Cargo Uploads In Cloudsmith!

At Cloudsmith, our goal is to make it as easy as possible to get your packages into our system from where you can manage and distribute them according to your needs.

CircleCI is a continuous integration and delivery platform that helps teams release quality code, faster. They provide a mechanism for users to share code and libraries which can be reused across pipelines called "orbs".

Cloudsmith provides first-class support for CircleCI with our official 

. Using the orb, users can easily integrate publishing to Cloudsmith with their existing CircleCI workflows.

Full reference documentation for the orb can be found on the 

. This documentation is automatically generated from the orb itself and so is guaranteed to always be up to date with the latest release of the orb.

To use the orb you must first ensure you are using Circle version 2.1. At the top of your 

You'll need to configure authentication credentials for the orb. To do so, you can add an environment variable named 

 within the CircleCI settings page for your project:

The orb (for now) requires that you have already built the package you wish to publish. Assuming you're publishing a Python library (though the same process applies to any package type), you'll want to run 

Once built, we can use the orb to easily publish the package. The orb provides a number of commands to make this process simpler. We'll first ensure the Cloudsmith CLI is configured and installed, then after we've built the package, publish it:

Putting this all together, we end up with a 

Our official orb provides simple integration for the majority of standard CI usecases, but we know that it won't fit every purpose. For additional flexibility users can mix and match commands provided by the orb and/or use the Cloudsmith CLI directly.

For example, to use the orb to install and configure the CLI, but then use the CLI directly to publish to Cloudsmith, your configuration might look like so:

As always, if you have any questions about integration or would like some general advice, please 

Cloudsmith + CircleCI

What is Rust? What is Cargo? What are Crates?

Rust lang, or Rust, is a systems programming language, designed at Mozilla research, and intended to be a safer alternative to existing systems programming languages like C and C++, but still just as fast. Rust was originally started as a personal side-project by Mozilla engineer Graydon Hoare, but the company quickly and rightfully recognised its promise and began sponsorship of the project in 2009.

Rust quickly became a critical part of Mozilla's efforts to improve the performance and reliability of their browser technology as part of the Servo project. Since then, Rust has only grown in popularity and appeal, year on year, and for the last four years has achieved the coveted top spot for "most loved programming language" on 

Whilst Rust is maybe best known as a low-level systems language, the same properties that make it appealing for working close to the metal also make it appealing for many other use cases. Rust's memory-safety, ownership semantics, performance, and comprehensive type system (among others) combine to make Rust a very compelling choice in many fields of engineering.

Whether you're writing a device driver for an embedded System-on-Chip (SoC), an operating system, a layout engine for a web browser, a web application, a package management service (heh), or a library for use in the WebAssembly ecosystem, Rust probably has you covered.

Early on, the Rust community realised that for a modern programming language to be successful, it needs modern tooling to accompany it. To this end, various teams in the Rust community have concentrated on tooling, such that Rust is now widely regarded as having best-in-class tools in areas like build and package management; which is something that we (Cloudsmith) recognise, respect and adore.

Rust therefore ships with its own package manager called 

. Cargo is an all-in-one frontend for building, packaging and configuring your Rust projects. It can build and run your code (providing a developer-friendly interface to 

) and manages resolving and fetching any required dependencies (also known as "crates" in the Rust world).

Cargo can install dependencies from a remote registry into your local project for building, using a command like 

. Until April of 2019 the only choice you really had was the official, public registry at 

. Crates.io is maintained by the Rust team and is the default public registry for the Rust ecosystem. With the 

, Cargo now officially supports the use of registries other than crates.io, making it possible to run an alternative registry for the hosting of private or internal crates.

There are several equally fantastic reasons for running/using your own registry:

To develop Cargo packages internally and share them privately to other teams.

To distribute and deploy your own Cargo packages in a pipeline at your org.

To distribute Cargo packages as vendored software (i.e. maybe commercially).

To make modifications to public Cargo packages, without republishing publicly.

To mirror public Cargo packages, to isolate from uncontrolled registry events.

To capture the exact state of your dependencies at a particular version/release.

To control (whitelist/blacklist) the exact Cargo packages allowed for your org.

To keep track of the exact versions/releases of Cargo packages you have/use.

Cloudsmith blog