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.

This brings its own challenges. For one, we no longer have a single source of truth for our software assets. Dependent on location, we can’t be sure that we’re all looking at the same thing at the same time, or that the same controls and permissions are being applied.

In addition, whilst it might be practical to mirror to a handful of offices, that doesn’t help teams that are spread across dozens or even hundreds of locations - including, of course, those cloud-native processes we mentioned above.

Lastly, it’s just complicated and costly. On-premises solutions are already expensive to maintain, support and scale. That is why cloud services have been universally adopted in almost every other area.

Attempting to add in mirroring of software assets across multiple locations only adds to that burden, meaning the development organization has to invest significant resources into performing this task - resources that could and should be spent actually delivering software.

Ultimately, all these approaches impose a great deal of cost for little tangible reward. In addition, they really only kick the can down the road. What happens as new locations are added?

What distributed development teams need is this:

A ‘single source of truth’ for software assets,

 one that is available to any team or individual, anywhere on the planet, whilst maintaining the highest levels of performance for all.

The only place that source of truth can exist is in the cloud. But there is a world of difference between being ‘in the cloud’ and being ‘cloud-native’. The former does mean that security, control, auditing and provenance can be handled in a single place, and consistently across the entire organization.

Only the latter, however, can deliver outstanding performance to developers and teams wherever they are.

At Cloudsmith, we invest a significant amount of effort into ensuring that every member of a development team, and every process you integrate packages and dependencies into, are supported in this way.

We provide the ability to choose precisely 

 in the cloud your assets are stored (which you may want to control for legal and IP reasons, as well as performance)

All packages are distributed around the world by a blazing fast global Content Delivery Network (CDN).

We use edge-caching to optimize performance everywhere, and give our users fine-grained controls over exactly how long assets are cached for, all across the world.

Upstream proxying caches upstream packages, reducing the amount of external repositories our clients depend on and protecting software and servers from downtime and slowness of official main repositories.


Through a combination of these features and more, we believe that cloud-native private repositories don’t have to mean ANY compromise when compared to on-premises solutions, in addition to being so obviously superior for supporting distributed teams.

If you’d like to try Cloudsmith for yourself and find out why - sign up today at 

Supporting Distributed Teams With Cloud-Native Package Management

At Cloudsmith we’re proud to do things differently. And when it comes to customer support and success, our customers are delighted that we do.

Here’s the thing: in huge numbers of organizations, both in the Saas universe and beyond, 

. Anyone reading this who has tried and failed to get timely, meaningful answers from a vendor when things go wrong knows this is true.

And even if it is just a case of finding out ways to get the most value out of a Saas product we all know it can take a huge amount of time and effort (mostly our own) to make it happen.

So if being different means not actively sucking when it comes to helping our customers succeed, we’re guilty as charged.

Given that customer satisfaction is such an important metric for a Saas business, it is surprising that the default setting when it comes to customer support is somewhere between ‘low’ and ‘none’. After all, if our customers don’t get value from the product and can cancel at any time, we all know what happens next…

As always, fixing something starts with understanding what went wrong. We don’t claim to have thoroughly researched this phenomenon, but at the same time we watch, listen and learn - and notice what’s going on.

Here’s a best guess as to the factors behind a failing customer support function:

. But we sure do keep writing them. Worse, the rise of online documentation has only encouraged this trend. Writing the manual has become easier than ever! Never mind that the user would prefer a product that worked intuitively. That’s 

. So we revert to creating a sea of information that struggling users have to navigate their way through.

 A little like documentation, there’s absolutely nothing wrong with communities in themselves. In fact, just like documentation, they can be fantastically useful. But they aren’t an alternative to a properly resourced customer success function.

Customer support as a last line of defense

. This is probably the big one. Too many organizations now see customer support as a cost center: when the approaches above have failed, a real human being steps in before things get out of hand. This is a fundamentally negative view of the function, and negative things don’t get the focus and resources that perhaps they should. We see things differently.

Customer support and success are isolated from the business

. As businesses grow, specialization happens. That isn’t always a bad thing, but it often means that customer support suffers. An entire function of the organization becomes removed from the day-to-day business of product development, and as a result becomes worse (not better) at helping customers get the most from the product.

. Customer support is what happens when your product isn’t working (and yes, if it is too opaque for a user to get started without your help, it isn’t working). Is that really something to look at as a source of revenue? Perhaps you could make more revenue by making the product worse! Unfortunately way too many business models rely on ‘services revenue’ - and customers who won’t pay get poor support.


