By submitting this form, you agree to our 

Getting Started with Go and Cloudsmith

A short demo of how to get started with Go modules and Cloudsmith, including pushing a Go module to a private Cloudsmith repository and then pulling the module as a dependency in a Go project.

Dan McKinney

Solutions Engineer

Docker Security Scanning

A walkthrough of Docker Security Scanning with Cloudsmith.

Get Started with Cloudsmith's Docker Security Scanning

 is an awesome tool, created by Hashicorp, with a vibrant community of open source modules for multiple cloud providers. It’s not hard to understand why it’s a favourite amongst developers; especially when it's often faster at supporting new features than some of the cloud providers!

Terraform enables its users to manage components in their architecture, ranging from the configuration of the services used in their chosen cloud provider (such as 

Amazon Web Services, Google Cloud Platform, or Microsoft Azure

), to software run on those services (like 

). Terraform even supports configuring some SaaS services you may interact with (for example, 

Using Terraform to define your desired configuration means that not only will you offload the work of creating the components you need, but also make the creation of these instances reproducible, allowing you to create, update and destroy components of your architecture as needed, all with one command (and a review of the changes before executing them!).


To make modules created by the Terraform providers available to all Terraform users, Hashicorp runs the 

 which allows users to upload modules, making them publicly available to all Terraform users.

Cloudsmith's private module registry fully supports the 

, allowing users to access both private modules available via Cloudsmith and public modules via the public registry.

Cloudsmith's private module registry also enables developers to:

Share custom modules for managing infrastructure among their team

Utilize private modules in your organization without the overhead of managing their storage

Distribute private modules as a commercial offering

Make modifications to public packages while having control of how you publish them (publicly accessible, private to your organization or open-source)

Capture the exact state of modules you depend on at a particular version

Control (allow list/deny list) at an organization, repository, and module level

Getting started with Cloudsmith and Terraform only takes a few steps. First, you need to create a Cloudsmith account and a repository to which you can upload your modules (a terraform provider for doing just this coming soon!).

If you need to install Terraform, you can find a getting started guide on the 

.

Cloudsmith's private module registry should work with all supported versions of Terraform, however, we recommend using version 

. You can check the version you have installed by running:

For this example, we'll create a module which prints out "Hello, world!".

First, we need to create the directory which will contain the module:

 file, this is the entry point for your module and will contain the code required to generate our message. To generate this message we must add the following to the 

Now that we have the code necessary for our module, we need to package and upload it to Cloudsmith. To achieve that we need to make use of the *nix tool 

To ensure we don't upload some unnecessary files, we exclude your terraform state file(s) along with 

 which can contain authentication credentials.

The name of the terraform module is critical here, as the 

terraform registry API requires this specific format

, along with several other requirements that you should review when creating modules.

To upload the module to Cloudsmith, you can use either the application's UI, or the Cloudsmith CLI. For this example, we'll be using the CLI, which has steps for installation available 

With the CLI installed and configured to authenticate successfully with Cloudsmith, we can upload our module by running:

Once uploaded, you can view your module in Cloudsmith.

Cloudsmith provides fully featured Terraform module repositories on all plans, flexible enough for use whether you’re hosting public packages for a public or open-source project, or private packages for your company’s internal needs. We're extremely proud to be able to support the Terraform ecosystem with this tooling.

You can find further, context-specific information, including detailed setup and integration instructions inside each Cloudsmith repository.

Lee Skillen

Chief Technology Officer

Announcing Private Terraform Registry Support in Cloudsmith

Getting Started with Unity and Cloudsmith

A short demo of how to get started with Unity packages and Cloudsmith, including pushing a package to a private Cloudsmith repository and then adding a package to a Unity project.

Getting Started with Docker and Cloudsmith

A short demo of how to get started with Docker and Cloudsmith, including building and pushing a Docker Image to a private Cloudsmith repository and then pulling and running the image.

Universal Package Tags

A walkthrough of universal Package Tags - tag any package or container within Cloudsmith. Use them to search/filter and organize your software assets.

We’re a little late to the party. Fashionably late.

By now the world knows that DockerHub has removed the free, untraceable goodness of anonymous pulls. How dare they? How dare they build a revolutionary technology, open-source it and give it away for free at a substantial cost to themselves. It’s worth calculating what a couple of petabytes of CloudFront bandwidth would cost, even with a substantial discount. It’s mind-blowing. And frankly unsustainable for any company that doesn’t have a multitude of revenue streams.

Why have public when you can have private?

 at the request of a customer about two years ago. At the time, we thought it was unlikely that we’d be picked over AWS ECR (other Cloud provider container registries are available) but we were pleasantly surprised to find that a single pane of glass for all assets is a huge draw for our customers.

We’ve built Cloudsmith to normalize, where possible, the diverse list of formats as much as possible; so that Docker images can sit beside the very dependencies they contain.

The truth is, untraceable, anonymous access is bad for software delivery. It really should be a thing of the past. Organizations must build security into their processes and workflows at the far left, with tools like Snyk, and at the point of deployment or distribution with tools like Cloudsmith.

We believe that building up a provenance trail is vital to monitor and control your risk.

The move from DockerHub, while it might cost you money, is actually a step in the right direction for everyone. Control over public upstreams is vital, and this move shines a light on the problem, and will, for many, force action toward a better, more secure, way of doing things.

Alan Carson

Co-founder and Chief Strategy Officer

DockerHub vs Cloudsmith Private Docker Registry

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

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

Getting Started with Alpine Linux and Cloudsmith

How to get set up and started with your own private, secure repository for Alpine Linux Packages on Cloudsmith.

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

Getting Started with Conan and Cloudsmith

A quick walkthrough of getting set up with Conan (C / C++) and Cloudsmith, including uploading and downloading packages using the native Conan tooling.

Cloudsmith Blog