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.

It’s official: regulations by the US and UK governments are coming down the track to secure the software supply chain.


Earlier this month, President Biden signed an 

 (EO) to increase cybersecurity defences across the U.S, with an emphasis on enhancing the security of the software supply chain. Now, the 

 is following suit, having announced their own call for advice on defending against software supply-chain attacks. The supply chain attacks at SolarWinds and 

 have shaken governments. The EO targets the software industry when it says, “Too much of our software, including critical software, is shipped with significant vulnerabilities that our adversaries exploit.” The US wants to know what is in the software they rely on and how securely it is built.

How could this affect your DevOps and Software Engineering teams?


Within 60 days of the EO, the US government will publish the following:

Minimum elements for a Software Bill of Materials (SBOM).

Guidelines recommending minimum standards for vendors’ testing of their software source code, including identifying recommended types of manual or automated testing (such as code review tools, static and dynamic analysis, software composition tools, and penetration testing).


The SBOM is a critical element of the EO, essentially a record of all of the components and dependencies used in building software. Most software contains libraries and packages sourced from the open-source community or commercial software. The end-user can use the SBOM to perform vulnerability or license analysis, both of which can evaluate risk in a product.

The EO specifically calls out actions to prove the security and provenance of open-source software (OSS). There is a fear that the OSS supply chain is a potential avenue of attack for hackers. Most modern software relies on many OSS packages, which will only increase moving forward as software becomes more and more complex. The EO indicates that OSS packages used in software will need to be checked for:

The EO may force Software developers and DevOps Engineers to change their practices and update their CI/CD pipelines to increase the visibility of the software composition, increase automation and attest to their security practices.

The EO's 10 steps to securing your software supply chain

Secure software development environments using administratively separate build environments, controlling access, 2-factor authentication and by monitoring operations on the build environments.

Provide proof that your software was developed in a secure software development environment when requested by a purchaser.

Use automation to maintain trusted source code supply chains, thereby ensuring the integrity of the code.

Automation tools checking for known and potential vulnerabilities and fixes shall operate regularly.

The Purchaser may request proof of Automation and a summary report of risks and mitigations.

Maintain accurate and up-to-date data, provenance (i.e., origin) of software code or components, and controls on internal and third-party software components, tools, and services present in software development processes, and regularly perform audits and enforcement of these controls.

Participate in a vulnerability disclosure program that includes a reporting and disclosure process.

Attest to conformity with secure software development practices.

Attest to the integrity and provenance of OSS used within any portion of a product.

Cloudsmith is uniquely positioned to help Engineers secure their supply chain and meet the new requirements the US and UK government will be introducing. Cloudsmith provides an entirely managed cloud-native ‘single source of truth’ for all software and its dependencies, isolating and protecting you and your customers from supply chain attacks. Using continuous packaging (CP), we offer the observability and control to ensure that your software is always verified, packaged and ready to deliver.

Build and ship your software with Cloudsmith to secure your supply chain and comply with future regulations.

United in Security: US and UK Vow to Improve Software Supply Chains

At Cloudsmith, we believe that packaging should be at the centre of any modern build and deployment process. In fact, we think that Continuous Packaging is the glue that ties Continuous Integration and Continuous Deployment or Delivery together.

So with that in mind, in this blog, we will take a walk through how easy it is to integrate Cloudsmith with a Semaphore CI workflow and push the artifacts and packages that you build to a private repository.

 – It’s super easy. You just need to add a block to a pipeline in a Semaphore CI workflow that installs the 

, and then uses the CLI to push your package. We will step through how you do that!

Semaphore CI is a Continuous Integration and Continuous Deployment or Delivery platform. It’s cloud-native, fast, easy to get started with and supports any platform or language. You can create your workflow and pipelines by writing the YAML configuration files directly, committing them along with your source code, or using the intuitive Visual Builder that Semaphore includes.

Building a workflow from scratch is beyond the scope of this blog, but we have created a straightforward example workflow that we can walk through to see where Cloudsmith fits in and how to set things up.

When you first log into Semaphore, you can authorise it to connect to your GitHub account and then choose which repository you want to use to create a Semaphore Project. Once you do this, Semaphore automatically installs the required hooks in your source repo so that new pushes can trigger your workflows on all or specific branches, or even for pull requests:

The next thing that we need to set up is to add our Cloudsmith API Key as a secret for this Semaphore project, as the Cloudsmith CLI requires the API Key to authenticate to Cloudsmith to push a package. It’s easy to add a secret to a Semaphore project and then use it as an environment variable in a pipeline:

