Lightning Out 2.0 Salesforce Winter ’26: The Developer’s Guide to Embedding LWCs Beyond Salesforce

When you’re building modern applications, you’re probably juggling multiple frameworks, platforms, and tools. Your main Salesforce org sits at the heart of your business, but your data and workflows need to live everywhere else too – in customer portals, partner sites, your custom applications built on React or Angular, or internal enterprise tools. And here’s the thing: you don’t want to rebuild everything from scratch just because it needs to work outside of Salesforce.

That’s where Lightning Out 2.0 comes in. It’s Salesforce’s fresh take on bringing your Lightning Web Components (LWCs) directly into any external application. If you’ve heard of Lightning Out (Beta), this is completely different – it’s a ground-up rewrite using modern web standards and the Lightning Web Runtime, and it’s now Generally Available in Winter ’26.

Let me walk you through what makes this such a big deal for developers, and then we’ll get into the practical stuff.

What’s Wrong with Lightning Out (Beta)? Why Do We Need 2.0?

Before we celebrate Lightning Out 2.0, it helps to understand what it’s replacing.

Lightning Out (Beta) was around for a while, and it did let you embed Aura components into external apps. But it had real limitations. It required you to tie everything to Aura architecture, components ran directly on the host page without isolation, and there were security concerns because malicious scripts from the host page could interfere with your Salesforce components. Plus, if you had CSS conflicts or JavaScript conflicts, you were stuck dealing with them.

The beta version also forced you to handle authentication manually using session IDs or OAuth access tokens – which meant more code you had to write and maintain. And you could only use Aura components, not the modern Lightning Web Components everyone’s moving toward.

Lightning Out 2.0 threw all of that out the window. It’s a brand new feature built on Lightning Web Runtime (LWR) – the same runtime that powers modern Salesforce Experience Cloud sites. It’s completely separate from Lightning Out (Beta), not an extension of it.

Lightning Out 2.0: Here’s What You’re Actually Getting

At the most basic level, Lightning Out 2.0 lets you take Lightning Web Components you’ve already built inside Salesforce and embed them into any external application. React, Angular, Vue, plain JavaScript – it doesn’t matter. Your component loads, connects securely to your Salesforce data, and works like it was native to the host app.

But there’s more depth to it than that.

It’s Powered by Lightning Web Runtime (LWR)

Lightning Web Runtime is Salesforce’s lightweight JavaScript runtime built for performance and flexibility. Unlike the older Aura framework, LWR uses standards-based web components. What that means practically is faster performance, smaller bundle sizes, and compatibility with modern JavaScript practices.

The architecture is designed to handle scale. If you’re embedding components into a customer portal that gets millions of visits, Lightning Out 2.0 is built to handle that traffic without choking.

Iframe Isolation: The Security Game-Changer

Here’s something that matters a lot but people sometimes gloss over: Lightning Out 2.0 runs each embedded component inside an iframe with a closed shadow DOM. This is intentional, and it’s actually great for security.

In Lightning Out (Beta), components ran directly on the host page. That meant a malicious script on the host page could reach into your Salesforce component, mess with its JavaScript, manipulate its CSS, or even try to intercept events. It was a real attack surface.

With iframe isolation in Lightning Out 2.0, your Salesforce components are locked away in their own sandbox. The host page’s CSS can’t bleed into your component. The host page’s JavaScript can’t touch your component’s code. And hostile scripts on the host page have no way to reach across that iframe boundary.

Salesforce uses a Content Security Policy (CSP) directive that explicitly says “only this external app is allowed to load the Lightning Out 2.0 script.” That’s strong. And on top of that, Lightning Web Security (LWS) is automatically applied to your embedded components, giving you modern security features by default.

Now, you might be wondering: “If my components are locked in an iframe, how do they actually talk to the host page?” That’s a great question, and Salesforce solved it with postMessage().

Communication Across the Iframe Boundary

Lightning Out 2.0 wraps custom events using window.postMessage() to let components and the host page talk to each other safely. Here’s the important part: from your perspective as a developer, you don’t need to think about postMessage directly. You still create and dispatch custom events exactly like you normally would in LWC using the CustomEvent constructor and dispatchEvent() method.

Behind the scenes, Lightning Out 2.0 is handling the cross-iframe communication. An event fired inside the embedded component bubbles up through the iframe boundary, gets wrapped in a postMessage call, travels across to the host page, unwraps, and your host page receives it as a normal JavaScript event. It works in both directions too – the host page can dispatch events down to the component the same way.

This is actually really clever because it means your component code stays clean and familiar. You’re not writing iframe-specific code.

Performance That Matters

LWR components are noticeably faster than their Aura counterparts. The runtime is optimized for modern browsers, the component rendering engine is efficient, and the lazy loading capabilities mean you only load what you need when you need it.

