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. Remember - 

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 