Let’s GO-LIVE: eCDN

So, you want to set a website live on Salesforce B2C Commerce Cloud. It is all relatively new to you, but your task is to set up the Staging and Production instance to prepare your “GO-LIVE.”

Not to worry! The eCDN is not rocket science, far from it. Once you have set up your first vanity domain, the second one will be peanuts.

Note

Updated July 2026: The eCDN has moved on since this guide was written in 2022. WAFv2 replaced the old firewall, TLS 1.3 shed its beta label, Cloudflare retired Auto Minify, certificates learned to renew themselves, and staging got its own Business Manager module. Every section below has been brought in line with the current platform, and the 2022 behaviour is preserved in “for the archives” notes where it still tells you something. The go-live warnings from the original (added back then with thanks to Sachin Upmanyu) still stand.

What is the eCDN

But first things first: what exactly are we configuring? The datasheet I quoted here in 2022 has since vanished from Salesforce’s site. The current help page keeps it drier: the eCDN is “a geographically distributed network of proxy servers” that sits in front of your storefront to improve speed, availability, and security.

Note

For the archives: the vanished datasheet described the feature as “an embedded content delivery network (eCDN) designed to accelerate site speed access and content delivery. The end result is a more secure, reliable online shopping experience for the consumer.” Marketing prose ages even faster than the product.

Ok, ok. That still might not explain what the eCDN is and does.

To put it in simple terms: it’s Cloudflare! If you have been active in web development for a while, you probably are already familiar with the service.

For the most part, Salesforce has put itself in between and taken complete control of the Cloudflare configuration. But luckily, they have left us with a few buttons and switches to fiddle with in the Business Manager.

Within this interface, you can configure:

• Your supported vanity domains
• SSL certificates
• The firewall & WAF (Web Application Firewall)
• Performance optimisation
• Custom error and under-attack pages

Getting Prepared

Before configuring the Production Business Manager, a few things need to be in place.

Domain

This one should be pretty obvious, but I’ll mention it anyway. Make sure the domains you will be using have been purchased. If you don’t own the domains, you won’t be able to point them to Salesforce B2C Commerce Cloud.

Note

No vanity domain yet? Since the 26.3 release, every development, staging, and production instance ships with a Default Domain: a Salesforce-managed hostname that is already behind the eCDN, with the whole certificate lifecycle handled for you (On-Demand Sandboxes joined with 26.4). It does not replace a vanity domain for go-live, but it lets you test eCDN behaviour while the domain purchase is still stuck in procurement.

DNS Configuration Access

To point the domain to Salesforce B2C Commerce Cloud, you need access to the domain DNS configuration. In later steps, you (or someone else you are in contact with) must add TXT and CNAME records to the DNS configuration.

Warning

APEX Domain Pointing / Naked Domain: An APEX (naked) domain can not carry a CNAME record, so the eCDN can not serve it directly.

With a naked domain we mean https://mybrand.com (without the www).

Most DNS providers have a workaround for this, but plan for it. In a worst-case scenario, you need a “mini-server” whose only job is redirecting the naked domain to the www subdomain. Salesforce documents the limitation and the recommended redirect on the help site.

Get your SSL certificates (or don’t)

We have come to a time where no website should operate without a secure connection. To achieve that, an SSL certificate is required. “Getting” one, though, no longer has to mean buying one. The eCDN supports two flavours:

• eCDN-managed certificates: Salesforce provisions the certificate through Let’s Encrypt or Google Trust Services and, since the 23.6 release, renews it automatically. No private keys to guard, and no renewal reminder that everyone ignores until the storefront goes down.
• Custom certificates: the classic route. You purchase a certificate and upload it together with its private key, and its renewal remains your problem. Still the way to go if you need certificate pinning, extended validation, or a specific certificate authority.

For a new project, the managed certificate is the sensible default. If you go the custom route, have the certificate and the private key at hand before you start the configuration.

Note

For the archives: in 2022, buying a certificate and guarding its private key was the only route, and this section simply sent you off to research “how to get an SSL certificate” as part of the go-live preparation. That homework assignment is now optional.

Alias Configuration

Before a domain becomes available in the eCDN, it must appear in the alias configuration of at least one site.

An example config you can use to get you up and running quickly:

{
  "__version": "1",
  "settings": {
    "http-host": "www.my-domain.com",
    "https-host": "www.my-domain.com"
  }
}

Once an Alias is configured on at least one site in your production environment, we can continue to the next step!

Note

Alias Configuration: Setting up this configuration can be a pain in the ***, so be prepared to fiddle around with it for a few hours if you are unfamiliar with it, especially if you are handling multiple sites with multiple domains.