For external embedding, this matters because every millisecond counts when your portal or partner site is loading. Lightning Out 2.0 is designed with performance in mind from the ground up.

How Lightning Out 2.0 Actually Works: The Flow

Let me break down what actually happens when you embed a component.

Step 1: Setup in Salesforce

First, you configure your Lightning Out 2.0 app in Salesforce. You go to Setup, find the Apps section, and there’s now a new menu for Lightning Out 2.0 App Manager. You create an app, add the custom LWC components you want to embed, and configure any styling or properties those components should have.

When you save your Lightning Out 2.0 app, Salesforce generates a script tag – a specific JavaScript snippet that you’ll copy and paste into your external application.

Step 2: Authentication Setup

Here’s where the UI Bridge API comes in. The UI Bridge API is how your external app exchanges a valid Salesforce access token (or the current session ID if you’re in a Salesforce context) for what’s called a frontdoor URL.

The frontdoor URL is basically a secure bridge that tells Salesforce “this person is authenticated, I’ve verified their credentials, let them access their data.” It’s how Lightning Out 2.0 maintains a secure session without exposing sensitive information to the host app.

If the user isn’t already logged into Salesforce, the OAuth authorization flow gets triggered automatically. Your users don’t need to log in twice – the system figures it out.

Step 3: Loading the Script and Initializing

On your external host page, you include the Lightning Out 2.0 JavaScript library that was generated in the App Manager. Then you add the lightning-out-application component to your HTML. This component needs two attributes:

• frontdoor-url: The secure bridge URL you got from the UI Bridge API
• components: A comma-separated list of the component names you want to embed

The script bootstraps the connection to Salesforce using that frontdoor URL, establishes the session, and then initializes each component you specified.

Step 4: Components Render in Iframes

Once the session is established, Lightning Out 2.0 creates an iframe for each embedded component. Inside each iframe, the actual LWC component runs in the Salesforce context. From the host page’s perspective, it just sees the iframe. Inside the iframe, the component has full access to Salesforce data services, the Lightning UI components, and everything else it would have inside the Salesforce Platform.

The lightning-out-application element fires custom events to let you know what’s happening:

• lo.application.ready: Fires when the Salesforce session is successfully established
• lo.application.error: Fires if something goes wrong with authentication
• lo.component.ready: Fires when individual components finish initializing

You can listen for these events on the host page and respond accordingly – show a loading spinner until lo.component.ready, display an error message if lo.application.error fires, that kind of thing.

Setting Up Lightning Out 2.0: What You Actually Need to Do

If you want to actually embed components, here’s the practical checklist.

In Salesforce Setup

1. Make sure you’re on Winter ’26 or later (this feature needs the latest platform)
2. Navigate to Setup > Apps > Lightning Out 2.0 App Manager
3. Create a new Lightning Out 2.0 app
4. Add your custom LWC components to the app (standard components and base components aren’t supported yet – just custom LWCs)
5. Configure any default styles or properties using SLDS styling hooks or CSS custom properties
6. Save the app and copy the generated script

That’s the Salesforce side. The script Salesforce generates is your starting point for the external app.

In Your External App

1. Add the Lightning Out 2.0 script to your HTML page
2. Create a div or container where your component will mount
3. Add the lightning-out-application component with your frontdoor-url and component list
4. Set up the UI Bridge API call to get your frontdoor-url from a valid Salesforce session
5. Listen for the lifecycle events to know when things are ready

Here’s what a simplified example looks like:

<!DOCTYPE html>
<html>
<head>
  <title>External App with Embedded LWC</title>
</head>
<body>
  <div id="app-container"></div>

  <script src="https://your-salesforce-instance.lightning.force.com/lightning/lightning-out.js"></script>
  <script>
    // Get frontdoor URL from UI Bridge API
    // This assumes you have a valid Salesforce session
    async function initLightningOut() {
      const frontdoorUrl = await getFrontdoorUrl(); // Your auth logic here
      
      const lightningOutApp = document.createElement('lightning-out-application');
      lightningOutApp.setAttribute('frontdoor-url', frontdoorUrl);
      lightningOutApp.setAttribute('components', 'c-my-component,c-another-component');
      
      lightningOutApp.addEventListener('lo.application.ready', () => {
        console.log('Salesforce session established');
      });
      
      lightningOutApp.addEventListener('lo.application.error', (e) => {
        console.error('Authentication failed:', e.detail.message);
      });
      
      document.getElementById('app-container').appendChild(lightningOutApp);
    }

    initLightningOut();
  </script>
</body>
</html>

Styling: Making Components Match Your App

One thing people worry about is: “Will my Salesforce component look out of place in my external app?”

