By submitting this form, you agree to our 

At Cloudsmith we love playing video games, everything from Super Meat Boy to Halo, Fortnite to Candy Crush. We’ve got a big Pac Man money box sitting on the office shelf. Steve Collins, of Havok fame, is on our Board of Directors. Quite simply, gaming is in our DNA.

When we started Cloudsmith we made a list of customers we’d love to work with someday and there were numerous games studios on the list. It was a proud moment for the team when the first games company signed up to distribute its software globally. Since then more major studios have followed suit. It’s truly exciting to be a part of the deployment and delivery process for companies we really admire.

We pay homage to a few video game greats with our pop culture banners in our documentation; see 

. Can you guess the games on which each is based?

Cloudsmith can solve many problems for games companies, but what is most unique about a games company is that they are the software companies that can make use of all three of our primary use cases:

The beating heart of any games company is its Intellectual Property. Now, of course, this consists of game characters, themes, and franchises, but it also consists of a lot of proprietary code, libraries and packages, game engine components, and sound and graphic assets. Protecting this IP, while also granting globally distributed internal development teams easy access so that they can work with it is a major challenge. Cloudsmith private repositories allow a games company to centrally manage its software assets, provide secure access for development teams worldwide, and also deliver performant global availability.

A games company requires a lot of infrastructure to operate effectively. Significant resources are required to facilitate both internal development teams and any customer-facing environments for matchmaking and multiplayer services. This may take the shape of on-prem servers or cloud-based environments, but building and managing this infrastructure is a complex task. Even when automated through tools such as Terraform, Ansible, Puppet, Chef, and others, it still requires that these tools have a central source-of-truth for the packages and modules that they require. The universal package support offered by Cloudsmith means that it is easier for internal DevOps teams to manage these builds and deployments.

Games companies often need distribution of software assets and packages for a few different use cases, like distribution of software assets to licensed customers or distribution of packages and libraries to 3rd party development partners. To do this, they require fine-grained control over access, and visibility into download activity and usage. Cloudsmith’s extremely flexible Entitlement Token system allows the creation of unique, read-only access tokens that grant access to specific packages or assets. These tokens can have multiple restrictions attached, such as limiting access to specific packages, for a specific timeframe, from specific locations, and even a maximum number of downloads or bandwidth use. Any read activity on the repository is attributed and associated with an Entitlement Token and therefore users can be precisely monitored and analyzed.

As an example, we’re solving two use-cases for one such customer:

Supporting the management of Debian deployments to their IT infrastructure, including isolating public packages through our recently launched Upstream Proxy & Caching feature,

Enabling the distribution of private core dependencies to their partners, which utilizes our Entitlement token system.

As we mentioned, we love playing video games, and being part of the deployment and delivery process for companies that create them is something we’ll be forever excited about. Whether it’s 

, or the full trifecta, Cloudsmith is here to help support and solve many of the problems games companies face all in one platform.

Don’t just take our word for it though - 

Dan McKinney

Solutions Engineer

Games are in our DNA

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

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

Puppet is a Continuous Configuration Automation tool that’s you can use to automate the configuration of your entire infrastructure. You can use it to manage the configuration of anywhere from a few, to thousands of servers or devices.

The Puppet server is where you create and store your configurations and define which nodes specific configurations will be applied to. Puppet uses modules and manifests to describe how a machine should be configured and they are written in a ruby-like syntax that describes the desired state of a node.

The Puppet agent is installed and runs on each of your nodes. The agent pulls configurations from the Puppet server and then applies them to a node to bring the node into the desired state. It can be configured to periodically check the Puppet server for new or updated configurations (which would be the usual configuration in a Puppet deployment), or it can be started manually on a node as required.

The Puppet server must be installed on Linux but the Puppet agents can be installed on, and manage, Unix / Linux like systems, MacOS, or Windows. Installing the Puppet server and agent(s) is beyond the scope of this article, but for further details, you can see the official 

You can use a private Cloudsmith repository in combination with the automation power provided by Puppet to bolster your pipeline with more security and control over your builds and dependencies. Puppet is an ideal tool to automate the configuration of a Cloudsmith repository on nodes in your infrastructure, and to then also install any required packages and dependencies from this repository. The key is control - control over your packages via your Cloudsmith repository, and control over your builds and configurations via Puppet.

For this example, we will use Puppet to set up a Cloudsmith repository for 

 packages, but Puppet also provides official modules to support the most popular repository types, like yum, pip, 

On our example Puppet server, we will create a module to configure a Cloudsmith repo and install a package. I have created a directory for this module, called cloudsmith-repo. In this directory, I have also created a manifests directory, and this is where we create our manifest (called init.pp).

