You've planned your migration to Cloudsmith: you know you need hybrid repository structures, granular access controls, retention policies and vulnerability scans.
However, there is one foundational decision that must be settled first, because it underpins all subsequent security and distribution configurations: setting up custom domains for your package distribution.
While it may appear to be just another configuration option - custom domains are fundamental to establishing trust, security, and professional credibility in your software supply chain. Let's explore why.
By default, when you access packages from Cloudsmith, your URLs follow a pattern that includes Cloudsmith's domain. With custom domains, you replace this with your company's own subdomain - something like docker.artifacts.yourcompany.com or packages.yourcompany.com. It's a simple DNS configuration that creates a profound shift in how your artifact distribution is perceived and secured.
When distributing software - whether to internal developers or external customers, using your own domain reinforces your brand at every touchpoint. Consider the developer experience: which feels more trustworthy? A third-party domain with your organisation name embedded in the path, or a clean domain that's clearly part of your company's infrastructure?
The custom domain maintains a professional appearance across all distribution channels and eliminates confusion about software authenticity. Many team members and customers may not even know (or need to know) that you're using Cloudsmith under the hood. Using your own domain reassures they're accessing an authoritative source directly from your organisation.
While branding matters, security is where custom domains truly shine. The benefits span multiple layers:
Tailored Rate Limiting is perhaps the most immediate advantage. Custom domains place you on dedicated CDN infrastructure with workspace-specific rate limits. Unlike shared Cloudsmith domains where you're subject to general limits alongside all other customers - custom domains allow you to configure rate limits that match your company's legitimate traffic patterns. This is particularly valuable during migration when transferring large volumes of packages, but it's equally important post-migration, for protecting against denial-of-service attacks with customised thresholds.
Enhanced Monitoring and Visibility becomes dramatically easier with custom domains. They integrate seamlessly with your security infrastructure, allowing you to monitor traffic patterns specific to your domain in firewall and proxy logs. You can integrate these metrics directly into your SIEM and monitoring tools like Datadog, set up domain-specific alerts and anomaly detection, and track DNS queries in your own logs. This visibility is invaluable for detecting unusual access patterns or potential security incidents before they become problems.
Finally, custom domains offer a simplified URL structure that reduces your attack surface. By removing your Cloudsmith organisation name and/ or repository name from URLs, you lower the risk of typosquatting - a common attack vector where malicious actors register lookalike domains to hijack traffic. With a dedicated, simplified domain, there's far less chance of a mistyped link leading somewhere it shouldn’t.
As you plan your custom domain strategy, several key considerations will help ensure success:
Not all package formats work the same way. Formats like Docker, npm, and NuGet have native API protocols and can use format-specific custom domains. However, formats like Debian, RPM, and Helm rely on static file downloads and need a single catch-all download domain. This distinction matters, because native API formats communicate through structured API calls, while download-only formats construct file paths from metadata files.
Trying to set up format-specific domains for download-only formats creates debugging nightmares - packages become accessible through multiple domains inconsistently, and metadata may reference different URLs. Document your domain pattern clearly for your team so they know which URLs to use and can troubleshoot effectively.
Most customers benefit from account-level domains that work across all repositories in your Cloudsmith organisation. This approach simplifies governance and reduces configuration overhead, making it ideal for organisations with centralised artifact management.
However, per-repository domains make sense when distributing different products to different customers or when you need fine-grained control and branding per product line. This approach works well for multi-tenant scenarios where each product needs its own identity.
Custom domains are the final, essential step in taking full control of your software supply chain. By implementing custom domains with Cloudsmith, you are fundamentally investing in:
By submitting this form, you agree to our privacy policy
