Managed Runtime Overview

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.

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.

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).

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.

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.

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 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 help you manage multiple environments, each environment also belongs to a project and each project belongs to an organization. When you create a storefront in Business Manager, storefront setup creates a default project and environment for the storefront. An organization can contain multiple projects for multiple storefronts and each project can contain multiple environments. A Managed Runtime user can belong to multiple organizations to separate different work streams.

Each organization can have a maximum of 100 total environments and a maximum of 10 production environments. To raise these limits, contact Salesforce Support.

Account Manager settings determine organizations and user organization membership. A user can belong to an organization as a member or an admin. Members can only interact with the projects in Managed Runtime for which they’ve been assigned a project role. Admins can interact with all the projects within an organization.

All users must be assigned the Managed Runtime User or Managed Runtime Admin role via Account Manager to access Managed Runtime.

Any user can have these capabilities for a Managed Runtime organization:

• Browse: View all projects for an Organization.

Any user can have these capabilities for a Managed Runtime project:

• Browse: View the project in Runtime Admin.
• Manage Redirects: Manage redirects for the project. See Redirects for details.
• Deploy: Deploy new bundles or revert the deployment to an older bundle.
• Manage Team: View, add, invite, remove, and edit the roles of team members for the project.
• Access Logs: Tail logs across all environments.
• View and Manage Environment Variables: See and manage environment variables in each environment. See Environment Variables.

Each user is assigned a project role that determines which abilities they have. (A user can only have one role.) Project roles can be assigned to any user within an organization.

This table lists the abilities for each project role:

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 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:

• Currently deployed bundle
• Redirects
• User permissions
• Production environment flag

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 of Managed Runtime environments in mind.

• 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.
  • /mobify/redirect/$path: Returns a similar response as projects_target_redirect_retrieve.
• Storefront Next preconfigures access control headers for the default domain. For vanity domains, configure them manually. Environment access control headers support up to 2 headers. Each header:
  • Can contain up to 128 characters.
  • Can be a combination of alphanumeric characters and - and _ characters.

• 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.

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.

• Managed Runtime Administration
• Managed Runtime API
• Managed Runtime API reference: mrt-admin and mrt-b2c-config
• B2C Developer Toolkit: MRT Commands