Add the domain to the eCDN

Note

Use the correct environment: For a go-live, the eCDN is set up on the production instance. Staging gained its own Embedded CDN Settings module in the 24.4 release (retiring the API-only dance it required before), and settings are per instance: nothing you configure on staging replicates to production, or the other way around.

Warning

Zone Creation with care: Once a zone is created, you can not delete it yourself, not even through the CDN Zones API. You will have to go through support to undo this.

To get to the eCDN configuration, go to

“Administration” > “Sites” > “Embedded CDN Settings”

Once the page has loaded (be patient), you will see the following at the top right of the page.

You should see the message “x hostname(s) available” if everything goes well. If not, go back to the Alias configuration to verify everything was saved correctly.

Click “Add Hostname.” A screen should show your configured Alias domain and to which site it is assigned.

Click “Create Zone.” Be patient; it can take a while before something happens.

Verify ownership of the domain

Once the page responds in the previous step, you should see something like this.

If you see the above, you are well on your way! But there is a clear message: “Verification needed.”

Before continuing, we need to verify that we own the domain. Click the text “Verification needed,” and you will see more information on the next steps.

This builds on the pre-work steps where you need access to the domain’s DNS. Before we can continue with the following steps, a TXT record with the provided value needs to be added to the DNS settings of your domain.

DO NOT DO THIS ON THE DAY OF THE GO-LIVE.

As the warning says, it can take up to 6 hours for these changes to take effect. And on the go-live day, you don’t want to spend your time “stressing out” on something you have no control over.

From personal experience, this usually takes a couple of minutes rather than hours. But the warning is there for a reason!

Domain Configuration

Now that we are a “verified owner” of the domain within the eCDN, we can start configuring that domain.

To start, click the “settings” to the right of the top-level domain.

Set up an SSL Certificate

The first screen you will land on is the “crypto” settings. This is where you manage everything about SSL and TLS.

For a new setup, the path of least resistance is an eCDN-managed certificate. Click “Add Certificate”, tick “eCDN Managed Certificate”, pick a certificate authority (Let’s Encrypt or Google) and a validation method (HTTP does the job in most cases), and let Salesforce handle every renewal after that. The 23.10 release brought those renewals into Business Manager as well, and Salesforce Support recorded a five-minute walkthrough of the whole flow.

Uploading your own certificate still works the same way it did in 2022: leave the managed checkbox unticked and paste away.

The screen itself is pretty self-explanatory. If you followed the “get prepared” section at the beginning of this article, these should already be in your possession.

Once entered, the system will validate if it is correct. If it passes the validation, click “Upload Certificate,” and bam… you are done!

TLS 1.3

The 2022 version of this section poked fun at a checkbox: “Enable TLS 1.3 (beta)” had been carrying that beta label for two years, and I had enabled it on most projects with no adverse effects.

That discussion is now closed. With the 26.2 release, Salesforce made TLS 1.3 support on the eCDN mandatory rather than optional. Browsers that do not speak TLS 1.3 fall back to TLS 1.2. Curious what the protocol actually brings? The Cloudflare Docs explain it well, and these days without a beta warning in sight.

HSTS

Once a certificate is in place, the same Crypto tab offers HSTS (HTTP Strict Transport Security). Don’t see it? There is a feature switch for it under “Administration” > “Global Preferences” > “Feature Switches”.

Enabling this option will tell browsers that your domain only operates over HTTPS and that all HTTP connections should be blocked.

Since this includes all subdomains, ensure that no system besides Commerce Cloud operates on HTTP. Otherwise, people will be “barred” from using that site until the max-age you configured runs out. And think twice before ticking “preload”: getting off the preload list again takes months.

Firewall Settings

You can manage the Security Level and Trusted IP Addresses in the firewall settings.

As the help popup explains, this part of the firewall judges visitors by the reputation of their IP address.

Using the IP Allowlisting feature, you can inform the firewall to ignore specific IPs.

Need something more precise than a trust list? The 24.2 release replaced the old firewall rules with custom rules in the CDN Zones API, which can block, log, or challenge traffic based on expressions such as the URI path or user agent.

WAF Settings

The WAF (Web Application Firewall) looks beyond IP reputation and inspects the requests themselves for malicious patterns.

This part of the article needed the biggest rewrite. The WAF you configure today is not the one from 2022: Salesforce introduced WAFv2 with the 24.5 release, added a self-service migration button in 24.7, and required every zone to be migrated by February 1, 2025. Whatever zone you are configuring now, it is running WAFv2.

Instead of the single OWASP rule list from the old days, WAFv2 gives every zone three managed rulesets:

• eCDN managed ruleset: rules maintained by the Salesforce security team.
• OWASP Core Ruleset: based on the official OWASP project. Rather than each rule acting on its own, matched rules add up to a threat score, and the zone responds when the total gets too high.
• Exposed credentials check: compares login attempts against databases of leaked credentials.

In the eCDN and exposed-credentials rulesets, individual rules can be overridden with actions such as block, log, or managed challenge; the OWASP ruleset acts on its combined score instead. And one thing to plan for: WAF settings live per instance and are never replicated, so an exception you validated on staging has to be applied to production by hand. Salesforce documents the details on the help site and in the CDN Zones WAFv2 guide.

Note

For the archives: WAFv1 gave you a single OWASP ruleset with one action dropdown and a sensitivity level, and that was the whole configuration surface in Business Manager (the CDN Zones API could tune individual WAFv1 rule groups underneath). If the screenshot below looks nothing like your Business Manager, that is a good sign: it means your zone was migrated.

Download Log Files

In this section, you can also download log files per hour. Keep in mind that this is an asynchronous operation: after clicking “Request Log,” an email with a download link arrives a little later (usually not so long).

These files contain a log of all network traffic, how the WAF analysed it, and how it responded. They are kept for seven days, so fetch them while they are fresh.

The hourly download is no longer the only option, though. CDN Logpush (added in the 23.6 release) streams request and firewall logs continuously to destinations such as Amazon S3, Datadog, or Splunk. Log Center joined the party in 25.10, adding eCDN error logs for production proxy zones.

Speed Settings

This section used to open with advice about Auto Minify, the Cloudflare feature that stripped comments and whitespace from your HTML, CSS, and JavaScript. You can forget that advice: Cloudflare retired Auto Minify in August 2024 after concluding it barely moved the needle for sites that already minify at build time, and Salesforce removed the checkboxes from Business Manager in the 24.10 release. If you counted on it to strip HTML comments, that job now belongs to your build pipeline.

Note

For the archives: HTML minification mostly deleted comments from your markup. If an external system relied on those comments, the advice was to leave that checkbox alone. It also broke the (equally deprecated) Storefront Toolkit on the Development instance, which depended on them.

The tab did not stay empty, though. A block of optimisation toggles has taken Auto-Minify’s place: plain checkboxes for Early Hints, Brotli, HTTP/3, and HTTP/2 to Origin. Those used to require API calls; more on that in the last section.

Polish, Cloudflare’s image optimisation, also lives on this tab, and that one is still worth your attention.

One thing to watch out for: “Polish Level Basic+JPEG” uses lossy compression, so your images might lose quality. If you work for a brand that wants crisp and clear photos, do extensive testing before permanently enabling it. “Polish Level Basic” sticks to lossless compression and is the safer starting point.

Enabling WebP remains a no-brainer. The 2022 version of this article claimed Safari did not support the format; that claim had already expired when I wrote it. Safari gained WebP support in version 14 (2020), with the small print that it required macOS Big Sur, and today every major browser handles it. With the option enabled, Polish serves a WebP variant when the browser asks for one and the conversion actually saves a meaningful number of bytes.

Customise Settings

A section you hope you will never need. When “**** hits the fan,” Cloudflare provides standard error pages. In this section, you can choose to load your own rather than the default.

Commerce API Configuration

In 2022, the headline advice of this section was that some Cloudflare features could only be enabled through the CDN Zones API. That gap has been shrinking ever since: Brotli, Early Hints, HTTP/3, and HTTP/2 to Origin have all landed in the Speed tab shown earlier.

The advice behind it still stands, because none of these are switched on for you:

• Brotli Compression: Cloudflare compresses responses by default on its self-serve plans these days, but eCDN zones are Enterprise zones and do not get that default, so this flag is still ours to flip.
• HTTP/2 Prioritisation: the one speed setting that has not made the jump to Business Manager, so the API remains the way to enable it. It helps a lot on lister pages with many images processed by the DIS (Dynamic Image Service). Do test it, though: Cloudflare documents cases where it slows down content loading in Safari on macOS and in any browser on iOS.

Make sure you do not forget about these! The same API family also covers cache purging, Logpush, custom rules, rate limiting, and the WAFv2 configuration. And if raw REST calls are not your thing, the official B2C Developer Toolkit CLI now wraps most of it in a b2c ecdn command.

That is the eCDN tour, 2026 edition. The platform keeps absorbing more of the Cloudflare feature set, and more of the instance types keep joining the eCDN, so expect this article to age again. The vanity-domain flow itself has barely changed, though: alias, zone, TXT record, certificate. Once you have done it once, the second one really is peanuts.