All these factors and more play a part. And they add up to frustrated customers. We know, because we hear these complaints frequently from new customers who arrive at Cloudsmith after giving up on one of the alternatives.

The purpose of this piece isn’t to talk about how great our service is, but nor will I pretend we don’t get told on a regular basis how much our responsive and helpful attitude to customers is appreciated. So let’s talk about how we do it.

...And How Cloudsmith Does Things DIfferently

It’s easy to talk at length about what is wrong. See above! But how do we fix things?

start meaning it, and act as you mean it, when you talk about how important your customers are.

If customers are important, start acting on it. Stop looking at customer support, and customer success, as a bolt-on, ‘responsibility’ or cost center. Look at it as perhaps the most important function in the business.

That means being responsive because you want to be responsive. Because every conversation is an opportunity to learn and improve. We see Cloudsmith as a ‘whole product’, and we see the conversations and interactions we have with customers as a part of that product. Not an extra.

Part of that, by the way, is an obsessive focus on making the product easy-to-use and as indestructible as possible. Prevention is better than cure. Cloudsmith is cloud-native because we wouldn’t wish the hassle of managing an on-premises solution on our worst enemy. Our motto is 

, because we know that when we automate we reduce the risk of problems caused by user error.

In other words, customer support and customer success are hard-coded into the product from day one.

Even so, things can go wrong. When they do, we accept that people don’t want to read a manual (even though, of course, we have awesome 

) or check with a community. They want to talk to someone, and they want to talk to someone who knows what is going on.

That’s why we don’t have a customer support team. 

We have an engineering team, who talk to customers every day.

We believe that the best people to help our customers use the product are the people who wrote it. Customers get the best support possible. We get the kind of insights around product usage that we never would through any other means.

To do that we open up channels of communication that might make others nervous. We are freely available on Intercom at any time. For customers who really want to get close we share Slack channels.

And because we automate everything, those conversations focus around how best to use the product and where best to start delivering value, rather than firefighting 24/7. So they are super productive for everyone involved.

Again, if we start from the customer being important, this feels normal. For those who start from the customer being a problem to keep at bay, then it seems more like insanity. Which one are you?

Ultimately, we want our customers to learn from us, and we want to learn from them. And that isn’t just about keeping the platform up and resolving issues around usage. It is also about delivering maximum value, and discovering what can be done with package management together.

That’s our approach. It’s how we see customer success differently. It’s why in the entire two years of our existence we’ve lost fewer customers than you can count on the fingers of one hand.. Yes, it helps that we aren’t a huge, unwieldy global organization. But we truly believe that our approach can and will scale.

In fact, it needs to. Because it is at the heart of the Cloudsmith promise.

Why We Do Customer Support Differently

At Cloudsmith, we are always looking for new ways to make our customers’ lives easier, more efficient and more highly automated. With this in mind we are extremely excited to announce that we have developed an official Cloudsmith Zapier integration!

Zapier is an automation platform that allows you to connect your favourite apps and services together (such as Stripe, Slack, Gmail and more). You can connect multiple apps together to automate tasks and you can do all of this without needing developers to build or code custom integrations - the simple interface is entirely point-n-click driven and is extremely easy to set up.

