By submitting this form, you agree to our 

Explores AI-driven development, rising supply chain attacks, and new regulatory requirements.

2026 Artifact Management Report

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.

Dan McKinney

Solutions Engineer

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 support@cloudsmith.io.

Paddy Carey

Principal Engineer

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.

Alan Carson

Co-founder and Chief Strategy Officer

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.

Integrating a Cloudsmith repository with a Harness CD pipeline

Using Harness to deploy packages from Cloudsmith

A short demo of how you can use Harness CD to deploy a docker image from a private Cloudsmith repository to an AWS ECS Cluster.

It was revealed just a few days ago that US Federal investigators are looking into an intrusion and insertion of malicious code into Codecov.

As many readers here will already know, Codecov is a software auditing tool that analyses your source code to check for the amount of test coverage. The intrusion targeted the Codecov bash uploader, which is a script that provides a way to send coverage reports to Codecov.

It has been determined that attackers were able to target the bash uploader script due to an error in a Docker image creation process, which effectively leaked a secret credential. This allowed them to update the bash uploader. The malicious code added to the script scraped all environment variables that are present when the script runs and sent these to an as-yet-unidentified third party.

Specifically, the following line was added to the bash uploader:

This means that if the bash uploader script was running as part of a CI process, then it would copy all of the environment variables that this process required (such as API keys, tokens, credentials for other required services etc), and leak them to the attackers.

Codecov found out about the unauthorized access on April 1st, but their investigation determined that beginning as far back as January 31st, 2021 there were periodic unauthorized alterations of the bash uploader script.

Codecov said that a customer informed the company of the issue on April 1st after noticing a discrepancy between the SHA1 checksum for the uploader posted publicly on GitHub and the checksum calculated from the Bash Uploader they had downloaded.

Simply put - not enough people were looking and checking, or more specifically, not enough people had the correct tools and processes in place to simplify such checks.

You need a single source of truth for all packages and dependencies used in your environments. Somewhere you can check all package checksums quickly. A single pane of glass for all your software artifacts, together with a good API where you can get this information and automate your checks.

The advice given by Codecov here is good:

We strongly recommend affected users immediately re-roll all of their credentials, tokens, or keys located in the environment variables in their CI processes that used one of Codecov’s Bash Uploaders.

You can easily determine any keys, credentials or tokens that may have been compromised in your CI environments by simply running the ‘env’ command in your pipelines. Any environment variables that are output should be considered possibly compromised. You should both change/rotate them and perform an audit of their use.

This underlines the importance of two things we at Cloudsmith talk about as benefits of Continuous Packaging - Provenance and Isolation.

 - checking the signatures (if present) and checksums of artifacts that you consume. This revealed that the bash uploader script had been modified.

 - Keeping a cached copy of the bash uploader script allowed this customer to have a point of reference to compare the checksum with the publicly available version.

Thoughts On the Codecov Breach

At Cloudsmith, we strive hard to ensure that private Cloudsmith repositories work with any build and release process that our customers use. Our mission is to be the universal package management solution that any modern DevOps workflow requires. Thanks to the power of the Cloudsmith CLI and API, it’s very easy to integrate our platform with any of the popular build tools out there, and in this blog, we will take a look at how you can set up your Drone CI pipelines to push the results of your builds to your own private repository.

Drone CI is an open-source Continuous Integration platform. It has a container-first approach which means that you utilize Docker containers to execute the steps in your build pipelines.

Installing and setting up Drone itself is beyond the scope of this blog, but it’s easy – the components of a Drone build environment are provided as Docker images so you can get set up and running very quickly.

A Drone environment consists of two main pieces of infrastructure. The Drone Server and Drone Runners.

The Drone server is the centralised place where you manage and observe your build pipelines and configure settings and secrets. It is installed via a lightweight Docker image that you can deploy on a cloud instance, a container service or even directly on your own hardware. It’s also available as a cloud-native solution that is free to use for open-source projects.

For this tutorial, I have installed the Drone server directly on an AWS EC2 instance.

The Drone runners are standalone daemons that poll the drone server for pipelines to execute. In this tutorial, I will make use of the Docker runner that I have installed on my local machine, but you could equally install it on a cloud instance or container service also. There are additional types of runners that are optimized for different use cases such as a stateful pipeline that needs to store files on the host machine between pipeline executions, but we will look at a simple build here that doesn’t require anything stateful.

