Manage Your Environments in Business Manager (Beta)
Managed Runtime environments are isolated deployments of your Storefront Next app. Use an environment while you develop your storefront. Test your app in a development environment, host the storefront in a staging environment after you test it, and move it to production when you release it. Each environment has its own URL, bundle deployment, environment variables, and eCDN configuration. Manage environments in Business Manager from the Storefronts page for your storefront.
Developer Workspace is a pilot or beta service that is subject to the Beta Services Terms at Agreements - Salesforce.com or a written Unified Pilot Agreement if executed by Customer, and applicable terms in the Product Terms Directory. Use of this pilot or beta service is at the Customer’s sole discretion.
Important
Every storefront has one primary environment and can have additional environments for development, staging, or other purposes.
Prerequisites
To manage an environment, you must have the “Storefront Environments” Business Manager permission for a specific storefront with appropriate read, write, and delete rights.
To manage URL redirects, you must have the “Storefront URL Redirects” Business Manager permission for a specific storefront with appropriate read, write, and delete rights.
Primary Environment
The primary environment is the default environment for your storefront. Use it as the target for:
Page Designer: Content previews and layout editing.
Environments list: The first environment shown for your storefront.
Storefront Preview: Live preview in the Storefront Toolkit.
Change the Primary Environment
Change the primary environment at any time from Storefront Settings. The change doesn’t affect your storefront or active deployments.
In Business Manager, go to Administration > Storefronts > Your Storefront.
Click Storefront Settings.
Under Primary Environment, select the environment to set as primary.
The primary environment change takes effect immediately.
You can’t delete the primary environment while it is set as primary. Before deleting it, set a different environment as primary from Storefront Settings.
Note
Create Environments
Create additional environments for development, testing, staging, or other deployment workflows alongside your primary environment. Each environment has the same capabilities as the primary environment: bundle deployments, environment variables, eCDN zones, and routing rules.
To create an environment:
In Business Manager, go to Administration > Storefronts > Your Storefront.
Click Storefront Settings.
Click Environments, and then click Create.
Enter a name.
Environment creation can take up to 30 minutes. Business Manager sends an email when the environment is ready.
Clone or Delete an Environment
A clone copies an existing environment’s name and, optionally, its redirects and environment variables. A clone doesn’t copy the production status. Deleting an environment removes all related resources and system configurations from Managed Runtime. You can’t undo this action. Clone or delete an environment from the Environments page.
Edit Environment Settings
Edit environment settings, including production settings, deployment settings such as the deployment region, and logging settings. Rename an environment from the same page.
In Business Manager, go to Administration > Storefronts > Your Storefront.
Under Primary or Additional Environments, next to the environment, open the dropdown menu, and then select Environment Settings.
Click Edit next to the setting section, and then modify the setting.
Save your changes.
Environment Constraints
Each storefront has a limit on the number of environments. When you reach the limit, you must delete an existing environment before creating a new one. To request a higher limit, contact Salesforce Customer Support.
For environments not created in Business Manager, they only respond to requests whose HTTP Host header matches their External Hostname set in Runtime Admin. For environments created in Business Manager, which have eCDN default domains, the host header is automatically set.
The path / only accepts HTTP GET requests.
Request and response size can’t exceed 6 MB.
The maximum size of the HTTP request line and headers is 10,240 bytes. Requests exceeding this size return an HTTP 413 Content Too Large.
Of the 10,240 bytes, 1,500 bytes are reserved for internal use, 1,800 bytes for authorization headers, and 1,000 bytes for Salesforce B2C Commerce API (SCAPI). 5,940 bytes are left for custom request headers, including cookies.
Requests with headers that start with _ aren’t supported. These requests are dropped.
HTTP requests originating from Managed Runtime environments don’t use fixed IP addresses. To allowlist requests from the app server, use the AWS IP Range for EC2.
The path prefix /mobify is reserved for managed endpoints. These endpoints include:
/mobify/ping: Returns an HTTP 200 response code when the environment is operating correctly.
Storefront Next preconfigures access control headers for the default domain. For vanity domains, configure them manually. For more information, see Access Control Headers in the Composable Storefront Guide. Storefront Next environments support up to 4 access control headers. Each header:
Can contain up to 128 characters.
Can be a combination of alphanumeric characters and - and _ characters.
Access Control Headers
Access control headers limit incoming traffic to trusted sources, such as a CDN or your development team. An environment that has access control headers accepts only requests that include the x-sfdc-access-control HTTP header with a valid value. This blocks bots that bypass CDN security, and it blocks search crawlers from indexing non-production environments.
In Storefront Next, access control headers are read-only in Business Manager. View the headers for an environment in Business Manager. Add or remove them with the Managed Runtime API.
Server-side code in the environment can’t read access control header values. The infrastructure layer enforces the headers before requests reach your storefront.
Note
Header Value Requirements
Each access control header value meets these requirements:
Minimum length: 9 characters
Maximum length: 128 characters
Allowed characters: alphanumeric characters, hyphens, and underscores
Storefront Next environments support up to four access control header values. Use multiple values to rotate headers without downtime.
Rotate Headers
To rotate an access control header value without downtime:
Add the new header value with the Managed Runtime API.
Wait for the deployment to complete.
Update your CDN or proxy to send the new header value.
Verify that the environment accepts requests with the new value.
Remove the old header value with the Managed Runtime API.
Storefront Next enables server-side cookies. You can’t configure them. Storefront Next uses HttpOnly cookies for all authentication tokens. See Cookie Architecture.
Source Maps
Production builds generate source maps by default with Vite’s build.sourcemap option. Source maps connect minified code to your original source files, so stack traces stay readable when errors occur.
Storefront Next environments turn on source maps by default. If the setting is off, turn it on in Business Manager:
Go to Administration > Storefronts > Your Storefront.
From the dropdown menu next to an environment, select Environment Settings.
Click Edit, and then turn on Source Maps.
When you turn on source maps, the MRT server starts with the Node.js --enable-source-maps flag. This flag can affect performance.
Note
Set up source map generation in vite.config.ts. See Source Maps.
Environment Variables
Environment variables are key-value pairs stored outside your application code that configure your storefront’s runtime behavior per environment. Use them to supply secrets, API endpoints, feature flags, and other settings that differ between development, staging, and production without changing your codebase.
URL redirects forward site visitors and search engines from an old URL to a new URL. Use redirects to preserve SEO rankings and to maintain the shopper experience during storefront changes such as campaign transitions, URL restructuring, or content moves.
Redirects can have significant security consequences if misconfigured. Avoid redirecting to untrusted external URLs.
Warning
Redirects are configured per environment. Each environment maintains its own set of redirects independently.
Manage URL Redirects
In Business Manager, go to Merchant Tools > Storefronts > Your Storefront.
From the dropdown menu next to an environment, select Environment Settings.
Click URL Redirects.
Create a Redirect
Before creating a redirect in a production environment, we recommend that you create it and test it in a staging environment. Then clone it to production.
Tip
On the URL Redirects tab, click New.
In the From field, enter the relative path to redirect from (for example, /winter). Use * at the end of the path to match all paths with that prefix.
In the To field, enter the destination path or full URL.
Select the HTTP status code: 301 for a permanent redirect or 302 for a temporary redirect.
Optionally enable forwarding rules:
Forward Query Parameters: Includes query parameters from the source URL in the redirect.
Forward Wildcard: Appends the matched path segment to the destination URL when using a wildcard source path.
Click Save.
New redirects have a Publishing status while they propagate. After a redirect is active, the status changes to Active.
The value that you enter in the Redirect From field is always a relative path. The Redirect To field is a relative path or a full URL. For example, to redirect visitors from www.example.com/spring to www.example.com/summer, enter /spring in Redirect From. Enter /summer or www.example.com/summer in Redirect To.
Wildcards
Add an asterisk (*) to the end of the Redirect From URL to indicate a wildcard. A wildcard matches zero or more characters in the URL. For example, a redirect from /a/* matches /a/, /a/b, and /a/b/c.
Use a wildcard only at the end of the Redirect From URL.
Standard redirects are processed first by Managed Runtime, followed by redirects with wildcards.
HTTP Status Codes
Most redirects use the Permanent 301 status code. Select Temporary 302 for a temporary redirect. If you aren’t sure which HTTP status code to use, see this status code explainer from Moz.
Forwarding Query Parameters
Some requests contain query string parameters to include in the redirected request. For example, append a query string for analytics tracking to /spring-landing-page, such as /spring-landing-page?gclid=123.
To turn on query parameter forwarding, go to the Forward section of the form, and then select Query Parameters. Otherwise, the redirect URL omits query string parameters from the source URL.
When Redirect From and Redirect To both include query strings and forwarding is on, the redirect URL combines the two query strings. Managed Runtime appends the query parameters from Redirect To to the query string in the request. For example, the app receives a request for /spring?year=2019. If you redirect /spring to /summer?year=2020 and forwarding is on, the redirect URL is /summer?year=2019&year=2020.
Forwarding Wildcard Path
You can automatically include any path that comes after the wildcard portion of the Redirect From URL in the Redirect To URL. For example: if /a/* matches /a/b/c in the Redirect From URL, and the Redirect To URL is /z/, the redirect URL is /z/b/c.
To enable wildcard path forwarding, go to the Forward section of the form and select Wildcard Path.
When you clone redirects, you’re replacing all the redirects in the destination environment with all the redirects from the source environment.
Warning
Edit, Delete, or Clone Redirects to Another Environment
Edits and deletes are only available while a redirect has Active status. Cloning copies all redirects from one environment to another. Cloning useful when promoting a set of redirects from staging to production.
Cloning replaces all existing redirects in the destination environment with the redirects from the source environment.
Warning
Troubleshooting Redirects
If a redirect doesn’t work as expected, try these steps:
Verify that you’re viewing the settings for the correct environment.
Edit the redirect and verify that you entered the correct values in the Redirect From and Redirect To fields.
Technical Limitations with Redirects
Redirects have these technical limitations:
Each environment supports up to 10,000 redirects. To request a higher limit, contact Salesforce Customer Support.
Each environment has its own redirects. Clone redirects to keep them in sync across environments.
The redirects feature supports simple redirects from one path to another. For complex redirects with conditionals, use Express.js’s redirect support in ssr.js.
Local development environments don’t run redirects that you create in the UI or the API.
Page transitions in the Storefront Next app don’t trigger redirects. Only an HTTP request triggers a redirect.
To load a redirect in the context of a storefront, use the managed endpoint /mobify/redirect/$path.
j