Managed Runtime Overview for Business Manager

Managed Runtime provides the cloud infrastructure to deploy, host, and monitor Storefront Next. Managed Runtime organizes storefronts into projects and environments for testing code in isolation before promoting to production. Managed Runtime also includes a scalable serverless app server, a web application firewall, and admin tools for managing bundles, deployments, redirects, and user permissions.

Managed Runtime only supports applications created from a Storefront Next template and the Retail React App template for Composable Storefronts. The source code for the Storefront Next template is in the storefront-next-template GitHub repository.

The app server on Managed Runtime is a scalable serverless Node.js runtime environment for your storefront. Each published bundle, which contains a Storefront Next app, runs within a Managed Runtime environment on the app server. The Storefront Next app is a React app that’s built on React Router 7 in framework mode.

Because the Storefront Next rendering and routing system handles the differences between local development and Managed Runtime environments, your code runs predictably when you deploy it. This predictability helps your development team deploy bundles more frequently.

The app server supports Transport Layer Security (TLS) version 1.2 and later.

The eCDN that serves the storefront includes a web application firewall (WAF). WAF protects the storefront environments against malicious traffic, bot attacks, and vulnerabilities such as SQL injection and cross-site scripting (XSS). WAF filters, monitors, and blocks HTTP or HTTPS traffic to and from a web application.

When you create Storefront Next in Business Manager, or when you link an existing Storefront Next or Composable Storefront, the storefront in Business Manager represents the collection of resources that are required to develop, deploy, and run the storefront on B2C Commerce. These resources include the auto-generated Shopper Login and API Access Service (SLAS) credentials that are used for the B2C Commerce API (SCAPI), the Account Manager credentials that are used for B2C clients, such as the B2C CLI. Other resources include the storefront primary and any additional environments, storefront settings, and deployments. In Runtime Admin, a project groups multiple environments within an organization. The storefront maps to a corresponding project in Managed Runtime for deploying and hosting the storefront code on Salesforce public cloud infrastructure. The storefront setup in Business Manager automatically creates a project for the storefront.

An environment describes all the cloud infrastructure and configuration values for a storefront hosted by Managed Runtime. Environments separate your production storefront from storefronts deployed for other purposes, such as development or testing. The Storefront Next setup flow in Business Manager creates an environment for the new storefront. Admins can also create more environments for the storefront in Business Manager. Environments created in Business Manager are behind an embedded content delivery network (eCDN).

In the Managed Runtime API, environments are called targets.

Because environments run on highly efficient microservices that automatically scale up and down, create as many environments as you need at no additional cost. For example, create a short-lived environment dedicated to a single agile sprint or user story. When you no longer need an environment, delete it.

Environments marked as production are prioritized for monitoring by the Salesforce Support team and receive additional internal monitoring. Production environments get higher concurrency and capacity limits than non-production environments used for development and testing. The higher limits ensure that the production environment can handle the volume of live storefront traffic. To mark an environment as production, choose one of these methods:

  • Use the Runtime Admin tool. For instructions on creating or editing an environment, see Environments in Managed Runtime Administration.
  • Use the Managed Runtime API. The projects_target_create and projects_target_partial_update endpoints both include the is_production parameter. To mark an environment as production with these endpoints, set is_production to true.
  • If your B2C org is enrolled in the Developer Workspace Beta, mark the environment as production by clicking Production Status in environment settings. When you turn on Mark as Production, dependent settings are automatically enabled: Production Tier Capacity, Uptime Monitoring & Alerts and Real User Monitoring (RUM) Dashboard Display.

Before going live, contact Salesforce Support to get a production environment allocation. By default, organizations aren’t allocated any production environments.

Marking an environment as production turns on two more features. The production setting controls these features and you can’t manage them independently.

  • Production-Tier Capacity: Higher concurrency limits and traffic capacity for production-scale shopper load.
  • Uptime Monitoring and Alerts: Continuous monitoring across all serving regions, with alerts when issues are detected.

Starting September 29, 2026, you can mark an environment as production only if it’s associated with a staging or production B2C Commerce instance. Associate your production environments with a staging or production instance now to avoid disruption. See Edit Environment Settings.

Marking an environment as production doesn’t affect access to Log Center logs and metrics. Log Center logs and metrics can be enabled for any environment associated with a B2C Commerce instance, regardless of the production flag. See View Logs in Log Center.

Code running on the app server has access to these environment variables:

  • DEPLOY_TARGET: ID of the environment.
  • EXTERNAL_DOMAIN_NAME: The domain name set on the environment.
  • MOBIFY_PROPERTY_ID: ID of the project that the environment belongs to.

For more information, see Environment Variables.

The storefront code that runs on an environment is called a bundle. When you create a storefront in Business Manager, the storefront is bundled and deployed to a default MRT environment. Alternatively, use the CLI to deploy a bundle. A bundle is a snapshot of your code at a specific point in time. It’s immutable: After a bundle is created, it can’t be changed. A complete and accurate history of bundles makes troubleshooting deployments easier.

To deploy a bundle with the sfnext CLI, see Deploy Storefront Next to Managed Runtime (MRT) with Business Manager Resources. To deploy a bundle with the B2C CLI, see Deploy in the Agentic B2C Developer Toolkit documentation.

After pushing the bundle, use the Runtime Admin or Managed Runtime API to designate the bundle as “deployed.” Each project can have multiple bundles, but each environment can have only one bundle that’s designated as deployed. Change which bundle is designated as deployed at any time.

To manage the settings for your organizations, projects, environments, and bundles, use the Runtime Admin tool for routine tasks, such as deploying a code bundle to an environment. Use the B2C CLI or the Managed Runtime API for programmatic control, such as automatically creating an environment as part of a continuous integration script.

  • The Managed Runtime Admin, a web-based UI.
  • The B2C CLI, which offers commands for scripted automation. See MRT Commands in the Agentic B2C Developer Toolkit.
  • The Managed Runtime API, mrt-admin and mrt-b2c-config, is a collection of REST APIs that offer the same functionality as the web-based tool and some additional capabilities.

Use the admin tools to configure many settings, including:

Access to the admin tools is controlled with Account Manager roles and an API key. For continuous integration (CI) and continuous delivery (CD) processes, dedicated bot users with their own API keys are typically provisioned by your organization.

While building your storefront, keep these constraints in mind.

  • The execution time for App Server requests is limited to 20 seconds for production environments and 16 seconds for non-production environments. After this time, an HTTP 502 is returned.
  • Unhandled promise rejections break app rendering.
  • The maximum size for bundles is 400 MB and the maximum size of all ssr_only and ssr_shared files within the bundle is 249 MB.
  • Static assets that can be uploaded and served are limited to these content types: application/javascript, application/json, image/png, image/gif, image/jpeg, image/svg+xml, image/webp, text/css, text/plain and fonts (ttf, woff, woff2, otf, etc). All other content types need to be served by an external system.

See Environment Constraints.

Cookies, including the HTTP request Cookie and the HTTP response Set-Cookie header, are enabled by default.

To be informed of the availability of Managed Runtime services, subscribe to service updates on Salesforce Status.

During some maintenance windows, Managed Runtime enters a read-only mode: write requests to the Managed Runtime API are rejected while read requests continue to work normally. See Read-Only Mode During Maintenance.