Lightning Out 2.0 App Manager
The Lightning Out 2.0 App Manager is the Setup interface where an admin or developer creates and configures a Lightning Out 2.0 app, the Salesforce app that lets you embed custom Lightning web comp…
Definition
The Lightning Out 2.0 App Manager is the Setup interface where an admin or developer creates and configures a Lightning Out 2.0 app, the Salesforce app that lets you embed custom Lightning web components into an external, non-Salesforce website. You build the app in Setup, add the custom LWCs you want to expose, optionally define properties the host page can pass in, and then copy a generated code block straight into the external app's HTML.
Lightning Out 2.0 went generally available in the Winter '26 release. It is built on Lightning Web Runtime and completely replaces the older Aura-based Lightning Out (beta), rather than extending it. Each embedded component runs inside an iframe that forms a closed shadow DOM, so the host page cannot reach into Salesforce internals. The framework works with React, Angular, Vue, and plain JavaScript host apps.
How the App Manager turns LWCs into an external embed
What you actually configure in Setup
You start in Setup, in the App Manager list. The New Lightning Out 2.0 App button creates the record, and the Edit page is where the real work happens. Open the App Components tab and add each custom Lightning web component by name in the Component Name field. The namespace separates from the component name with a forward slash or a hyphen, so complexNs/lwcComponent and complex_ns-lwc-component are equivalent and both valid. A component in the default namespace uses the c prefix. After you add components, you can define custom property values the external page is allowed to pass to those components. The App Manager then produces a Lightning Out 2.0 code block: a script element plus the markup that loads your app and renders the components you exposed. You paste that block into the host page. This is the whole point of the App Manager. It is the single Setup surface that decides which components leave Salesforce, what data the host may hand them, and what embed code the external team copies. Nothing renders externally unless the component was added to an app here first.
The iframe and closed shadow DOM model
Lightning Out 2.0 does not run your component directly on the host page. The JavaScript library creates custom web components on that page, and the base element, lightning-out-application, has no visible UI of its own. Each Lightning Out 2.0 web component contains an iframe that becomes the root of a closed shadow DOM. The real LWC runs inside that iframe in the Salesforce context, not in the context of the host page. Because the iframe sits in a closed shadow DOM, JavaScript on the host page cannot directly see or manipulate what is inside it. This is a deliberate security boundary and a sharp departure from the original beta, which executed components inline and exposed Salesforce internals to whatever else was on the page. The tradeoff is that you give up direct DOM access from the host. You cannot reach in and query the embedded component's elements. You communicate by setting attributes the component already supports, and Salesforce handles the rest behind the closed boundary. For most embeds this isolation is a feature, not a constraint, because it keeps host page scripts and Salesforce logic from colliding.
Passing data in and getting events back out
Since the host cannot touch the iframe directly, communication is structured. You set values for any attribute the embedded LWC supports, declared in HTML, set in JavaScript, or passed as JSON properties. CSS custom properties can travel in through a style attribute to restyle the component without breaking the boundary. Under the covers, messages cross the iframe edge using window.postMessage wrapped around standard CustomEvent semantics, which Salesforce describes as a secure and predictable channel. On the way back, Lightning Out 2.0 fires lifecycle events you can listen for. The lo.application.ready event signals that the Salesforce session was established successfully. The lo.component.ready event fires when a component has rendered. When something fails, lo.application.error and lo.component.error give you a hook for debugging instead of a silent blank space. Wiring these events is the practical difference between an embed that feels reliable and one that mysteriously shows nothing. Treat lo.application.ready as your green light before assuming the embedded experience is live, and surface the error events somewhere visible during development so a failed session or a typo in a component name is obvious immediately.
Authentication through the frontdoor URL
An embedded component still runs as a real Salesforce user and needs a real session. Lightning Out 2.0 configures the lightning-out-application element with a secure frontdoor URL that establishes that session inside the iframe. Today the app serves authenticated Salesforce users only. Sharing with unauthenticated visitors is not yet available, so this is not the tool for a fully public marketing page where the viewer has no Salesforce login. Two browser settings matter and are easy to miss. Third-party cookies must be enabled in the user's browser, and cross-domain Salesforce session cookies must be enabled for the org. If either is off, the session handshake fails and the component never loads. The OAuth 2.0 client credentials flow is explicitly unsupported here because it does not carry user context, and Lightning Out 2.0 is built around the identity of an actual person. Plan the login experience before you plan the components. Deciding late how the external page authenticates the user against Salesforce is the most common reason a Lightning Out 2.0 proof of concept stalls.
What it supports and what it does not
Lightning Out 2.0 embeds custom Lightning web components only. To use a standard base component such as one from the lightning namespace, you wrap it in a custom LWC and expose that wrapper, because a standard component used directly may not be fully styled or behave as documented. Aura components are not supported at all, custom or standard, which is the cleanest signal that this is an LWC-era replacement and not a continuation of the Aura beta. A few technical limits shape designs. The lightning/navigation service is not supported, so an embedded component cannot drive page navigation the way it would inside Lightning Experience. The Lightning Out 2.0 JavaScript library cannot be loaded from within another Lightning web component because Lightning Web Security blocks it, so you load the library directly from the host page instead. There are additional component-level styling and property limits documented separately. None of these are bugs. They follow from running real Salesforce components inside an isolated iframe on a page Salesforce does not control, and knowing them up front keeps you from designing an embed that the platform will not allow.
Lightning Out 2.0 versus the original beta
The naming hides a full rewrite. The original Lightning Out (beta) was an Aura application type that ran components on an external origin server, often a Node.js app on Heroku, using a JavaScript library and a $Lightning.use style entry point. It executed components more or less inline on the host page. Lightning Out 2.0 is a generally available feature that completely replaces, and is not an extension of, that beta. It is built on Lightning Web Runtime, isolates components in iframes within closed shadow DOM, and ships an App Manager that generates the embed code for you. Salesforce describes 2.0 as lighter, faster, and more secure, and frames it as working across React, Angular, Vue, and plain JavaScript rather than assuming a specific server stack. The old beta remains under Beta Service Terms, but Salesforce recommends 2.0 for new work. If you have an existing Lightning Out (beta) integration, treat it as legacy. The component model, the embedding code, and the security architecture all changed, so a migration is a rebuild on the new App Manager, not a config tweak.
Where Lightning Out 2.0 fits next to Experience Cloud
Lightning Out 2.0 and Experience Cloud both let Lightning web components run outside the standard Salesforce UI, and they solve different problems. Experience Cloud is a full site platform with its own authentication, navigation, pages, and theming. You reach for it when the external surface is itself a destination: a portal, a help center, a partner site. Lightning Out 2.0 is a focused embed tool. You reach for it when you already have an external app, built in any framework, and you want to drop one or more Salesforce-aware components into it without rebuilding that app inside Salesforce. The remaining authenticated-users-only limit also matters to the choice. If you need to serve anonymous visitors today, Experience Cloud with guest access handles that, while Lightning Out 2.0 does not yet. A simple test: if the answer to where does this live is on my own website or app, Lightning Out 2.0 is likely the fit. If the answer is on a Salesforce-hosted site, that is Experience Cloud territory.
Build a Lightning Out 2.0 app in the App Manager
Lightning Out 2.0 is configured entirely from Setup before any external developer touches the host page. You create the app, add the custom LWCs you want to expose, optionally declare the properties the host may pass, then copy the generated code block into the external app.
- Open the App Manager and create the app
In Setup, go to the App Manager and click New Lightning Out 2.0 App. Give it a name. This record is the boundary that decides which components are allowed to leave Salesforce.
- Add your custom components
On the Edit page, open the App Components tab. In the Component Name field, enter each custom LWC, separating namespace from name with a forward slash or hyphen (for example c/myComponent), then click Add Component.
- Declare any properties the host can pass
Define the custom property values your external page is allowed to hand the components. Only the attributes the LWC already supports can be set, in HTML, JavaScript, or JSON, so plan the public surface of each component.
- Copy the generated code block
Take the Lightning Out 2.0 code block the App Manager produces. It includes the script element and the markup that loads the app and renders your components. Paste it directly into the external app's HTML.
- Wire the lifecycle events and test
On the host page, listen for lo.application.ready and lo.component.ready to confirm the session and render, and surface lo.application.error and lo.component.error during development so failures are visible.
The custom LWC to expose, with namespace and name separated by a forward slash or hyphen. Standard components must be wrapped in a custom component first.
Attribute values the external host is permitted to pass to the embedded components. Restrict these to attributes the LWC genuinely supports.
The script element and markup output by the App Manager. Load this from the host page directly, never from inside another LWC, because Lightning Web Security blocks that.
- Only custom LWCs are supported. Wrap any standard lightning-namespace component in your own LWC before adding it, or it may not style or behave as documented.
- The app serves authenticated Salesforce users only. Unauthenticated, fully public access is not yet available, so this is not a drop-in for an anonymous marketing page.
- Third-party cookies in the browser and cross-domain session cookies for the org must both be enabled, or the frontdoor session handshake fails and nothing renders.
- The lightning/navigation service is not supported, so embedded components cannot drive page navigation the way they would inside Lightning Experience.
Prefer this walkthrough as its own page? How to Lightning Out 2.0 App Manager in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Lightning Out 2.0 App Manager.
Hands-on resources to go deeper on Lightning Out 2.0 App Manager.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What does the Lightning Out 2.0 App Manager configure in a Salesforce org?
Q2. How does a component running through Lightning Out on an external host typically authenticate to access Salesforce data?
Q3. How does Lightning Out compare with Experience Cloud for running Lightning components outside the standard Salesforce UI?
Discussion
Loading discussion…