Build Trust with a Custom Domain

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 dl.mydomain.com or pkgs.mydomain.com 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:

Identity and Brand Awareness

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.

Overall, it just looks better.

Security and Control

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.

Flexibility

Cloudsmith Custom Domains are a good example of our “no vendor lock-in” philosophy.

Once you have set up and started to use your private repositories, you may have tens, hundreds or even thousands of build definitions, package manager configurations and scripts across your organizations’ projects.

Let’s say your private repositories are located at a domain such as https://dl.vendor.com/mycompany. Should you at any point in the future decide to move your repositories to another vendor or location, you would then need to update all of these configurations. This could be no small task and quite the upheaval.

However, if your repositories are located at say https://dl.mycompany.com, then you can just continue to use these URIs (provided, of course, that your new vendor also provides the same “no vendor lock-in” approach as Cloudsmith does!). Your configs, build processes etc can all stay the same. In the background, your packages can all be migrated to a new location and your processes need be none-the-wiser. It’s fully decoupled.

Summary

Custom Domains give you more control over the Identity and Security of your hosted repositories and also provide you with more flexibility going forwards. They are one of the key features that differentiate Cloudsmith repositories from alternative solutions.

Liked this article? Don\'t be selfish (:-), share with others:   Tweet