This guide assumes that you have access to the Runtime Admin web application and the Managed Runtime API to perform administrative tasks. To get access to these tools, contact your B2C Commerce administrator and ask them to add either one of the following roles to your account using Account Manager: Managed Runtime User or Managed Runtime Admin.
To make requests to the Managed Runtime API, you must include an API key in the HTTP request Authorization header with the value, Bearer $API_KEY. For all the sample requests provided, don’t forget to replace $API_KEY with your actual API key.
Important: Treat your API key like a password because it allows scripts to complete operations on your behalf.
You need access to your DNS provider to create and update CNAME records, as well as access to your third-party CDN provider (as applicable).
What Is Mobify?
In this guide, the word “Mobify” appears in a few places. Mobify is the name of the company that originally developed the technology that became PWA Kit and Managed Runtime. In 2020, Salesforce acquired Mobify along with all of its technology.
The Mobify brand name appears in the mobify-storefront.com domain used to host your storefront and the cloud.mobify.com domain used by the Managed Runtime API.
Use a Custom Domain for Local Development
If you need to add conditional logic that alters the behavior of your site depending on the domain used, it’s easier to test this logic when your local development server can use a custom domain. Why would you need to add this kind of logic? Consider, for example, the need to look up a different SLAS Client ID depending on the domain.
To run your local development server using a custom domain:
Modify your local computer’s DNS to resolve your custom domain to 127.0.0.1 (localhost).
Edit ssr.js.
In the options passed to runtime.createHandler, set the port to 80.
Run EXTERNAL_DOMAIN_NAME=www.example.com npm start, replacing the value of example.com with your custom domain. Running the server on port 80 can sometimes require administrative privileges.
Requests from your browser to the custom domain are now resolved and routed to your local development server!
Launching an Environment
The process for launching an environment is the same for staging and production, with the only difference being the domain name and the Managed Runtime environment used.
We strongly recommend going through the launch process on a staging environment first before repeating the process on production. These steps should be completed as soon as you start a PWA Kit project and at least two weeks before your launch date.
Warning
For the instructions provided, imagine you’re launching a storefront at staging.example.com, your project ID in Managed Runtime is example, and your bundle is deployed to an environment called staging.
Here’s a sample request that uses the projects_target_create endpoint to create an environment. Replace example in the request with your actual project ID string and $API_KEY with your API key:
Many PWA Kit implementations make requests to OCAPI or controllers in addition to B2C Commerce API.
You must ensure your B2C Commerce instance is reachable by Managed Runtime.
Making the APIs reachable typically involves configuring eCDN to make your B2C Commerce instance available at an alternative domain like ecom.example.com. For more information, refer to the eCDN setup and configuration documentation.
After your domain is configured, update your environment’s proxy settings to use it. For more information, see our guide to Proxying Requests.
3. TLS Certificates
This step is not required when using a third-party CDN or eCDN. Consult your CDN vendor documentation for configuring certs.
Important
If you are routing traffic directly to the Managed Runtime CDN, then Managed Runtime issues and manages TLS certificates on your behalf.
Certificate Management
Organization Admins and Organization Users with the Managed Certificates permission can now manage TLS certificates directly through Runtime Admin. This provides enhanced control over certificate lifecycle management without requiring support tickets for routine certificate operations.
Prerequisites for Certificate Management:
Organization Admin role OR Organization User with Managed Certificates permission assigned.
This step isn’t required when using a third-party CDN or eCDN.
Important
Reduce the time to live (TTL) for staging.example.com to one minute. Reducing the TTL speeds up the DNS cutover process, and if something goes wrong, allows you to roll back quickly.
The access control header value will be used during Perform the Cutover to prevent direct access to the environment.
Option 2: Use the Managed Runtime CDN
Configure the environment to receive traffic from the host staging.example.com.
Navigate to the Environment Settings page.
Under Advanced, click Edit.
Select the desired certificate (staging.example.com or *.example.com).
Provide a subdomain if using a wildcard certificate.
Click Save.
Optionally, you can configure the environment via the API. Update the environment’s ssr_external_domain and ssr_external_hostname settings using the projects_target_partial_update API.
The cutover process is different depending on whether you use a third-party CDN, eCDN, or the Managed Runtime CDN.
Option 1: Use a Third-Party CDN
Configure your Managed Runtime environment as an origin in your CDN:
set the Host header to match your environment {{project}}-{{environment}}.sfdc-8tgtt5-ecom1.exp-delivery.com
forward the request method
forward the path (including query string)
forward the headers
forward the body
forward all traffic over HTTPS
obey HTTP caching headers
set the x-sfdc-access-control header value if configured for your environment
Refer to your CDN provider documentation for detailed guidance.
Managed Runtime routes requests to environments using the HTTP Host header. Requests with an incorrect host are rejected with an HTTP 403 Bad Request response.
Note
Consider adding a handler to reflect HTTP requests and verify that your CDN is configured correctly:
Use the upsertOriginHeaderModification API to set the headerValue to the same ones that you used in step 5. That way, only traffic from eCDN is allowed.
In this example, we use the API to set an access control header with the header value 25pn5dec7f1c:
Where {{project}} is your project ID, and {{environment}} is your environment ID.
Update Your DNS Records
Update the DNS CNAME record for staging.example.com to the value shown in your DNS configuration (e.g., example-staging-cdn.sfdc-8tgtt5-ecom1.exp-delivery.com).
Open your web browser and navigate to staging.example.com.
Congrats, you’ve completed your launch! 🥳
After completing these instructions for a staging site, you can repeat the same process with the production domain and production environment.
7. Site Monitoring
From here, the Customer Success Group assists you in monitoring the site’s traffic to make sure that the launch has succeeded. The goal is to ensure that everything happens as expected during launch!
After launch, customers with a Signature Success Plan receive proactive site monitoring. To take advantage of this increased monitoring service, you must mark your environment as production. For more information, see the section on environments in the Managed Runtime Overview.
Technical Limitations
The ssr_external_hostname target setting controls which host the environment receives traffic from. If the HTTP Host header of a request doesn’t match this value, the request fails with a 403 error.
Currently, Salesforce doesn’t support storefront URLs with a bare domain like example.com (with no www subdomain). To use a bare domain, you must set up a server to redirect requests from the bare domain to your CNAME.