Let’s look at each bit of this manifest and explain what it does.

Our manifest starts with a class called cloudsmith-repo, the same as the module name.

First we add the puppet “apt module” with:

Since our Cloudsmith repository works as a native apt repo, we can use the class and types from the apt module to define the configuration of our repo.

The next thing we do is use the apt:key type to set up the GPG key for our repository. We need to add the 20 Byte Fingerprint of the repository GPG key, which we can get from the signing keys section of our Cloudsmith repo, and the URL for the key:

https://dl.cloudsmith.io/TOKEN/OWNER/REPOSITORY/cfg/gpg/gpg.8-BYTE-FINGERPRINT.key

After this, we then use the apt:source type to set up the repository itself. We give the repository a short description, then add the URL for the repository - which also contains an access token as this is a private repository. In your Cloudsmith repo settings, you can create as many of these access tokens as you like, and add restrictions to each token. Or you can also use HTTP basic authentication instead, we support both types of auth:

comment => 'An Example Cloudsmith Repository',

https://dl.cloudsmith.io/TOKEN/OWNER/REPOSITORY/deb/debian

We will also add our Debian distribution version, and we also specify that this is a Debian source and binary repository, as Cloudsmith repos support both types of Debian package:

Finally, we declare the package that we would like installed, and we use ensure to specify the version of the package we would like - in this case the latest version:

So, putting that all together and adding in details for the repository and owner etc, we would have something that looks like this:

id => '7DF1831D968E392DAFD802A97D4D4CE49534374A',

https://dl.cloudsmith.io/QOH0JBRgKQx5lE7S/demo/examples-repo/cfg/gpg/gpg.7D4D4CE49534374A.key

https://dl.cloudsmith.io/QOH0JBRgKQx5lE7S/demo/examples-repo/deb/debian

