Heading 1
Heading 2
Heading 3
Heading 4
Heading 5
Heading 6
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur.
Block quote
Ordered list
- Item 1
- Item 2
- Item 3
Unordered list
- Item A
- Item B
- Item C
Bold text
Emphasis
Superscript
Subscript
The decision on the table is how much of your storefront operation you hand to Salesforce, and what your own team still has to cover once you do. Getting that split wrong is costly in two directions. Budget as if hosting were the whole job and nobody owns performance. Staff a full infrastructure team on top of Managed Runtime and you pay twice for the same work.
Managed Runtime hosts the front end, the platform hosts the commerce
A headless storefront on Salesforce has two parts. Commerce Cloud (Agentforce Commerce) runs the catalogue, prices, promotions, baskets and orders on the B2C Commerce platform. Managed Runtime runs the storefront application that customers load in their browser, and it connects that application to the commerce APIs.
Both are operated by Salesforce, which is the main difference with hosting a headless front end yourself. The wider architecture is covered in our overview of headless commerce on Composable Storefront.
What Salesforce takes over
Salesforce operates the servers, applies patches to the hosting layer and scales capacity when traffic peaks, such as during a sale or a campaign launch. Managed Runtime also caches pages and assets close to the shopper, which shortens load times on repeat requests. Your team works with environments, typically a production environment and one or more for testing, without configuring any of the underlying infrastructure.
When an issue sits on the Salesforce side, escalation matters more than any dashboard. FORWARD holds weekly calls with Salesforce product management in the US. Blocking bugs and missing functionality reach the people who can act on them, which a request through the normal account channel rarely does.
What stays with your team
Everything inside the storefront code stays yours. That covers how fast your pages render, how many third-party scripts load on each page and how well your caching rules fit your content. A slow product page on Managed Runtime is usually a code or content problem, and fixing it is your team's job.
Your team also owns release quality and business monitoring. Managed Runtime keeps the application running. It does not tell you that conversion dropped after Tuesday's release. Someone in your organisation has to watch those numbers and act on them.
Caching deserves a named owner as well. Pages that show the same content to every visitor can be cached for longer. Pages with prices per customer group or personal recommendations need rules that separate the shared parts from the personal ones. Rules that are too cautious slow the shop down, and rules that are too loose show shoppers outdated prices.
Releases and rollbacks change the risk of a launch
On Managed Runtime, each new version of the storefront is deployed as a bundle to an environment. If a release misbehaves in production, your team can roll back to the previous bundle. That makes frequent, smaller releases safer, because a bad change can be reversed quickly.
Rollback lowers the cost of a mistake without removing the need for testing. Changes on the commerce back end, such as a new promotion type or a data model change, follow their own cycle on the platform. The two have to stay compatible, so release planning still spans both sides.
