For any developer, the road to launching a new feature for a high-traffic, consumer-facing web storefront can be a rocky one. Before a single line of code can be properly tested in a production-like environment, teams often face the operational burdens of manual DNS setup, custom domain registration, certificate management, and the required IT involvement that slows everything down. Setting up a new development or testing environment has traditionally been a process filled with friction, delaying innovation and extending time-to-market.

Salesforce Commerce Cloud is removing these obstacles with a powerful new capability: the Default Domain. This out-of-the-box feature provides an instantly available, eCDN-ready hostname for every instance, eliminating the setup headaches that have long frustrated developers. This post breaks down the five most impactful takeaways of this new capability.

Takeaway 1: Default Domain support for B2C Commerce

The Default Domain is far more than a simple placeholder URL; it’s an immediately eCDN-ready environment right out of the box, meaning the CDN layer and HTTPS are already configured. This is a critical distinction that transforms how development and testing can be approached.

Built-in eCDN integration enables developers to test crucial, real-world functionality in a non-production environment that accurately mimics the final production setup. Development teams can now validate PWA Kit performance, fine-tune security rules, test complex caching strategies, and conduct performance tuning early and often.

The key benefit is the ability to prevent production issues by discovering them and addressing them earlier in the development cycle. By testing in a truly production-like environment from day one, you mitigate the risk that improper domain or certificate setup will lead to outages or insecure (HTTP) traffic when you go live. For more information, see Default Domain Support for B2C Commerce.

Administration UI showing Embedded CDN Settings

Takeaway 2: Security is built in, not bolted on

With the Default Domain, security is a built-in feature, not an afterthought. HTTPS is automatically enabled because Salesforce manages the entire SSL/TLS certificate lifecycle. This completely eliminates any manual work for developers related to certificate provisioning, uploading, or renewal.

Production instances using a Default Domain have a “secure by default” posture. To prevent accidental public exposure, production instances are preconfigured with a “Block All” firewall rule at the eCDN layer. Development teams must explicitly add “Allow” rules for specific sites or paths they want to make accessible, ensuring nothing goes public until it’s truly ready. (Remember: rules are executed from top to bottom, so any custom “Allow” rules must be placed above the default block.)

Development and Staging instances are also protected by default, requiring user credentials for access to safeguard these lower environments from unwanted public traffic.

Administration UI showing SSL/TLS Settings

Takeaway 3: All of the control, none of the paperwork

Contrary to the common misconception that managed domains limit control, with the Default Domain developers have full eCDN configuration access through both the CDN API and the familiar Business Manager UI.

You retain complete control over customizing and testing the eCDN settings for your Default Domain, including:

This allows you to fully customize and validate your eCDN setup for a new project or feature without any risk of affecting the configuration of your production custom domains.

Administration UI showing WAF Settings

Takeaway 4: A complement to, not a replacement for, your custom domain

It’s crucial to understand that the Default Domain does not replace or alter the functionality of your existing custom domains (also known as vanity domains), like www.TheWidgetStorefront.com.

The two types of domains can coexist on the same instance. Your custom domain remains the preferred choice for external-facing, branded storefronts that your shoppers interact with. (While the Default Domain can be made publicly accessible if explicitly configured, it is not intended for that purpose.) The configuration of your custom domain is not affected by any changes made to the Default Domain.

The Default Domain serves a different, but equally important, purpose. Its primary use case is for internal-facing tasks – such as developer testing, load testing, and pre-production reviews – enabled by eCDN functionality in environments where setting up a custom domain is neither practical nor necessary.

Administration UI showing Embedded CDN Settings with Default and Proxy Zones

Takeaway 5: More than a feature, a foundation for the future

While its immediate benefits are clear, the Default Domain is also a strategic platform enhancement that paves the way for future innovation. Specifically, Default Domain support is a critical prerequisite for enabling eCDN for on-demand sandboxes (ODS), which are planned for later this year.

This connection addresses persistent developer pain points identified through voice-of-the-customer feedback. For teams adopting composable storefronts, the lack of easy eCDN testing in sandboxes has created major friction. Limited local development support for hybrid environments has required teams to create many custom proxies, a cumbersome workaround that slows development cycles and that eCDN-enabled on-demand sandboxes would eliminate.

Conclusion

As a foundational capability, the Default Domain enables faster deployment, enhanced site security, and more streamlined composable development workflows on Commerce Cloud.

The Default Domain removes friction from the Commerce Cloud development process by eliminating the operational burden of domain and certificate management. The result is more time to focus on what you do best: building innovative features and exceptional customer experiences.

Resources

About the author

Raghu Venkatraman is a Product Management Director at Salesforce, where he drives product strategy and innovation. With extensive experience in enterprise software and a passion for building user-centric solutions, Raghu focuses on delivering products that empower organizations to work more efficiently and effectively. He brings deep expertise in product leadership and cross-functional collaboration to help customers maximize their Salesforce investments. Follow him on LinkedIn.

Deep Shrestha is a Principal Member of Technical Staff at Salesforce, specializing in software engineering and technical architecture. With a strong background in building scalable, robust solutions, Deep brings technical depth and innovation to complex engineering challenges. His expertise spans system design, implementation, and delivering high-quality software that meets the evolving needs of enterprise customers. Follow him on LinkedIn.