By submitting this form, you agree to our 

Rust team's announcement of the 1.68.0 version of Rust

, Cloudsmith is happy to announce our support for the new "sparse" registry protocol, which has been stabilized as part of version 1.68.0.

Cargo is the package manager for Rust, a programming language empowering everyone to build reliable and efficient software. Cloudsmith customers who migrate to the new beta "sparse" registry implementation will dramatically improve the speed and reliability of their builds.

What's changed with Cargo's sparse protocol

Cargo's "sparse" registry protocol defines a new mechanism for communication with remote registries such as crates.io and Cloudsmith. The sparse protocol switches to an HTTP-based transport from the previously supported (and still default) Git-based transport. The Git-based protocol works by cloning a repository that includes JSON metadata for 

The Git-based method of serving the registry has several advantages, including:

Crates.io could rely on GitHub to store metadata, offloading some infrastructure requirements

Incremental updates (determining what's changed) are trivial with Git

Git has a well-understood API that allows for simple integration with other tooling

However, because Git can be highly resource intensive and because Git expects repositories to maintain a clean history over time, this approach began to fail for providers as repositories grew in size. Cloudsmith customers saw this impact, as did the main crates.io registry users. To deal with the problems before they got out of control, The Cargo team implemented an HTTP-based protocol that Cargo could use to pull crate metadata from registries (either public or private).

This new "sparse" protocol allows Cargo to fetch package metadata via simple HTTP GET requests that return JSON for 

 the packages that the client requests. This means:

Only metadata for packages that the build uses need to be pulled

Registries no longer need to maintain long-lived state (git repositories) to serve to clients

HTTP caching and other techniques can be used to speed up performance dramatically

 larger sets of packages due to no longer needing to deal with them all at once

Migrating to the new sparse registry implementation

We recommend Cloudsmith customers migrate to the new beta "sparse" registry implementation as soon as possible. Customers with 1000s of packages in their registries will see a dramatic improvement in the speed and reliability of their builds. The only migration requirement is that you're using Rust 1.68 or nightly.

Please have a look at the documentation in your repositories for setup instructions.

Deprecating support for the Git-based method

It is paramount to Cloudsmith that we maintain a performant and reliable platform for our customers. To ensure we do so for Cargo users, we intend to implement a limit on the number of packages a customer can have in a single repository, and to deprecate support for the Git-based protocol later this year. Currently, the sparse protocol is planned to become the default for crates.io in the 1.70.0 release coming in a few months.

Paddy Carey

Principal Engineer

Experience faster, more reliable builds with Cargo's new sparse registry protocol

The root cause of many vulnerabilities is memory corruption from software written in memory-unsafe languages like C and C++.

The responsibility to stop memory corruption errors is left to the developer in C and C++ and they are often hard to catch. You fix up one memory vulnerability and another one appears.

We can eliminate these vulnerabilities by moving software away from C and C++.

 advise and encourage organizations to move away from memory unsafe languages.

OpenSSL, a crucial C software library found in Linux that implements the TLS protocol, is a good case study in memory vulnerabilities. It has suffered from a number of vulnerabilities due to memory corruption, including:

, found in 2014, allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL.

The NSA recommends C#, Rust, Go, Java, Ruby and Swift as possible alternatives to C and C++.

An important feature of all the memory-safe languages that the NSA recommends is that they have a package manager. Cloudsmith's cloud-native artifact repository supports over 28 different types of languages including 

 to help you with the transition to a memory-safe language.

Memory-safe languages- who is the obvious successor to C and C++?

How do we transition Legacy systems from C and C++?

In C and C++ the memory is allocated to all the variables of a program automatically during compile time. The stack is used for static memory allocation like local variables. Dynamic memory is allocated during runtime on the heap when the size of the memory is not known e.g reading in data. C and C++ developers need to manage their dynamic memory by allocating, deallocating memory and checking for potential memory issues.

Managing your memory and assigning data is where memory vulnerabilities can occur.

Buffer overflows are the most common type of memory corruption in C and C++ and are one of the top vulnerabilities used by attackers.

A buffer overflow occurs when you allocate memory of a certain size but the data you put into it is larger than the buffer has room for. This causes the program to write past the end of the buffer or array and corrupt the extra memory. This vulnerability can be triggered under certain circumstances e.g. unexpected user input.

A buffer overflow attack exploits the buffer overflow vulnerability. This attack can lead to the following:

unauthorized memory being accessed in an information leak attack e.g. Heartbleed in OpenSSL,

modify program code in a code corruption or control-flow hijack attack or

Protections in C/C++ without moving to another language

There are a number of things that can reduce the risk of memory corruption in C and C++, including:

Checking that the allocation of memory succeeded.

Dynamically allocate memory rather than statically when you don't know the size needed.

Defensive programming where you always assume the worst by checking any input including return values from functions.

Using managed buffers and strings rather than raw arrays and pointers in C++.

Using safe functions that include buffer overflow protection e.g use 

The C++ Core Guidelines advise against using 

 directly for creating dynamic objects in favor of smart pointers through 

 for reference-counted multiple ownership.

Heap scanning technologies to improve memory safety of C++.

Operating system kernel settings like ASLR and stack canaries.

Why mitigations against memory vulnerabilities aren't enough

Most of the responsibility to stop memory corruption errors is left to the developer in C and C++ and defenses in the compiler/kernel e.g. ASLR, stack canaries, can be circumvented by attackers. If you are lucky, the program will crash during testing, exposing the memory issue, but these bugs can go under the radar only to be found by attackers when they are running.

 that prevent it from improving its memory safety including tech debt and its commitment to backward compatibility.

Memory corruption in C or C++ has gone on for more than 30 years and continues to be one of the top vulnerabilities in real-world exploits. This is what has driven the NSA to encourage organizations to shift to using memory-safe languages.

Languages such as C#, Go, Java, Ruby, Rust and Swift use built-in safety mechanisms that minimize the likelihood of memory corruption vulnerabilities like buffer overflows.

It doesn't mean that there are no security vulnerabilities in programs developed in these languages but it eliminates a whole class of vulnerabilities.

Languages, like Java, C#, Python and Ruby are interpreted languages. The source code is not directly translated by the target machine. Instead, first, the source code is compiled into a virtual language and then it is interpreted by a VM.

Well-written C and C++ code will generally run faster than well-written code in interpreted languages mostly because they are statically-typed languages compiled to machine code.

Go and Rust are both performant open-sourced, compiled languages that are memory-safe alternatives to C/C++.

The garbage collector manages the allocation and release of memory for an application. In garbage-collected languages (e.g. C#, Go, Java, Ruby and Swift) developers don't have to write code to perform memory management tasks.

C and C++ don't use garbage collection for memory management which improves performance at the expense of security and usability.

The Rust language does not perform garbage collection and instead uses a 

. This allows it to be more efficient and performant than other memory-safe languages but at the expense of usability.

Who is C/C++'s successor? Is it all about speed?

Speed isn't the be-all and end-all in programming.

Optimizations in interpreted languages, powerful chips, cheap infrastructure and the development of performant languages have reduced the need for the speed that C and C++ can achieve. Security, usability, team experience and development time are often more important considerations.

Let's hear about some of the contenders for the C/C++ throne:

Java and C# are pretty fast and have made significant speed increases in the last few years. On top of that Java and C# have comprehensive tooling which leads to a 

really impressive developer workflow at 15hrs/16hr

 to merge a PR compared to the average 40hr. The same study showed that C++ programs took on average 140 hrs to merge a PR.

Go is a good all-rounder with speed and ease of use. Go compiles to machine code, has more modern features, simpler syntax, and is easier to write than C/C++.

But if we talking about applications where speed is the priority- Rust is a memory safe language that is 

 but it comes with a steep learning curve.

How do we transition legacy code from C and C++

There are lots of alternatives for developing new software in memory-safe languages but migrating billions of lines of legacy C/C++ code is a huge task.

Google launched a new programming language called 

. It’s an experimental successor to C++. Carbon is not fully memory safe but it has a path toward achieving robust memory safety.

The primary purpose of the Carbon language is to have performance similar to C++, bi-directional interoperability with C++ and migration from existing C++ code.

 using Rust if it is possible to do so. Many large C++ codebases use features incompatible with Rust making the migration process difficult. This is where Carbon makes sense.

A likely path off memory unsafe programs is to find the most problematic and popular C/C++ programs and replace them 1 at a time.

Rust is now in the Linux kernel- this opens up a lot of possibilities for moving off C and C++ code. One possibility is to replace the use of OpenSSL, a C program that implements TLS and SSL protocols, that has suffered from a number of memory vulnerabilities with 

C and C++ lack guardrails around memory which have led to too many exploitable memory vulnerabilities over the last 30 years. These bugs can be completely eliminated by moving to memory safe languages, like the NSA recommendations of, C#, Rust, Go, Java, Ruby and Swift.

Migrating billions of lines of legacy C/C++ code will be a huge task but pathways exist to make this happen. Who knows, maybe the new Carbon language will develop some nice tools for migrating some of this code without much intervention.

The march has already begun- worries about security, less skilled C/C++ engineers, performant alternatives and trends in software development mean there will be less and less C and C++ code in the world over the next decade.

Cloudsmith supports memory-safe languages

Ciara Carey

Solutions Engineer

Could 2023 be the year of memory safety?

Why is Ruby such a popular programming language for the Cloud? What exactly is a Ruby Gem, or Ruby on Rails, and how do these relate to Ruby itself? And how does and Organization go about hosting their own Ruby Gems? Come with us as we dive in and explore!

Ruby is an open source, interpreted, general purpose programming and scripting language. It was developed and first released by Yukihiro "Matz" Matsumoto in 1995. Ruby is object-oriented in nature, and this lends to the reusability of code as objects, which in turn increases the speed of development.

Though Ruby has been around for almost three decades, it still maintains popularity as one of the preferred languages for web development, static site generation, DevOps, and automation. The ability of Ruby developers to quickly and easily set up a web application or site using Ruby, with simple and readable code, speaks to the sheer versatility of the language.

An important secret weapon in Ruby’s popularity for web development is Ruby on Rails. Ruby on Rails, first open sourced by David Heinemeier Hansson in 2004, combines Ruby with a web application development framework called Rails. Ruby on Rails includes a great deal of boilerplate Ruby code and standardized conventions for tasks like standing up a web server, communicating with a database, sending and receiving messages, rendering HTML templates, and even securing against common web attacks. All this utility baked right into Ruby on Rails makes it a chosen web framework for full-stack developer productivity. It’s no wonder this combination is utilized in some of the most popular sites on the Internet, including GitHub, Shopify, AirBnB, Twitch, Hulu, Bloomberg, and Instacart.

Ruby can be packaged in shareable units of code called Ruby Gems. Most languages have a standardized package format, so that devs aren’t stuck reinventing the wheel. Plenty of reusable programs and libraries exist as Ruby Gems (also known as gems), and the package manager for handling the structure, packaging, download, and installation of gems is also called RubyGems.

The general structure of gems is as follows:

You can read more about this structure in the “

” article at RubyGems.org. To summarize, there are three main elements in a gem:

(including tests and supporting utilities)

 file that contains metadata about the gem (version, title, author, etc.)

As with most popular programming languages, alongside a package format exists a public repository for sharing OSS packages with the Ruby Community; namely, 

 . As of this article’s writing, there have been over 1.08 billion downloads of gems from RubyGems.org .

Hosting your own RubyGems Repository (the Easy Way)

As a Ruby developer, you probably already understand the importance of being able to share your Ruby code for efficiency, reuseability, and standardization. However, if you’re in an Organization with private code that cannot legally be shared in public repositories, how do you go about maintaining your developer team productivity while still preserving your intellectual property?

 is an excellent Cloud-native SaaS artifact management solution for this purpose. We take the hassle out of hosting your own repository on servers you have to patch and maintain. We offer support for gems, as well as 28+ package formats; we even allow you to host 

! Also, every artifact uploaded to our platform is highly available in 225+ points of presence around the World, thanks to our 

 (PDN). If you’d like to learn more, feel free to check out our Ruby Gems repository 

If you’d rather try Cloudsmith for yourself first, we also offer a 

, no questions asked and no credit card required.

If your development team would like to leverage the power of RubyGems.org in your own private highly-available Cloudsmith repository, we now offer support for Ruby Upstreams! You can set RubyGems.org as your upstream source for your Cloudsmith repo, and then only set your Cloudsmith repo as your single source of truth on endpoints and pipelines. Your Cloudsmith repository will not only host your private gems, but also any gems from RubyGems.org that are requested and installed by your development team. All of these gems and dependencies will also be cached in your Cloudsmith repository automatically in the background. Now, even if there is an outage or performance issues with RubyGems.org, your Cloudsmith repo will remain available and your Production pipelines and deploys will not be affected.

Just a heads up that our Ruby Upstreams are currently in Public Beta (August 2022), so we'd greatly appreciate your feedback if you hit a snag. We take feedback 

seriously, as it directly helps shape our roadmap to building a better Cloudsmith!

You can read more about setting up Ruby Upstreams in our 

Ruby, Ruby Gems, and Ruby on Rails are all popular tools for developers, be it web development, automation, data processing, or even standalone desktop apps. Using an artifact repository like Cloudsmith to host your Organization’s gems will help your dev team stay productive. Using a Cloud-Native solution like Cloudsmith takes the headache out of managing another service, and lets your team focus on your core application, service, or mission. Now with Ruby Upstreams, you can combine the power of a highly-available private repository with the plethora of OSS gems on RubyGems.org.

 of Cloudsmith today, and come find out for yourself what all the fuss is about! 😉

If you prefer a video guide, here's a short video on getting started with Ruby and Cloudsmith:

Getting Started with Ruby and Cloudsmith

If you'd like to explore other package formats we support, check out our other articles in this series below:

Lee Skillen

Chief Technology Officer

What is Ruby?

We’ve all been there. You’re getting ready to perform some work that requires installing a PowerShell module on some servers. Or, your Production pipelines are suddenly full of red X’s even though you’ve tested your code extensively. You test it in your own PowerShell prompt locally, and are greeted with the following message:

"Powershell gallery is currently unavailable... please try again later"

You open up a tab to browse to the PowerShell Gallery page, and another tab to check Twitter to see if others are experiencing the same issue:

Unfortunately, the PowerShell Gallery is currently experiencing an outage... we are currently working to resolve this as soon as possible and will provide updates as available...thanks
— Sydney Smith (@sydneysmithreal) 

Yup. That was me too, just a few weeks ago. 😱😱😱😱

The PowerShell Gallery we know and love can sometimes fail you in the most inopportune moments. Your mission-critical code needs the ability to withstand outages like this, while still ensuring you are still pulling down the latest versions of modules.

Of course, we acknowledge and appreciate The PowerShell Team, who work tirelessly to keep the PowerShell Gallery up, and the site abides by a Microsoft [

] that is very clear about no guaranteed uptime.

However, what if we could find a way to protect ourselves from outages like this with a more highly-available option, without introducing too much complexity? Well my friends, we may have just the thing for you here at Cloudsmith! 😉

In this article, I’ll break down the following steps in this process for you:

Create a NuGet Repository (aka repo) on Cloudsmith

Configure this repo in your PowerShell console

Use Save-Module to pull down a few PowerShell modules

Push these modules up to your Cloudsmith repo

Install these modules locally from your Cloudsmith repo

PowerShell code examples will be provided for your convenience.

As a bonus step, I’ll introduce you to 

. Upstreams may as well be “The Easy Button” for setting up a PowerShell Gallery backup repository, as they remove the need for you to pull packages from the PowerShell Gallery and push them up to your Cloudsmith repo.

How to create a NuGet repository on Cloudsmith

I’ll outline the process for setting up a NuGet repo on Cloudsmith here, but believe me when I tell you this can take as little as 60 seconds! Don’t believe me? Are you a visual learner? Check out this video where I show you.

From Zero to Repo in 60 Seconds

Sign up for a trial account on Cloudsmith. It only takes a few seconds, and you’ll receive an email invite that you can then accept.

If you want to keep it even simpler, you can just use one of the Social Sign-On links to the right. For example, since I’m already logged into my Gmail account, I can simply click the “Google” sing-on link, and accept the use of my Google account for authentication.

You’ll now see the message above when logged in. Click the green “Create New Organization” button and fill out the fields to create your organization.

Click the “Create” button, and in a few seconds, your organization should be ready to use.


Click on the plus icon (+) at the top right corner of your screen, and select “New Repository”.

Fill in the fields above, and click “Create”. In a few seconds, your new Cloudsmith repo should be ready!

But wait, we did say earlier that we wanted to set up a NuGet repo specifically, didn’t we? Well, this is one of the many unique features of Cloudsmith. Think of this as your “Everything” repo. Our Multi-Format Repository feature allows you to store up to 28+ different package formats in the SAME repository! You can check out more information in our article: 

Modern Tech Stacks Need Multi-tenant Repositories

Multi Format Repositories

A video on Cloudsmith's multi-format repositories.

In order to authenticate to your new repo from your PowerShell console, we’ll need to grab your API key from the web portal.

At the top right corner of the window, click on your username, and in the resulting drop-down menu, select “API Settings”.

You’ll now see your API key in the field above. Click on the paperclip icon to copy this to your clipboard, and save this key ins a secure location locally. You’ll need this for later steps.

How to configure the Cloudsmith repository in your local PowerShell console


Now, let’s switch to your PowerShell console to add your Cloudsmith repo locally.

We’ll need to define some variables first.

In the above code snippet, you will need to populate the `YOUR-API-KEY`, `YOUR-ORG`, and ‘YOUR-REPO-NAME` values accordingly. Next, we are building your unique URI for your Cloudsmith repo. Also of note, this URI is unique for NuGet. This is to ensure that Cloudsmith presents your local console with the correct metadata associated with a NuGet feed.

We are then creating your custom `PSCredential`, which includes your encrypted API key in order to authenticate against your private Cloudsmith repo.

We can now use the above repo URI and credential to finish configuring your Cloudsmith repo in your local console.

Now, you can run the `Get-PSRepository` command to see your Cloudsmith repo has been configured properly.

Push a PowerShell Module up to the Cloudsmith repository


We will now push a module to our new Cloudsmith repo. For this example, we’ll save a sample module to our local directory first:

Now, we’ll push it up to our Cloudsmith repo:

You can now see the PowerShell module has made it into your Cloudsmith repo by browsing to your repository:

Installing the PowerShell Module from your Cloudsmith repository


In order to confirm that a working version of the `Invoke-CommandAs’ module has made it into your Cloudsmith repo, we can go ahead and install it from the repo to your local workstation:


You can confirm the module has been installed by running a `Get-Command` against it:


Setting up a NuGet Upstream with Cloudsmith


As you’ve seen, the process of setting up a Cloudsmith repo and pushing and pulling PowerShell modules from it it quite simple. But what if I told you that you didn’t even need to populate your Cloudsmith repo with the modules you needed ahead of time?

This is where Cloudsmith Upstreams come in. You can set the PowerShell Gallery as an Upstream source for your Cloudsmith repo, and then you can simply begin installing any module available in the PowerShell Gallery from your Cloudsmith repo. As an additional bonus, these modules will automatically be cached in your Cloudsmith repo as well. This means that the next time the PowerShell Gallery goes down, you can continue using your Cloudsmith repo in your Production tasks and pipelines without missing a beat.

Set Up PowerShell Gallery as an Upstream


Browse to your repository, and near the bottom of your left sidebar, click on the link to “Upstream Proxying”:

Now click on the “Create Upstream” button, and select “NuGet” in the drop-down menu:



Fill in the fields as below, and be sure to leave the “Cache and Proxy” option selected; click “Create NuGet Upstream”:


Your Upstream is now configured, and you can begin installing PowerShell Gallery modules from your Cloudsmith repo, without the need to push them up first.

Let’s try this out by installing `PSWindowsUpdate`, a module we know isn’t in your Cloudsmith repo yet:

You can confirm the module has been installed by running a `Get-Command` against it:

In a few minutes, you’ll see that the `PSWindowsUpdate` module has also been cached in your Cloudsmith repo. The next time you, a colleague, or a pipeline task installs this module, it will come directly from the Cloudsmith repo, without needing the PowerShell Gallery at all.


 During your 14-day free trial, you’ll be able to use Upstreams without any limits. After the trial period, full-transparency, Upstreams are a paid feature if you’d like to continue using them.

So there you have it; not only can you have your own highly-available PowerShell module repository on Cloudsmith, but it’s relatively quick and easy to do so as well.

Again, if you are a visual learner, most of the material covered in this article was also presented at the PowerShell & DevOps Global Summit 2022; the video of this talk is here:

Is it Down Again? PowerShell Gallery Outage Mitigation Strategies by Adil Leghari

If you are curious about the NuGet package format, we’ve got you covered. We did a deep dive on NuGet here:

Or watch our to NuGet and beyond webinar below:

Webinar: To NuGet and Beyond: NuGet Ecosystem & Upstream Support at Cloudsmith

Hopefully, this article has shown you that hosting a NuGet repository for your PowerShell modules is no longer a slow and complex task. We look forward to seeing what you build with our platform, and please feel free to reach out with any questions.

And remember: Be Awesome, Automate Everything!

The PowerShell Gallery is Down Again... Now What?

At Cloudsmith, our mission is to be the universal package management solution for teams and enterprises. As a result, we continually expand and improve the package formats we support. We are delighted to be able to introduce support for 

public and private Conda package repositories

In this article, we will help you to understand:

The difference between Anaconda and Conda

Conda is a multi-platform open-source package management system. It was initially created to solve package management problems for Python data scientists and is now a popular package manager for Python and R packages, but you can also use it to manage packages for any language. Like all package management systems, Conda helps you create, find, and install packages you need.

Conda is also an environment manager. Suppose you need to use a package that requires a different version of Python. In that case, you can easily set up and switch to a development environment using that specific version of Python without needing to change the version of Python you use in your usual environment.

Conda started as part of the Anaconda Python Distribution but gained popularity on its own for things other than just Python and R package management and was then spun out as a separate project under a BSD licence.

A Conda package is typically a compressed tarball file (.tar.bz2) or, from Conda version 4.7 onwards, it can also be a .conda file. The .conda file format was introduced in conda 4.7 as a smaller and more performant alternative to a tarball. The tarball or .conda file usually contains:

Cloudsmith Blog

Experience faster, more reliable builds with Cargo's new sparse registry protocol

Could 2023 be the year of memory safety?

What is Ruby?

The PowerShell Gallery is Down Again... Now What?

What is Conda?

What is NuGet?

Getting Started with Terraform Modules and Cloudsmith

Improvements to Dart Package Support

Package Management for Gaming Software Development

Private Package Repositories Part 1: What’s a package again?

Track your Bandwidth & Storage limits with our Quota API

Multi Format Repositories