Lightning Out 2.0 handles this with CSS custom properties and SLDS styling hooks. You can override styles at runtime without touching your component code.

When you set up your Lightning Out 2.0 app, you can declare CSS custom properties in the App Manager. Your embedded component can reference these properties in its CSS, and the host app can set the values. So if your external app uses a different primary color, different typography, different spacing – your component adapts.

The way this works is through SLDS 2 (Salesforce Lightning Design System version 2), which is based on CSS custom properties. Your component declares something like:

--slds-c-button-color-background: var(--primary-color);

And the external app provides:

<c-my-component style="--primary-color: #FF6B35;"></c-my-component>

Your component inherits the color from the host app. Clean and simple.

Component Communication: Talking Between Iframe and Host

Let’s say you have an embedded component that displays a data table, and when a user clicks a row, you want the host app to update something on its side. Or vice versa – the host app wants to tell the component to refresh its data.

Custom events handle this. Inside your LWC component, you dispatch a custom event like normal:

this.dispatchEvent(new CustomEvent('rowselected', {
  detail: { recordId: this.selectedRecord.Id },
  bubbles: true,
  composed: true
}));

On the host page, you listen for it:

const lightningOutComponent = document.querySelector('c-my-component');
lightningOutComponent.addEventListener('rowselected', (e) => {
  console.log('Row selected:', e.detail.recordId);
  // Update your host app
});

The iframe boundary is transparent to you. Lightning Out 2.0 wraps the event in a postMessage call, sends it across, and your host page receives it.

Going the other direction, the host page can dispatch an event:

const event = new CustomEvent('loadnewdata', {
  detail: { filter: 'active' },
  bubbles: true,
  composed: true
});
lightningOutComponent.dispatchEvent(event);

Your component receives it and responds. It’s bidirectional communication with standard JavaScript events.

Let us give you some scenarios where Lightning Out 2.0 shines.

• Customer Portal with Embedded Components: A SaaS company built their main web portal in React. They want to show customers a case status component that pulls live data from their Salesforce Service Cloud. Instead of building a duplicate case status view in React, they embed their existing Lightning Web Component. 

The component updates in real time with new cases, the styling matches the portal’s design, and they don’t have to write a single line of duplicate code.

• Partner Portal with Account Information: A B2B company wants their partners to see their account details, available products, and pricing through a custom portal. They build this portal as an Angular app, but instead of hooking up all the data queries themselves, they embed their Lightning Web Components that already handle account queries, product filtering, and pricing logic. 

The partner portal is now a thin UI on top of their Salesforce data, and any changes to their pricing logic automatically flow through to all partners.

• Internal Tools Dashboard: An enterprise has built custom internal tools in Vue.js for their operations team. They want to show Salesforce data dashboards in these tools without maintaining separate dashboard views. 

They embed Lightning components that already exist in their Salesforce org. Now operators see their tools and their Salesforce data in one interface.

• External Application Integration: A company uses a third-party platform for inventory management. They want to add a “create Salesforce opportunity” button that’s smart – it pulls pricing from Salesforce, applies account discounts, and creates the opportunity with all the right data. 

Instead of building a standalone API integration with a UI, they embed a custom Lightning component. The component knows how to talk to Salesforce, and the inventory app just hosts it.

What’s NOT Supported Yet (And What’s Coming)

Lightning Out 2.0 is GA, but it’s also relatively new. There are some things that aren’t on the table yet.

No Aura Components: You can only embed custom Lightning Web Components right now. If you’ve got legacy Aura components you want to share, they won’t work with Lightning Out 2.0. Salesforce is working on this, but it requires deeper architectural work because Aura has tight integrations that LWC doesn’t have.

No Standard/Base Components (Yet): You can’t directly embed standard Lightning base components like lightning-button or lightning-card into external apps through Lightning Out 2.0 – at least not right now. You need to wrap them in your own custom component. Again, Salesforce is working on this for post-GA releases.

Unauthenticated Access Is on the Roadmap: Right now, Lightning Out 2.0 requires authenticated users. You can’t embed a public-facing component that anyone can see without logging in. But this is actively being developed.

OmniStudio Functionality: If your use case heavily depends on OmniStudio features (like complex integration procedures, datamappers, etc.), Salesforce recommends checking out Omni Out instead, which is specifically designed for OmniStudio components.

Third-Party Cookies Required: Browsers need to allow third-party cookies for Lightning Out 2.0 to work. Cross-domain Salesforce session cookies also need to be enabled in your org. This is a security consideration some organizations need to think through.

CORS Configuration: Setting Up the Bridge

For Lightning Out 2.0 to work, your external app’s domain needs to be in Salesforce’s Cross-Origin Resource Sharing (CORS) allowlist. This is a security feature that explicitly says “these external domains are allowed to load Lightning Out 2.0 components.”

