---
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-05-07T11:10:27.535Z"
content_type: "lesson"
course: "microfrontends-on-vercel"
course_title: "Microfrontends on Vercel"
prerequisites: []
---
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.
# 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 |
| Section-level migration from legacy | Modernize page sections incrementally without rewriting the whole route |
## How Remote Components Work
Remote Components build on your Microfrontends setup. The `remote-components` package adds the runtime helpers; `@vercel/microfrontends` handles the routing through `microfrontends.json`. Install both in the host and in the app exposing the component:
```bash
pnpm add @vercel/microfrontends remote-components
```
The exposing app wraps the page in `ExposeRemoteComponent`:
```tsx title="components-app/app/components/header/page.tsx"
import { ExposeRemoteComponent } from "remote-components/remote/nextjs/app";
export default function Page() {
return (
Hello from the header!
);
}
```
The host app consumes it with `ConsumeRemoteComponent`. By default this is a Server Component, so the remote content is SSR'd:
```tsx title="host-app/app/page.tsx"
import { ConsumeRemoteComponent } from "remote-components/host/nextjs/app";
export default function Page() {
return (
Page content
);
}
```
The path `/components/header` resolves through the Microfrontends proxy to whichever app exposes that route. The remote component:
1. **Fetches** from the exposing application (components-app)
2. **Renders** the component as if it were local
3. **No iframes** - It's embedded directly in the DOM
4. **SSR by default** - Server-renders like native Server Components
## Configuration
Both the host and the exposing app wrap their `next.config` with `withRemoteComponentsConfig` and `withMicrofrontends`:
```ts title="next.config.ts"
import { withRemoteComponentsConfig } from "remote-components/config/nextjs";
import { withMicrofrontends } from "@vercel/microfrontends/next/config";
export default withRemoteComponentsConfig(
withMicrofrontends({
// your Next.js config
}),
);
```
Routing is declared in `microfrontends.json` the same way you've done throughout the course. The exposing app gets a path like `/components/:path*`, and the host resolves remote `src` values against it.
## State Sharing
The most common question: "How do I share state between host and remote?"
To pass shared modules like `next/image`, `next/link`, `next/navigation`, or client-side configuration to remote components, add `RemoteComponentsClientProvider` to the host's layout:
```tsx title="app/providers.tsx"
"use client";
import { RemoteComponentsClientProvider } from "remote-components/host/nextjs/app/client-only";
export function Providers({ children }: { children: React.ReactNode }) {
return (
{children}
);
}
```
The provider lives in a Client Component, but `ConsumeRemoteComponent` continues to render on the server. With this in place, both host and remote can share React context across the boundary, so a theme toggle in the host updates the remote header.
## 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
```
On Vercel with the App Router, invalidation is automatic. Remote Components tag their fetch calls, and Vercel triggers revalidation on the host whenever a remote redeploys, no manual configuration required.
## Done-When
- [ ] You understand vertical vs horizontal microfrontends
- [ ] You know when to consider remote components
- [ ] You can identify the `remote-components` package and its host/remote entry points
- [ ] You understand how state is shared via `RemoteComponentsClientProvider`
## 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
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)