Getting Started with RPM packages and Cloudsmith

Dan walks you through using your private Cloudsmith repository for your RPM packages.

https://help.cloudsmith.io/docs/redhat-repository

Dan McKinney

Solutions Engineer

Getting Started with Debian packages and Cloudsmith

A short walkthrough of using your private Cloudsmith repository for your Debian packages.

https://help.cloudsmith.io/docs/debian-repository

Getting Started with Debian Packages and Cloudsmith

Getting Started with Ruby and Cloudsmith

A short demo of how to get started with RubyGems and Cloudsmith, including pushing a Gem to a private Cloudsmith repository and then pulling and installing the Gem.

https://help.cloudsmith.io/docs/ruby-repository

Getting Started with sbt and Cloudsmith

Dan walks through sbt support for publishing a package to Cloudsmith and integrating your private repo into a project to help you manage your dependencies.

https://help.cloudsmith.io/docs/sbt-repository

Getting Started with Python and Cloudsmith

Get started with your own private, secure Python repository.

https://help.cloudsmith.io/docs/python-repository

Getting Started with npm and Cloudsmith

A short walkthrough for getting set up with your own Private npm registry on Cloudsmith.

https://help.cloudsmith.io/docs/npm-registry

Create a Repository in under 60 seconds

See how quickly you can create a multi-format repository in Cloudsmith, both via the Website UI and the Cloudsmith CLI.

Create a Repository in Under 60 Seconds

At Cloudsmith, we are all about automation and we believe that first-class command line tooling makes up a significant part of that. With that in mind, we are continually improving the Cloudsmith Command Line Interface (CLI). This short post will guide you through installing / setting up the CLI and show you some examples of the things you can achieve with it!

The Cloudsmith CLI is built in Python atop the Cloudsmith API and as well as the API powering the CLI, we have designed the API so that it is fully compatible with 

, allowing us to generate bindings in more or less 

If you have Python set up already, then it is super simple to install the CLI from pip using:

This will install the Cloudsmith CLI itself and any required dependencies.
Once installed you can then configure the CLI it with:

This command will prompt you for your Cloudsmith username and password, and it will then retrieve your Cloudsmith API key and set up the required configuration and credential files automatically:

To check that it was all installed and configured correctly, use the command:

This will return the current user that the CLI is authenticating as:

Cloudsmith CLI Overview

Once you have the CLI installed and configured you can start to try out some of the operations. To get a list of the supported commands, just do:

There is a LOT you (or the systems you are automating!) can do with the Cloudsmith CLI, but rather than explore every single command here how about we start with what is sure to be a very common use-case - uploading (pushing) a package.

We can see above that the command will be 

, and you can get additional help and information on any command by using the 

OK, that makes more sense now! So to push an 

 package we need the push command, the repository owner (namespace), repository identifier, and the package file name! Easy:

cloudsmith push npm OWNER/REPO PACKAGE_FILE

Right, that works! The CLI has now uploaded the files, created the package and waited for synchronisation to complete (synchronisation is where we extract the metadata and files associated with the package, and make the package available for download).

Remembering that all Cloudsmith repositories are fully multi-format, i.e you can upload any of the package types that we support into the 

 repository, we can then push a Python package using the command:

cloudsmith push python OWNER/REPO PACKAGE_FILE

cloudsmith push cargo OWNER/REPO PACKAGE_FILE

I'm sure you're sensing a theme here... :-) . Some other formats (such as Debian or Maven) have additional requirements that change the command used, but help is always available using the 

The point is, it's simple, quick and easy! The whole idea of the Cloudsmith CLI is to 

 your automation, not get in your way. It supposed to make your life using Cloudsmith easier!

So what else can we do with the Cloudsmith CLI. Well, lots of things! Let's start by seeing how we can list the contents of a repository. To do this we use the command:

Again, it's Easy! It will probably come as no surprise at all at this point that the command to get a list of all repositories for an account is just:


And similarily, the command to retreive a list of all the Entitlement Tokens created in a repository is simply:


We've also got the following resources to help you:

Finally, we wish you well on your path to better software and better DevOps. 

Add Cloudsmith to your DevOps Toolkit

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.

Cloudsmith Blog