In Setup, you go to CORS settings and add your domain. This is pretty straightforward but it’s something to remember – you can’t just embed Lightning components from random external domains. It’s intentional, explicit, and controlled by the org admin.

Lightning Out 2.0 vs. Lightning Out (Beta): The Feature Comparison

If you’re trying to decide whether to upgrade from Lightning Out (Beta), here’s what changed:

Lightning Out 2.0 is clearly the future. It’s cleaner, more modern, more secure, and performs better. If you’re starting a new project, use Lightning Out 2.0.

Security: How Your Data Stays Safe

Security is baked into Lightning Out 2.0’s architecture, not bolted on.

Iframe Isolation: Your components run in iframes, which are their own execution context. Code in the host page can’t reach your component’s code.

Shadow DOM: Each component’s DOM is in a closed shadow DOM. The host page can’t traverse into it or modify elements.

Content Security Policy: Salesforce uses CSP headers to explicitly allow only your external app to load the Lightning Out 2.0 app. No other domain can sneak in and try to embed your components.

Lightning Web Security: LWS is applied automatically to embedded LWCs. It provides API distortions that prevent unsafe operations and keep code in a secure sandbox.

Session Management: Your component gets access through a frontdoor URL, not a raw session ID or token. This frontdoor URL is a temporary, secure bridge that Salesforce validates on each request.

Event Communication: Events are wrapped in postMessage calls, which only work between explicitly related frames. An unrelated iframe can’t intercept or manipulate events between your component and the host.

It’s hard to break this model. That doesn’t mean it’s impossible – no security is perfect – but it’s built on solid foundations.

Performance Considerations: Making It Fast

Lightning Out 2.0 is optimized for performance, but there are still things to think about.

Bundle Size: LWR is lighter than Aura, so your components have a smaller footprint. But you’re still loading a JavaScript runtime and your components. On the first load, there’s some overhead. Subsequent loads are faster because browsers cache the runtime.

Network Latency: Every component in an iframe makes a connection to Salesforce. If you’re embedding five components on a page, that’s multiple connections. It usually isn’t a problem, but it’s worth being aware of.

Lazy Loading: You don’t have to load all components at once. Load them as needed, show a spinner while they’re loading, and the page feels responsive.

Caching: Use @wire with cacheability turned on for Apex methods. LWC handles client-side caching automatically, so repeated calls for the same data don’t go back to the server.

Data Transfer: Only query and transfer the data you actually need. Don’t pull massive datasets into components if you’re only displaying a summary.

For most use cases, Lightning Out 2.0 performs really well. But like any technology, thoughtful architecture matters.

Getting Started: Your First Lightning Out 2.0 App

Here’s a practical path forward if you want to try this:

1. Make Sure You’re on Winter ’26: Check your org’s release version. You need Winter ’26 or later.
2. Create a Simple LWC: Build a basic component that does something useful – displays data, has a button that dispatches an event, something concrete. Nothing fancy for your first one.
3. Configure in App Manager: Go to Setup > Apps > Lightning Out 2.0 App Manager and create a new app. Add your component to it.
4. Get the Script: Copy the generated script snippet.
5. Set Up CORS: Add your external app’s domain to the CORS allowlist in Salesforce Setup.
6. Test Locally: Create a simple HTML page locally that loads the script and embeds your component. Get the authentication flow working.
7. Expand: Once you have the basics down, add event communication, multiple components, styling customization, whatever your use case needs.

The learning curve isn’t steep if you already understand LWC. The main new pieces are the UI Bridge API for authentication and understanding how postMessage event wrapping works – but honestly, you can mostly ignore that implementation detail and just use events normally.

Wrapping Up: Why Lightning Out 2.0 Matters

At the end of the day, Lightning Out 2.0 is about breaking down the walls between Salesforce and the rest of your tech stack. For years, if you wanted to use Salesforce data somewhere else, you had to either:

1. Build a REST API and duplicate UI logic
2. Use Lightning Out (Beta) and deal with its limitations
3. Accept that your Salesforce and external systems would be separate

Lightning Out 2.0 changes that equation. You can reuse your Salesforce components. You can deploy once and use it everywhere. You get consistency – both for developers (one codebase) and for users (one look and feel).

It’s built on modern web standards. The security is solid. The performance is good. And it works with whatever framework your team is using – React, Angular, Vue, or plain JavaScript.

If you’re building anything that needs to span Salesforce and external applications, Lightning Out 2.0 is worth your time. Try it out, build something, see how it fits into your architecture. The future of extending Salesforce beyond the platform starts here.

Avoid common Lightning Out 2.0 mistakes. Request expert guidance. (https://2creative.ca/) from our Salesforce team on architecture and security.