~> package { 'cloudsmith-debian-example':

As stated previously, you would normally configure Puppet nodes to periodically check in with the puppet server to pull and apply configurations, but we will just kick off the puppet agent by running it manually with:

The puppet agent will now connect to the puppet server and will retrieve and apply the configuration:

We can then check to see that the Cloudsmith repo has been added as a source for apt in /etc/apt/sources.list.d/ :

And if we check that our cloudsmith-debian-example package is now present (with apt-cache showpkg cloudsmith-debian-example), we can see that it has been installed:

It really is quick and easy to set up a Cloudsmith repository and deploy your packages using Puppet. We try to ensure that things "Just Work", and when using the built-in apt_module support in Puppet (or other modules to support other repository types, like yum or pip) you should be up and running in minutes, not hours.

Using a private Cloudsmith repository allows you to level up the control you have over your packages and software artifacts, and using Puppet allows you to automate and control your infrastructure configurations. It's a great combination.

Deploy Packages From a Cloudsmith Repository With Puppet

 preparations are already underway globally. If you're not familiar with the event, it's a month-long celebration of open source during October by Digital Ocean. Hacktoberfest promotes contributions to a diverse range of open source projects on Github and welcomes for first-time contributors to get involved with the community.

It's easy and the perfect time to get involved or even to rejoin the open source community. If contributing to your favorite open source project sounds appealing, wait, because it gets even better! Hacktoberfest is open to everyone across the world. Contributors can sign up anytime between October 1st and October 31st to become edible for fantastic swag in the form of t-shirts and stickers from Digital Ocean. Submitting four quality pull requests to a public Github repository qualifies each contributor to swag, and what fantastic swag it is! Check out last year's fantastic t-shirt!

At Cloudsmith, we use open source tools and dependencies in all of the software we build and use daily. We love giving back to the community and frequently contributing enhancements and bug fixes to libraries and package management tools to help our customers and our own internal needs.

Helping to support the open source community is important to us. That's why we provide 

 for all our package formats and provide open source tools to help users get the most out of Cloudsmith as their universal package repository.

This year, like many previous years, will see members of the team contributing to a range of open source projects for fun and to scratch our own itch by making something we love even better. Still, we're all about giving back and want to help empower developers to contribute to tools they enjoy using. That's why we will be creating a range of issues suitable for first-time contributors and experienced developers to make code and documentation improvements across some of our open source projects:

As a team, we are looking forward to engaging with the community we love, and creating new awesome software together!

A month-long celebration to open source projects: coming soon!

What software assets does your organization use?

What sounds like a simple question is anything but. If we include every package and dependency that ends up in the code we produce then for most development teams the truthful answer is ‘we don’t know’.

As we’ve said enough times already, that really isn’t good enough anymore. And that’s one of the core motivations behind Cloudsmith. A central private repository provides an ‘isolation layer’ in which everything you use is both stored and controlled.

Cloudsmith is entirely flexible in terms of how repositories are built and structured. Depending on what is convenient for your organization, you can either build universal repositories in which packages in multiple formats sit side-by-side, or format specific repositories.

But our support for transparency around the use of software assets across the entire organization doesn’t stop there.

By providing a single repository for all your assets, Cloudsmith enables you to check at a glance exactly which individuals and processes are downloading those assets. This can be helpful in a number of ways. It certainly is if you need to quickly establish precisely where any given package may have been used in the wake of identifying a specific vulnerability.

Download logs in Cloudsmith, as shown below, mean you have a record of precisely what is being used where, and by who or what. At any moment you have a full audit trail and detailed information relating to every download of every asset, so you can ensure the right people are accessing the right things in the right way.

We also provide event logs along similar lines, so you can keep a handle of any actions against any package within your Cloudsmith environment.

Beyond granular level access logs, Cloudsmith also supports aggregated reporting around access to each individual repository. This includes download and upload counts and associated bandwidth, plus downloads and uploads reported against geolocation, package type and distribution.

This type of reporting has a variety of uses. For one, it helps manage your account with Cloudsmith and ensure total visibility around usage, which in turn can be used to accurately forecast costs. (Cloudsmith also supports the configuration of retention/lifetime rules, meaning you can automatically delete or move packages after a certain amount of time in order to actively control those costs).

Full statistical reporting also provides key insight around which packages and formats are most popular, plus which are trending up or down in terms of usage. This data in turn can help understand where the business is particularly exposed to one package or package type, or alternatively which packages are being stored and rarely used.

All in, we provide a variety of methods for understanding how your repositories, packages and assets are used. All of them support better, more efficient development and distribution.

Auditing and Reporting In Cloudsmith

Getting Started with Composer and Cloudsmith

A quick walkthrough of getting setup with php/Composer and pushing packages to a Cloudsmith repository.

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

As time has progressed, the number of languages, frameworks and packages available has grown to the point where it’s rare nowadays to find a project that is developed entirely in a single language or within a single ecosystem.

A typical project uses the best languages and frameworks for the job, and these frequently differ depending on what part of the project is being developed. And that stands to reason - after all those different languages in most cases exist precisely because they are better suited to some specific tasks rather than others.

When you then bring package management into play, things get more complicated again. If you are using several languages, you’ll have several package managers. That in turn means you’ll require several repositories (Public or Private) and therefore several places that you need to manage, several places that you’ll need to integrate with your build processes, and several places that you’ll have to ensure your team has reliable, performant access to.

It is a universal law of software development that there is more than enough to manage as it currently stands, so adding all that to the pile isn’t a great idea.

At Cloudsmith we believe there is a better way: 

Multi-Tenant Repositories: What Are They?

So what is a Multi-Tenant Repository? Well, in short, it’s ONE PLACE to store and manage your software artifacts and packages - no matter what package formats you are working with.

Yes, that’s right Your Docker images can live right alongside your Python packages or your npm packages. You have one single location to manage.

Furthermore, this one location will play nicely with your 

 tooling. You can just do your usual `docker pull`, `pip install` or `npm install` - all from the one, single repository!

So whilst you have a single repository, and a single set of processes for managing, sharing and controlling your software assets, you lose absolutely nothing when it comes to functionality.

The benefits of multi-tenant repositories aren’t just limited to development environments either.

If you are distributing your software to your own customers, and you provide it in a number of different formats, wouldn’t it be nice (and convenient) to offer all those formats to your customers from a single unified location? Not only does it just work better, it looks better also!

You no longer have to worry about pushing/publishing to multiple different repositories, or keeping them in sync, wondering what was pushed to where - it’s all in the one place. The reduction in overhead here is not to be underestimated.

Now of course, if you want to create a repository for each format that you use then you absolutely can do that - there is nothing about Cloudsmith’s multi-tenant repositories that would prevent you from doing so, if that’s your style and you’re happy with it - or if you work in a single language/ecosystem. The point is that we give you the flexibility to “do it differently” (and just maybe, easier!)

At Cloudsmith, we really believe in automation. And in our experience what helps automation is simplification. Make processes simpler, make them less error-prone, more reliable and more robust: just make them easier to automate!

Multi-Tenant repositories are here to make your lives easier, not harder.

As I said, software engineering is hard enough already! 😊

How Multi-Tenant Repositories Benefit Workflows

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

Cloudsmith Blog