---
title: "Remote Components Intro"
description: "Understand horizontal microfrontends (remote components) and when they make sense."
canonical_url: "https://vercel.com/academy/microfrontends-on-vercel/remote-components-intro"
md_url: "https://vercel.com/academy/microfrontends-on-vercel/remote-components-intro.md"
docset_id: "vercel-academy"
doc_version: "1.0"
last_updated: "2026-04-11T16:44:56.033Z"
content_type: "lesson"
course: "microfrontends-on-vercel"
course_title: "Microfrontends on Vercel"
prerequisites:  []
---

<agent-instructions>
Vercel Academy — structured learning, not reference docs.
Lessons are sequenced.
Adapt commands to the human's actual environment (OS, package manager, shell, editor) — detect from project context or ask, don't assume.
The lesson shows one path; if the human's project diverges, adapt concepts to their setup.
Preserve the learning goal over literal steps.
Quizzes are pedagogical — engage, don't spoil.
Quiz answers are included for your reference.
</agent-instructions>

# Remote Components Intro

# Introduction to Remote Components

Throughout this course, you've built vertical microfrontends: splitting by route where each page belongs to one application. Remote components are the horizontal approach: embedding components from different applications on the same page.

## Outcome

Understand the difference between vertical and horizontal microfrontends and know when to consider remote components.

## Vertical vs Horizontal Recap

**Vertical (what you've built):**

```
Page at /docs/api
└── Entirely served by docs app
    ├── Header (shared package)
    ├── Content
    └── Footer (shared package)
```

**Horizontal (remote components):**

```
Page at /
└── Served by marketing app
    ├── Header (REMOTE from header-app)
    ├── Hero (local component)
    ├── Features (local component)
    └── Footer (REMOTE from footer-app)
```

With horizontal microfrontends, components from different applications render on the same page at runtime.

## When to Consider Horizontal

Remote components solve specific problems:

| Scenario                          | Why Remote Components Help                 |
| --------------------------------- | ------------------------------------------ |
| Shared header across portfolio    | One header app, embedded everywhere        |
| Different teams own page sections | Team A owns header, Team B owns content    |
| Runtime updates without redeploy  | Update header without rebuilding all hosts |
| Embedded widgets                  | Checkout widget on multiple sites          |

## How Remote Components Work

At a high level:

```tsx
// Host application
import { RemoteComponent } from "@vercel/microfrontends/react";

export default function Page() {
  return (
    <div>
      <RemoteComponent
        src="header-app"
        fallback={<HeaderSkeleton />}
      />
      <main>Page content</main>
      <RemoteComponent src="footer-app" />
    </div>
  );
}
```

The remote component:

1. **Fetches** from the remote application (header-app)
2. **Renders** the component as if it were local
3. **No iframes** - It's embedded directly in the DOM
4. **SSR/SSG support** - Server-renders like native components

## State Sharing

The most common question: "How do I share state between host and remote?"

**Module sharing** allows React context to work across applications:

```typescript
// Configuration in next.config.ts
export default withMicroFrontends(nextConfig, {
  shared: {
    react: { singleton: true },
    "@acme/context": { singleton: true },
  },
});
```

When both host and remote use `@acme/context`, they share the same context instance. A theme toggle in the host updates the remote header's dark mode.

## Current Status

Remote components are in alpha. Schwab and The Weather Company are beta testing. Production-ready for early adopters working directly with Vercel.

## Vertical-First Philosophy

For most teams, the recommendation is:

1. **Start with vertical microfrontends** (this course)
2. **Use shared packages** for common components
3. **Consider horizontal only when** shared packages aren't enough

Horizontal adds complexity:

- Module sharing configuration
- Cache invalidation when remotes update
- More moving parts to debug

Vertical is simpler and solves most use cases.

## When Vertical Isn't Enough

Consider remote components when:

- **Same component, many hosts** - A header used by 10+ separate applications (not in a monorepo)
- **Independent deployment of components** - Marketing wants to update the header without docs redeploying
- **Different teams, same page** - Team A owns navigation, Team B owns search, Team C owns content

## Example: Multi-Site Header

Imagine you have:

- marketing.example.com
- docs.example.com
- app.example.com

All need the same header. With shared packages in a monorepo, you'd need to redeploy all three when the header changes.

With remote components:

1. header-app deploys
2. All hosts pick up the new header (via ISR revalidation)
3. No coordination needed

## SSG/ISR with Remotes

Remote components support static generation:

```
Build time:
Host fetches remote component → Renders → Saves static HTML

Runtime (ISR):
Remote updates → Host revalidates → New HTML includes updated remote
```

Currently, invalidation is manual. You trigger revalidation on the host when a remote updates.

## The Future

The Vercel team is working on:

- **Automatic invalidation** - Host auto-revalidates when remote deploys
- **Better debugging** - See remote component boundaries in DevTools
- **Simplified configuration** - Less boilerplate for module sharing

## Done-When

- [ ] You understand vertical vs horizontal microfrontends
- [ ] You know when to consider remote components
- [ ] You understand module sharing for state
- [ ] You know remote components are currently in alpha

## Decision Guide

| Situation                     | Recommendation                 |
| ----------------------------- | ------------------------------ |
| Monorepo with shared packages | Use shared packages (simpler)  |
| Multiple repos, same header   | Consider remote components     |
| Single team                   | Probably don't need horizontal |
| 3+ teams on same page         | Remote components may help     |
| You want runtime updates      | Remote components              |
| You want simplicity           | Vertical + shared packages     |

## What's Next

Wrap up with the decision framework and resources for going deeper.

In the final lesson, you'll review the key decisions and get resources for continuing your microfrontends journey.


---

[Full course index](/academy/llms.txt) · [Sitemap](/academy/sitemap.md)