Once you have set up the drone server, and one or more runners, you then connect the drone server to your source repositories using OAuth. I’ve already set this up and you can see the source repositories that the Drone server now has access to:

Let’s go ahead and activate it for my demo source repository:

You can see some of the main settings here, including the name of the drone configuration file from the source repo (.drone.yml)

The Drone configuration file is a YAML file that you place at the root of your source repository and it is used to define your pipeline steps. It’s actually a superset of the docker-compose file format, and it’s designed to be easily readable by anyone looking at your source.

The next thing we need to do is add a couple of secrets to the environment for this build pipeline.

The Cloudsmith API Key. We will need this as we need to authenticate push the package that we build to our Cloudsmith repository

Docker Credentials. We are going to use our own Docker image to execute this build, and this image is stored in a private Cloudsmith Docker registry. We can get these credentials from our ~/.docker/.config.json file after we do a normal `docker login`

It is, of course, a great idea to store these secrets encrypted on the Drone server as we are doing here. You do NOT want to check secrets like these into your source as part of any configuration files.

Once we have everything activated as above, we can now build the project.

I have a simple “Hello World” example project in C, that I want to build into a Debian package. Let’s put together a drone configuration file for this project. It starts off by defining the kind as a pipeline, and the runner type as a docker runner, and we have just named it Cloudsmith Demo:

Next, we just specify the OS and architecture and we then get into defining the steps that will execute when this pipeline runs:

After this, we start to declare our steps. We just need a single step here, a build and push package step, and we also declare the docker image that we will use to execute this step:

image: docker.cloudsmith.io/demo/examples-repo/drone-base:latest

This is a docker image that I have prepared already, and just so you can see what is required for this build, the Dockerfile looks like this:

# Do system updates and install dependencies

RUN apt-get -y install git ruby ruby-dev rubygems build-essential python3-pip

It contains the tooling required to compile the C source, and then package it into a Debian package. It also contains the Cloudsmith CLI, which we will use to push the package to our Cloudsmith repository.

You could install all the tooling using additional commands in the step, and forgo the use of your own Docker image. But it’s cleaner, and also makes better use of drone’s “container first” approach to build your own image with any pre-requisites for the pipeline, and use that to execute the step.

Next, we set up our Cloudsmith API Key as an environment variable, from our drone server:

We then execute the ‘make’ command to compile our C source, use ‘fpm’ to package this into a Debian package, and then use the ‘cloudsmith push deb’ command to push the built package to our Cloudsmith repo:

- fpm -f -s dir -t deb -v 1.0.1 -n cloudsmith-drone-demo .

- cloudsmith push deb demo/examples-repo/debian/buster cloudsmith-drone-demo_1.0.1_amd64.deb

Finally, we also pull in the secret we added to our Drone server that will allow Docker to pull our Docker image with our prerequisites from our private Cloudsmith Docker registry:

So, putting all this together, our complete .drone.yml config files looks like this:

Now, all that we need to do is to make a change to our source and push it to our source repository to start this build.

If we check our Drone server after pushing a change to our source, we can see that our pipeline has started to execute:

Let’s have a look and see what happened. It started by cloning our source repo,

And then our “build and push package” step executed:

You can see that it has pulled the docker image we are using to execute this step, and then executed ‘make’ and ‘fpm’ to build our Debian package. Finally, it pushed the resulting Debian package to our private Cloudsmith repository. That’s the pipeline execution finished successfully.

If we now go to our Cloudsmith repository, we can see our new cloudsmith-drone-demo Debian package – the result of our automated build pipeline, present as expected in our own private repository:

It’s easy to automate pushing the results of your Drone pipeline builds to a private Cloudsmith repository. With the simple addition of the Cloudsmith CLI (or a Docker container that has the Cloudsmith CLI), you can be up and running in just a few minutes, and benefit from the security, control and centralised management that a universal package management solution like Cloudsmith provides.

Integrating a Cloudsmith repository with a Drone CI pipeline

Using Drone CI to push packages to Cloudsmith

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

Software development by distributed teams is nothing new. But since 2020, it’s no longer just teams that are globally dispersed, it is the individual team members themselves. Remote working is the new normal. So in this unpredictable, “modern” world we’re in, how do you put together a solution that delivers for every single team member, no matter their location?