Remember ALWAYS to store secrets used in your build or deployment processes in a secrets manager (here were are using the built-in Semaphore secrets store) or encrypted in some form. Never, ever add secrets or credentials to your configuration files as plain text, or commit any in your source.

OK, that’s the basics of our project settings configured. Now let’s take a look at the centrepiece of a Semaphore build and deployment process – the Workflow.

At this point, it’s probably worth running over a few of the terms we will come across when describing this workflow and what they mean.

First, you have the workflow itself, which may consist of multiple pipelines, perhaps one to run tests and another for deployment. Pipelines then consist of one or more blocks. Blocks run on an agent, which defines the execution environment, and they also specify which Jobs need to run. Jobs themselves then specify the commands that you want to execute.

In our example workflow here, we just have two blocks – A “Build Package” block and a “Push Package” block:

This is how things look in the Semaphore Visual Builder, and we can also drill down into individual blocks here to see the jobs within them. For example, this is what the “Checkout and Build” Job from the “Build Package” block looks like:

As previously mentioned though, all configuration in Semaphore is specified in YAML files. The initial pipeline is sourced from .semaphore/semaphore.yml. So let’s go and take a look at that now and see what it contains.

The semaphore.yml file starts by declaring a name for the pipeline and the agent that defines the hardware and software environment that the blocks will use:

Next we declare our blocks. The first block we declare is the “Build Package” block:

There are a few things to note here. First, is that any commands listed in the prologue are executed before each job, and here we use these to install the required tooling that we need to for our project (in this case, the rubygem “fpm”, which we will use to create a Debian package once our source is built)

Then, the commands in our “Checkout and Build” job will run. Going through these one at a time, the first command clears the Semaphore cache, so any artifacts from previous runs of this pipeline will be removed. Next, we check out our project source and run “make” to build our source. We then use “fpm” to package the results of our build into a Debian package, and finally, we store the built package in the Semaphore cache with the cache key “package”.

We need to use the Semaphore cache to pass files between blocks and jobs as each job runs in a separate, isolated machine that starts with a clean environment.

The second block that we declare is our “Push Package” block:

Things to note here are that we use the prologue to install the required tooling for the Block, namely the Cloudsmith CLI. We also use the secret that we added to the project here, which sets up our Cloudsmith API Key as an Environment Variable when the job runs.

In the “Push” job, we simply restore the package from the Semaphore cache. Then we use the “cloudsmith push” command with the Cloudsmith account called “demo”, our repository called “examples-repo”, and we are using “Debian” and “Buster” as the distribution and version for this package.

So putting that all together, our complete semaphore.yml file looks like this:

That’s all we need for this job to push the package to our private Cloudsmith repository.

Now, because Semaphore configured our Github repository automatically when we initially set up the project, all that is left for us to do is make a change to our source, add and commit the change, and then “git push”:

This push then triggers the Semaphore workflow to start:

Our pipeline is now running, and we can see that the “Build Package” block is executing the “Checkout and Build” Job:

We can view a live tail of the logs from this block, and we can watch for the output of each command in the job:

The job completed all commands successfully, and now the “Push Package” block starts and executes the “Push” job:

Again, we can view the logs from this block, and we can see that the “cloudsmith push” command succeeded and pushed our package to our private Cloudsmith repository:

That’s everything complete. Our Semaphore workflow ran successfully, and the package we created in our build process was uploaded to Cloudsmith. We can take a look now at our Cloudsmith repository and see our new package:

It is easy to add a private Cloudsmith repository to a workflow that you have in Semaphore CI. You don’t need to make sweeping changes to your build process. Cloudsmith and its universal package support means that, in reality, you are just a “cloudsmith push” away from adding your own central, single source of truth for your package management needs. In doing so, you are one step closer down the path of Continuous Packaging.

Continuous Integration, Continuous Packaging, Continuous Deployment / Delivery. The modern DevOps workflow, helping you secure and control your software supply chain.

Integrating a Cloudsmith repository with a Semaphore CI workflow

Using Semaphore CI to Push packages to Cloudsmith

A short demo of how you can set up a Semaphore CI workflow to push a package to a private Cloudsmith repository.

At Cloudsmith, our mission is to make it as easy and straightforward as possible to get your packages into our system from where you can manage and distribute them to your heart's content.

To this end, we recently spent some time with Atlassian's Bitbucket team at 

 that makes it simple for Bitbucket users to easily turn their source code into distributable packages and deploy to Cloudsmith in just a few lines of YAML.

Pipes build on top of Bitbucket's excellent 

 functionality which allows users to automate their build and deploy processes, whatever form they may take.

