Teams and Access Controls

A short video to show how to set up teams and configure access permissions in an organization on Cloudsmith.

Emojis are finally useful for more than sentiment or sass. Cloudsmith Engineering can now be raised in emergency situations via a single emoji - SOS.

And it’s been used for the first, and so far only, time.

At Cloudsmith, we pride ourselves on our reactive (and in many cases proactive) support. We architected and built the platform with monitoring in mind allowing us to provide transparency of internal operations to you and us. We utilize numerous tools to help us provide the best package logistics experience to our customers. All our customers, all the time. Statuspage, Datadog, Intercom, Slack are all critical components to the Cloudsmith Experience just as Cloudsmith is a critical component in your software lifecycle.

Up until a few months ago, we ran support on a fairly ad-hoc basis. We have a passionate team in Engineering willing to stay up late and get up early for the exigencies of the service.

However, it was time to formalize the support function. We evaluated a number of products but ended up going with Opsgenie (sidenote; some of the competitors missed out on a sale because of non-responsive support… all we wanted was a trial extension). We implemented a sane rota with primary and secondary levels and put it into force.

This had the nice side-effect that productivity in Engineering went up. Now, the team not on rota could relax from the burden of support and focus on building product. And those active on the rota could relax, talk to customers and fix bugs, or achieve small tasks in-between times. It was a win-win for everyone.

But we wanted more.

Now, we had the power and ability to raise and contact Engineering in off hours if we needed to. What if a customer, in distress, could do the same?

We added emoji support for all Ultra level customers via Slack. Our customers can now directly raise a Cloudsmith engineer if they feel the service is underpowered or having critical issues.

To date, our service uptime is 99.99% and the last two incidents were only degraded service, highlighted early by our monitoring and immediately managed by the team feverishly rerouting traffic across regions to prevent the vast majority of our customers and our customer’s customers from noticing anything was sub par.

Only once has the SOS emoji been used in anger. A 

 behavioral issue that was blocking pipeline builds. Our dutiful customer raised the alarm, we rolled back a change from the previous day, resolving the issue from bed to deployment within about 30 minutes.

We thanked them.

They still have three challenges remaining.

Support via Emoji

Getting started with R Packages and Cloudsmith

A short walkthrough of getting started with R packages and Cloudsmith, including uploading an R package and then installing it.

Getting Started with R Packages and Cloudsmith

Custom EULA

It is simple to add a custom End User Licence Agreement for your package downloads in a Cloudsmith repository.


As a vendor, understanding your bandwidth usage is an invaluable insight into how packages are distributed across your user base and how specific users have grown over a timeframe.

As a user base grows from 10s, 100s, and 1000s of users and package downloads are many multiples of your total number of users, it's essential to understand the distribution of your bandwidth utilisation by a user (or more precisely, entitlement token's) to aid in the identification of token's that make up a large percentage of your overall traffic.

When providing an entitlement token to a user under a specific license, you trust an entitlement token will be used to download packages upon the agreed-upon terms. However, an increase in your total bandwidth may start off slow and continuously grow over several months until it's suddenly become a massive increase in your overall bandwidth. Understanding this usage and precisely where this growth originates helps identify where/where change occur and provides options to mitigate runaway bandwidth from specific entitlement tokens by changing how those specific users are managed.

Whenever a user downloads a package from a private repository using an entitlement token, the exact number of bytes transmitted from our servers to the user host is stored for that specific token as an individual log entry. At the end of each day, we calculate the total bandwidth for every user across all of our repositories containing one or more packages and store the result as a daily aggregated value representing bandwidth usage.

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.



Using the Cloudsmith CLI you can quickly and easily query the total bandwidth usage for your repository by running the following command with your organisation/repository.

The following screenshot shows an example repository contain a number of active and inactive entitlement tokens alongside the total bandwidth used. The statistics table provides a simple insight into min/max/average token usage.

You can also retrieve usage metrics for one or more specific tokens by providing a comma separated list of Entitlement token (identifiers)

cloudsmith metrics tokens cloudsmith/example --tokens=ZGCV58VqT8Sl

If you wish to drill down further into a specific period of usage for a token, you can supply am epoch timestamp for the 

 parameters to include only usage within that period. In this example, a single token is displayed for all of 2019.

Vendors Rejoice! Analyse your Bandwidth Usage

Using Cloudsmith to store and distribute any type of file

A quick walkthrough of how you can use a private Cloudsmith repository to store and then distribute any type of file.

At Cloudsmith, we want to be your “one central source of truth” for your dependencies and package management needs. And in keeping with this ideal, we are extremely pleased to announce that we have added fully configurable transparent Proxying and Caching support for Debian packages.

Well, in short, it means that you can now use your private Cloudsmith repository for all of your Debian package needs – whether that is your own private packages or packages that you need from public upstream sources. Your private Cloudsmith repository is all that you need to handle both.

If you request a package from your Cloudsmith repository, and that package isn’t present in the repo, then Cloudsmith will automatically check any upstream repos that you have configured and will then fetch (and optionally cache the package for future requests) from the upstream.

This brings you several important benefits:

. Your Cloudsmith repository is the only repository you need to configure on your clients. No more need to configure multiple repos, and handle multiple authentication credentials etc. Configure the upstreams once in Cloudsmith, and that’s it done.

. If you have cached packages and dependencies that you require in your Cloudsmith repository, then if the upstream repo goes down, is otherwise unavailable, or if the packages are removed then you can still access your cached versions. No more breaking of build or deployment process due to an unreliable upstream.

. You can view details on what specific packages were requested from the upstreams. Gain insights into what you have, and what’s missing – or who and what else you are currently relying on.

. Cloudsmith repositories are backed by a performant, global CDN. This means that your own packages and those cached from an upstream are delivered with the same low latencies and speeds. Going further than this, with edge nodes in almost all geographic regions, your users will experience this performance wherever they are located. Distributed teams all benefit equally.

. All of your packages and dependencies in one place means it’s easier for you to implement the controls and security policies that you need. Multiple sources mean multiple management tasks. Keep everything in one place and keep a tighter hold on what you have.

Well, it’s easy. In your Cloudsmith repository, you’ll see a menu item called “Upstream Proxying”. This is where we will configure our upstreams. Simply click the “Create Upstreams” button and select “Debian” to create a new Debian upstream:

You are then presented with the “Edit Debian Upstream” form. This is where we enter the details of the Debian upstream we wish to use.

We add a Name for the upstream, it’s URL and a priority weighting- in cases of multiple upstreams this will determine the order in which they are checked for a package.

We can then choose to fetch and cache any requested package (instead of just fetching them), and to verify the SSL certificates provided by the upstream. In addition, we can choose to enable this upstream for source packages too.

Next, we select the distributions and architectures that we wish to use this upstream for, and finally, we can add optional authentication headers (for private repositories that require authentication) and also optional arbitrary headers, if you wish to send something custom along with your request.

And that’s it, we have now added a new Debian upstream to our Cloudsmith repository.

Behind the scenes, Cloudsmith will now start to index the packages available in the upstream repository. The upstream will be ready for use as soon as the indexing is complete.

So now, for the next request for a package that isn’t present in this repository, Cloudsmith will check the upstream and fetch it if it is available there and also cache it in the Cloudsmith repo (if you enabled caching) for future requests. It’s that simple.

Debian upstream proxying and caching support is just another step on our path to providing you with the centralized controls, security, management and visibility that you need to enable a modern, high-velocity and DevOps-first workflow for your package management needs. It means fewer things to worry about, less exposure to change and most importantly....