How do two (or more) people work together on the same project, if availability times for integration and deployment have different latency due to old thinking, old infrastructure limited due geographic locations. If a package containing a crucial bug fix takes nearly 15 minutes to replicate from San Francisco to London or Tokyo, it severely hampers rapid rollout of fixes - something that could potentially affect the bottom line of your business.

Organizations have been grappling with the challenges that distributed teams present for some time now, and many different tools and services were created to lighten this burden.

Take source control, for example. Organizations were quick to embrace distributed version control systems, and then went one step further when they shifted these to the Cloud. CI/CD build pipelines are no different, having moved from on-prem build servers to - you guessed it - the Cloud.

But these only solve some of the problems that distributed teams face. What about artifacts and package management?

Historically, one solution was to stand up an on-prem package management system, either as an instance in an organizations’ cloud or a physical server. But in the changing landscape now, this isn’t a great fit anymore. How do you ensure secure, performant access for every member of your distributed development teams? What about redundancy, backups, and high availability?

You may need to stand up many instances around the globe, in many regions - dealing with VPNs, replication, clustering, CDNs etc. Pretty quickly, you’ll probably need a full-time administrator, or a dedicated team to manage this. Costs here quickly spiral, both in terms of the infrastructure you need, the licenses for the software, and the dedicated personnel.

As with other components of the software development and delivery process, it's time for package management to move to the Cloud also, just like source control and CI/CD pipelines. You can reduce your total cost of ownership and at the same time, deliver a better solution for your teams. We believe this passionately, so we created Cloudsmith - a universal, web-scale package management system.

A fully distributed platform. Cloudsmith has been architected from the ground up to deliver best-in-class performance no matter where in the world you are. Multi-region, and backed by a global CDN. We have worked extremely hard to build a reliable, performant platform. Our reputation, and that of our customers, depends on it.

A fully managed service. You don’t need to be an administrator of the platform, it’s all fully managed for you, 24/7. One of our customers put it very succinctly when they switched to Cloudsmith: “We don’t want to be Sys Admins”. We are also here to provide support anytime you need it; our engineering team works closely with our customers to ensure that they get the very best possible value from Cloudsmith.

Secure by default. One of our core principles is security; you could almost say we are obsessive about it: fine-grained access controls, multi-factor authentication, event and access logs, and an extensive permission system. We are proud to say that we have never failed a security assessment by one of our customers.

Universality. With support for 24 package formats at present, and more being added all the time, you can simplify and centralize your package management. Also, with our multi-format repos, you can add all your package formats into the same repos; there are no restrictions on how you structure your repos.

Distributed teams aren't new, but for the post-2020 world, their automated workflows need to be much better for their distributed team members. A fully cloud-native package management solution is now an essential component for modern workflows.

Missing Infrastructure: Accelerated Worldwide Delivery

Security in software is now everyone’s problem. We can no longer simply rely on InfoSec teams or your equivalent Gary “he-likes-security” to handle security-related processes and issues. All software, tools, infrastructure, and services need to be trusted.

It is important to us at Cloudsmith to provide you with the ability to build that trust within your teams or with your customers.

Cloudsmith allows you to use your own domain name for your repositories. Not a subdomain of cloudsmith.io, but your actual domain name. This means you can use URIs like 

 to brand and identify your repositories.

So, why does this matter? Seems like a simple thing, a simple question, right? Well, there are a few facets to it that do actually make it quite important:

If you are distributing your software to your own customers, it’s important that your brand is reflected at every point in the distribution chain - from purchase to delivery. Using your own domain name for your repositories also reassures your customers and users that they are accessing an authoritative source.

And even if you are not distributing to external customers, using your own domain is a sign to your internal development teams that they are dealing with a company resource. It’s reassuring, and it makes integrating an external service like Cloudsmith that little bit more transparent.

Using your own domain name for your repositories means that you are in control of how you implement additional security features for that domain, such as DNSSEC (signed DNS request/responses) and CAA (enforced certificate authorities). It’s your domain, you control it, not Cloudsmith.

Also, it reduces typo-squatting. Using custom domains removes things like your Cloudsmith organization name, and even the repository name, from the URL. Therefore, they can't be entered incorrectly.

Cloudsmith Blog