Bitbucket Pipes are, at their simplest, the combination of a Docker container and some YAML-formatted configuration. Pipes are designed to remove what would otherwise be repeated or verbose configuration from a user's pipeline. Pipes can be shared across repositories or organisations and make many common tasks almost trivial.

The Cloudsmith pipe is included in Bitbucket's collection of officially maintained pipes and is available by default for any user that wishes to include it in their pipeline.

To use the pipe you'll first need an application or library that can be packaged into one of the formats that Cloudsmith support. You can see examples of Python and Javascript libraries in 

For the purposes of this example we'll assume you're using the Python example from the link above.

First, ensure that you can package your code using a Bitbucket pipeline by editing 

 in your repository. You can do so either via Bitbucket's web UI or using your normal editor and Git workflow.

For the example library, a basic pipeline that builds a package when a new tag is created looks like so:

This pipeline will build a new package each time you push an appropriate tag you your Bitbucket repository. The built package is then discarded as we have not yet added further instructions to tell Bitbucket what to do with it.

Next we'll add publish the package to Cloudsmith using our official pipe. We'll need to provide an API Key that the pipe can use to authenticate with Cloudsmith. You can find the official documentation for pipeline variables in the 

The API Key should be added as a "secure" variable (so it doesn't leak into logs) with the name 

Once authentication is configured, you can add the pipe configuration to your pipeline.

If using the web UI to configure your pipeline, you can select the Cloudsmith pipe right from your browser, from within the list of supported pipes as in the image below:

If using your local editor, you can follow the instructions in the 

Once added, your pipeline YAML should look something like so:

This configuration instructs the pipe to push artifacts to the 

 repository, with the API key we stored earlier. We're uploading a 

And that's it! Your pipe is now configured and ready to run. You should be able to push a new tag to Bitbucket and see your pipe run.

Bitbucket's pipeline UI provides a great overview of the status of your jobs:

Once pushed, you should see your shiny new package in the Cloudsmith UI, ready for download and install using your preferred tools:

Cloudsmith's Bitbucket pipe provides the easiest and simplest way for Bitbucket users to push their assets to Cloudsmith. Our official pipe is maintained by the Cloudsmith team and you can be sure it'll be kept up to date with all changes and features as we release them.

As always, if you have any questions about the pipe (or anything else), we're available at 

Cloudsmith + Bitbucket

Today, almost every service now is offered in a “Cloud” variant. But what does that really mean? Are all clouds services equal?

It’s easy to see why so many vendors rush to add a Cloud edition/variant of established software they sell. Undoubtedly, there has been a move to Cloud services across the industry, as more and more organizations seek to take advantage of the higher reliability and lower total cost of ownership that Cloud platforms promise.

The thing to watch out for is the major difference between Cloud Hosted and Cloud-Native.

When Cloud providers started to emerge; spearheaded by AWS who saw the opportunity to monetise the tooling and spare capacity they had in their data centres. We began to see other vendors jump to offer their software (which had previously been sold for on-prem use) on these Cloud platforms, hoping to capitalize on the emerging trend.

A lot of “enterprise” software was never designed to run on a Cloud platform. It was never architected to take advantage of the paradigm shift that cloud computing enables, and you are left with effectively paying (a premium, in some cases) for the same software, just running on a virtual machine on a Cloud platform. This is Cloud hosted. A self-contained software solution, typically cannot take advantage of what the Cloud offers - for instance, how would it know to load balance requests? Or scale up. Most of the time, it is limited by the resources it has to hand. The fixed cpu and memory it has been allocated.

On the other end of the spectrum, you have software that has Cloud built into its DNA. Software that relies on features that are only possible on Cloud platforms in order to work as it does - think fully distributed workloads, fault tolerance, and scaling for global performance.

Every superhero has an origin story. This is ours.

Cloudsmith is designed from the ground up as a Cloud-Native application. From day one, it has been architected to take advantage of all the technology that Cloud provider platforms offer.

This is why we don’t offer Cloudsmith in an on-prem variant. It’s not just a package management solution, it’s a secure, ultra-fast delivery platform for software, harnessing the power and flexibility of the Cloud and Edge computing.

Cloud-Hosted or Cloud-Native? Discover Why Cloudsmith Was Born in the Cloud

In this blog, we will walk through the process of configuring a private Cloudsmith repository as an artifact source for a Harness Continuous Deployment pipeline.

Harness is a Continuous Deployment platform that allows you to easily automate the deployment of your software to your infrastructure and environments.

The Harness Platform has two main components:

 The Harness Manager is where you manage your deployment pipelines and also where you store your deployment configurations. It is available as a SaaS or on-premises running in your own infrastructure. In this blog, we will use the SaaS version at app.harness.io. You can use the Harness Manager (or the API, or a trigger in your pipeline) to start and view your pipeline execution.

 the Harness Delegate is software you install in your environment (locally or on a cloud platform of your choice), and run as a service. The Delegate connects to the Harness Manager to receive tasks and then executes these pipeline tasks on your chosen platforms.

Installing the Harness delegate and building a pipeline from scratch in the Harness manager is beyond the scope of this blog, but Harness provide 

We are going to set up our Cloudsmith repository as a docker registry in Harness and then use Harness CD to deploy a docker image to AWS Elastic Container Service.

First, we log into the harness manager, and then go to “Setup”:

At this point it’s worth explaining some of the Harness key concepts, particularly Cloud Providers, Connectors and Applications :

Cloud Providers describe your infrastructure, such as AWS, GCP, Azure or even your own Physical Data Center. I’ve configured AWS as my Cloud Provider here and I have provided the AWS Access Key and Secret Access Key. I’ve added my AWS Secret Access Key as an encrypted secret using the included Harness Vault, and it’s always correct to use an encrypted secret and a secrets manager of some sort. Never, ever add your credential or secrets as plain text as part of a deployment pipeline.

Connectors are where you integrate repositories, registries, or monitoring tools. The Connector type we will configure here is an “Artifact Server”. This is the important bit for this blog, as it is where we add our Cloudsmith repository.

This is really simple, as Cloudsmith repositories are fully compatible as a native docker registry. All you need to add is your Cloudsmith registry URL – (docker.cloudsmith.io/v2/), your Cloudsmith username and your encrypted password.

I’ve added my Cloudsmith API key as an encrypted secret, again using the included Harness Vault.

You could also use a Cloudsmith Entitlement Token, and you can see our 

 to find out how to authenticate to a Cloudsmith repository using a token.

The next thing we configure is an Application. Applications are how you organize a deployment project in harness and consist of Services, Environments, Workflows, Pipelines, Triggers and Infrastructure Provisioners:

Services represent your applications and microservices, and this is where you declare the artifacts that you wish to use, any configuration variables and container specifications.

This is the first thing we define for our application.

I have selected my Cloudsmith artifact repository as the source server, and for my docker image name I have entered my Cloudsmith organization name “demo”, my repository name “examples-repo”, and my docker image name “cloudsmith-example-app”. I also choose here to deploy this docker image to AWS ECS:

An environment represents your deployment infrastructure, such a test, staging or production. This is the second thing that we define for this application.

We have defined a “TEST” infrastructure here on AWS here, and this is also where wer define things like the region and cluster to be used, and the IAM execution role to use:

A workflow includes the Service, Environment, and Infrastructure definitions we have added already, and then uses these for the deployment steps. A workflow is the third thing we define for this application.

There are different types of Workflows, such as basic, canary and blue/green. For this example, we will use a blue/green workflow that configures an AWS load balancer, and then deploys or upgrades the containers running on our ECS cluster. You can also add things like rollback steps and notifications:

A pipelines model is a collection of one or more stages, containing Workflows for Services and other deployment and verification steps, such as Approvals

We have set up a very simple single-stage pipeline here that just runs the Workflow we defined above:

A Trigger is used to automate deployment in response to an event, such as Git events, a new artifact in a repository, a schedule or even the success of another pipeline.

We have set up a trigger here that will start the Pipeline when a new docker image is pushed to our Cloudsmith Repository:

We have a simple python flask project, that just prints a simple message. We just need to create a docker image from this project using the ‘’docker build’ command:

This command also adds two tags to the image, a ‘latest’ tag and a ‘2.0.0’’ tag.

Now, we just push this docker image and tags to our Cloudsmith repository, exactly as you would do with any docker registry:

That’s the docker image pushed to Cloudsmith, and we can see it now in our Cloudsmith Repository:

As we have set up a Trigger in Harness, Harness will then poll any configured artifact repositories every 2 minutes for the presence of a new artifact. As a result, our Pipeline will then start to execute:

We can follow the stages in our pipeline, and the steps in our workflow here, and see the log output. For example, you can see the output of the upgrade containers step here:

Once the deployment has completed successfully, we can hit the address of our AWS Load Balancer in a browser and we can confirm that our docker image has been deployed to our ECS cluster, and the message that this example application prints:

Our automated deployment to AWS ECS was successful, our docker image was pulled from our private Cloudsmith repository, and it was all managed and controlled by Harness CD.