Getting Started with Maven and Cloudsmith

A short demo of how to get started with Maven packages and Cloudsmith, including deploying a Maven package to Cloudsmith and then downloading it as a dependency.

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

Dan McKinney

Solutions Engineer

The following is a true story. It doesn’t have a happy ending.

Horrors lurk beneath the trap door, for there is always something down there, in the dark, waiting to come out...

The Thing Upstairs glares across the conference table, already knowing the horrible truth, “What license does it have?”

Berk confidently replies, “GPL version 3.”

Berk is an experienced software developer at a well-known consultancy firm, TrapDoor Inc. He’s worked his way up the ranks, paid his dues, and has been given his first solo project.

A customer has asked TrapDoor Inc. to architect and build a software tool. The problem specification is well-defined, but the solution design, architecture, and implementation details can all be decided by Berk.

The high-level design gets approved, and Berk gets to work. The agreement with the customer is to release often and early as they too are a software consultancy and can run tests internally and externally on their customers’ sites.

After about five weeks of development, the first alpha is released.

A week after that, the third iteration is released to much fanfare. Good, steady progress is being made.

Only then does The Thing Upstairs stir and decide to code review Berk’s solution. The findings are shocking. Berk’s solution relies heavily on an open-source project with a copyleft GPL v3.0 license.

Copyleft is the practice of granting the right to freely distribute and modify intellectual property with the requirement that the same rights be preserved in derivative works created from that property.

Berk has spent seven weeks writing logic that is attached to the original license, not fit for commercial handover, and now likely being run illegally on customer sites, without the proper license or attribution.

Worst of all, the original source code for the dependency was copied into a TrapDoor Inc. repository and modified with Berk having explicitly deleted the license file.

Little could be done without a page-one, clean-room rewrite, using a dependency with a more permissive license. But we’ll never know. This story doesn’t have a happy ending. Trust was lost. The six-figure project was canceled. The customer refused to pay.

All because Berk didn’t think licensing was important.

Alan Carson

Co-founder and Chief Strategy Officer

DevOps Horror Stories: Software License to Kill

In keeping with our vision of offering a universal feature set across all the package formats we support, we are delighted to announce that we are now offering configurable upstream proxying and caching support for 

As we touched upon when announcing the same for Debian and 

 packages, there are a lot of reasons why this is a really 

, so instead of going over those again, let’s jump straight into how you can set this up in you Cloudsmith repository.

We don’t think that we could have made this much easier to configure (but, of course, we would love to hear 

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 “RedHat” to create a new RedHat upstream:

You will then see the “Create RedHat Upstream” form:

You just need to add a Name for the upstream, the upstream URL, and a priority weighting – If you have multiple upstreams this will determine the order in which they are used.

We can choose to fetch and cache any requested package (instead of just fetching them), and to verify the SSL certificates provided by the upstream. Then, we select the individual distribution for this upstream.

Optionally - we can also add a GPG key, if required, for package signing, authentication headers for private repositories that require authentication and also some arbitrary headers if you wish to send something custom along with your request.

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

So now, the next request for a package that isn’t present in this repository will be passed through to the upstream and the package fetched it if it is available there. If you also enabled “fetch and cache”, the package will be cached in your Cloudsmith repo for any future requests.

By adding Redhat upstream proxying and caching, we are moving forwards towards our goal of being the most universal package management solution for your development, deployment and distribution workflows. We would love you to join us on this journey, and we are very excited about the platform we have built, the service that we provide, and where we are going to next. Sign up for free today, and experience Cloudsmith for yourself!

Caching and Upstream Proxying for RedHat Packages

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

Caching and Upstream Proxying for Debian Packages

Today managing your licenses with Cloudsmith has become incredibly simple.

Now, with the help of our License Compliance UI, not only can you update the license associated with a package without needing to modify a package, plus you can also view statistics of how your overall licenses appear across all packages within a repository. Don't believe me? Have a look at the screenshot below:

From the overview section, we can see the breakdown of total packages by format, types of licenses used across all packages in the repository, and the number of unlicensed packages in the repository.

In this example, we want all our licenses to be uploaded with the MIT License; however, several packages are missing licenses, and one package has uploaded with the wrong license. Let's open the edit view for the django-guardian package and update it to use a MIT License.

At Cloudsmith, we endeavor to match the license defined within a package's metadata as accurately as possible. For example, the BSD license defined within this package's metadata is checked against a valid SPDX license.

The SPDX License List is a list of commonly found licenses and exceptions used in free and open source and other collaborative software or documentation. The purpose of the SPDX License List is to enable easy and efficient identification of such licenses and exceptions in an SPDX document, in source files or elsewhere. The SPDX License List includes a standardized short identifier, full name, vetted license text including matching guidelines markup as appropriate, and a canonical permanent URL for each license and exception.

Anytime Cloudsmith matches a license automatically, we will always provide a description of what the license was defined as within the package's metadata, our confidence of how accurate the match is, and the new license that has been applied. You can find the following description on the edit page for any license that has been automatically applied:

> The 

 license provided within this package’s metadata is a 

 SPDX license and was automatically added to this package.

Anytime the match is not accurate to a high percentage, or the license is not supplied, we leave the license empty for you to decide how you want to resolve it.

To change this license or add a new one, select a new license from the autocomplete/dropdown and click the Edit button to save this change.

Once all the packages within a repository have been updated with a license, the overview provides an easy way to confirm all packages are using the same license and all packages are licensed.

Simplify License Compliance

Using GitHub Actions to push packages to Cloudsmith

Dan walks through how to connect up GitHub Actions to push packages to Cloudsmith.

Cloudsmith blog