For example - maybe you have packages on Cloudsmith that you would like to sell commercially. Every time you get payment from a customer through your payment provider (Stripe, Shopify, Paypal etc), you could log into Cloudsmith, create an Entitlement Token in the relevant repository and then share that Entitlement Token with your customer. (For more information about Cloudsmith Entitlement Tokens, see 

OR - you could automate this entire process with the Cloudsmith Zapier integration!

Get started by logging into your Zapier account and creating a new “Zap”. A Zap is the name for the automated series of steps between your chosen apps that Zapier will perform.

Open the menu on the left and click “Make a Zap:

Choose the app that you want to use to “Trigger” this Zap, in this example we are going to use Shopify:

 - you will need to authorize Zapier to access your Shopify account after clicking “Continue”. This process varies depending on which payment provider / platform you are using, but for Shopify you are presented with a window to log into the Shopify platform and authorize Zapier. Other payment providers work similarly, or offer you the option to add an API Key.

Once you have authorized Zapier, you continue to set up the trigger event, in this case - specifying exactly what order conditions will fire this trigger:

You then test the trigger and it will pull in any orders from Shopify (or sample order data if your Shopify account does not have any paid orders yet):

Once you have this all completed, click “Done Editing” to move to the next step.

Click the "+" icon under your Trigger step, chose the Cloudsmith app from the dropdown list, and then Chose the “Action” that you wish to perform - in this case it is “Create Entitlement Token”:

You will need to authorize Zapier to access your Cloudsmith account, and you do this by adding your Cloudsmith API Key, which you can retrieve from 

Once you have entered your Cloudsmith API Key you then specify the details of the Entitlement Token that you would like to create. The only required fields are:

You can enter a Token Name manually or you can pull in output from your initial trigger step (such as an email address, customer ID or other identifying information from your Shopify order). For the Repository Owner and Repository you can select from the dropdown menus. In addition, you can specify a custom string for the Token itself (although if you don't then one is generated for you!)

You can optionally specify any restrictions you would like associated with this Entitlement Token, such as an allowed number of downloads or a valid to/from date.

In the example above, we will use the customer email address from the Shopify order as the Token Name, the order placement date as the Token Valid From date, and we will limit the number of downloads to 10.

You can then click “Continue” to test and review your selections, and then click “Done Editing” to complete this step.

At this point, your Zap is now set up to create an Entitlement Token in your specified Cloudsmith Repository for every complete Shopify order that you receive.

If we now create an order in Shopify, and then check the repository that we specified in the “Create Entitlement Token” action, we can confirm that the Entitlement Token has been created, with the details from the Shopify order:

You may wish to add an additional output step to the Zap that could, for example, email the Entitlement Token to your customer directly or maybe use an additional Zapier app to integrate with your chosen mail or CRM platform - This would enable you keep a track of Entitlement Tokens so that you can automatically disable them using the “Disable Entitlement Token” action in the Cloudsmith Zapier integration (perhaps if a customer unsubscribes or cancels)

We hope that this demonstrates how simple it is to automate a payment and token creation workflow for a Cloudsmith repository. There are many integrations available on the Zapier platform and we are pleased to be able to offer this official Cloudsmith integration as an option for our customers that use the Cloudsmith platform for distribution. As always, if you need any help, guidance or additional information please just 

 and we will be happy to work through it with you!


Vendors Connect. Powering digital distribution with Zapier & Cloudsmith.

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!

We are proud to announce the availability of Cloudsmith for CocoaPods.

One of the key attributes of the Cloudsmith platform is 

. We think it’s important that you can use Cloudsmith to manage packages and dependencies no matter what format they are in.

Taking this approach means distributed development teams have a single source of truth for 

 their software assets, and can store, share and secure them all in exactly the same way and in the same place.

It also means that other processes within the DevOps stack only need to speak to one partner rather than many, with a consequent reduced risk of things going wrong.

faster delivery pipelines, less broken builds, happy customers

To ensure that Cloudsmith is and remains a ‘universal’ package management solution, we continue to add formats and extend the scope of the platform. Hence the launch today of our support for CocoaPods.

 is the dependency manager for Swift or ObjectiveC packages (or Pods in this context) used within Cocoa projects. And 

 is the framework within which MacOS and iOS applications are developed.

As a result, Cocoa and CocoaPods are popular. 

In 2019 Swift was the 6th most loved programming language in the Stack Overflow developer survey

 and the 10th most active language on GitHub.

It is also commonly used alongside other formats and languages (no surprise for a framework focused solely on MacOS and iOS) so being just one of many popular formats supported by Cloudsmith really matters.

It’s easy to get control of your Pods. In fact it only 

takes a minute to set up a private repository

 with Cloudsmith. The short demo video below should help you get started:

Getting Started with CocoaPods and Cloudsmith

This short demo shows how easy it is to get started with your own private CocoaPods repository.

Then your entire team can enjoy cloud-native, secure and universal package management - with none of the hassles associated with managing an on-premises solutions.

Taking the Cloudsmith approach allows development teams to:

Develop Pods internally and share them privately to other teams

Distribute and deploy your own Pods in a pipeline at your org

Make modifications to public Pods, without republishing publicly

Mirror public Pods and isolate from uncontrolled upstream issues

Capture the exact state of your dependencies at a particular version/release

Control (whitelist/blacklist) the exact Pods allowed for your org

Keep track of the exact versions/releases of the Pods you have/use

deliver all the benefits of Cloudsmith that are already enjoyed by development teams all over the world today

 and start hosting and distributing your Pods with Cloudsmith!