Deployment Workflow
Deploy your microfrontends to Vercel and configure the group for proper routing.
Outcome
Deploy all three applications to Vercel as a microfrontends group with correct routing and fallback behavior.
The Deployment Model
Microfrontends on Vercel work differently from regular deployments:
- Each app deploys independently - Marketing, docs, and dashboard are separate Vercel projects
- Vercel stitches them together - The proxy routes requests based on
microfrontends.json - Fallback ensures availability - If an app wasn't built at a commit, Vercel uses a previous deployment
Fast Track
- Create three Vercel projects (one per app)
- Create a microfrontends group containing all three
- Deploy and verify routing in preview
Hands-on Exercise 2.5
Deploy Acme Platform as microfrontends.
Part 1: Push to GitHub
First, ensure your code is in a GitHub repository:
# From monorepo root
git remote add origin https://github.com/YOUR_USERNAME/acme-platform.git
git branch -M main
git push -u origin mainPart 2: Create Vercel Projects
You need three Vercel projects. One for each app.
Option A: Via Vercel Dashboard
- Go to vercel.com/new
- Import your
acme-platformrepository - Configure each project:
| Project Name | Root Directory | Build Command |
|---|---|---|
acme-marketing | apps/marketing | cd ../.. && pnpm turbo build --filter=marketing |
acme-docs | apps/docs | cd ../.. && pnpm turbo build --filter=docs |
acme-dashboard | apps/dashboard | cd ../.. && pnpm turbo build --filter=dashboard |
Option B: Via Vercel CLI
# Install Vercel CLI
pnpm add -g vercel
# Link and deploy each app
cd apps/marketing && vercel link --project=acme-marketing
cd ../docs && vercel link --project=acme-docs
cd ../dashboard && vercel link --project=acme-dashboardProject names in Vercel should match the application names in microfrontends.json. If they don't, add a packageName property to map them.
Part 3: Create a Microfrontends Group
- Go to your Vercel team's Settings → Microfrontends
- Click Create Group
- Name it
acme-platform - Add all three projects:
acme-marketing(default)acme-docsacme-dashboard
- Set
acme-marketingas the default application
Part 4: Verify microfrontends.json Configuration
Your apps/marketing/microfrontends.json should already be configured from earlier lessons. Verify it matches your Vercel project setup:
{
"$schema": "https://openapi.vercel.sh/microfrontends.json",
"applications": {
"@acme/marketing": {
"development": {
"fallback": "http://localhost:3000",
"local": 3000
}
},
"@acme/docs": {
"routing": [
{ "paths": ["/docs", "/docs/:path*"] }
],
"development": {
"local": 3001
}
},
"@acme/dashboard": {
"routing": [
{ "paths": ["/app", "/app/:path*", "/settings", "/settings/:path*"] }
],
"development": {
"local": 3002
}
}
},
"options": {
"localProxyPort": 3024
}
}Application names (@acme/marketing, etc.) must match each app's package.json name field.
Push the updated configuration:
git add -A
git commit -m "feat: configure microfrontends for Vercel deployment"
git pushPart 5: Deploy and Test
After pushing, Vercel will build all three projects. Once complete:
- Go to your default project (acme-marketing)
- Find the preview URL (e.g.,
acme-platform-abc123.vercel.app) - Test the routes:
| URL | Expected |
|---|---|
https://acme-platform-abc123.vercel.app/ | Marketing home |
https://acme-platform-abc123.vercel.app/pricing | Pricing page |
https://acme-platform-abc123.vercel.app/docs | Docs home |
https://acme-platform-abc123.vercel.app/app | Dashboard |
https://acme-platform-abc123.vercel.app/settings | Settings |
Fallback Behavior
What happens when you only modify one app?
Scenario: You push a docs change. Only the docs project rebuilds.
Preview deployment contains:
├── marketing → falls back to main branch or production
├── docs → built at this commit ✓
└── dashboard → falls back to main branch or production
Vercel's fallback logic:
- Same commit - Use deployment built at this commit
- Same branch - Use latest deployment on this branch
- Production - Use production deployment
This means preview URLs always work, even when only one app was modified.
Understanding the Deployment Output
After deployment, check the Vercel dashboard:
Microfrontends Panel:
- Shows which apps are in the group
- Displays which deployment is serving each path
- Indicates fallback usage
Deployment Details:
- Each project shows its build status
- The default app's domain routes to all apps
Try It
Make a change to just the docs app:
- Edit
apps/docs/app/page.tsx- change the heading - Commit and push
- Watch the deployments - only docs should rebuild
- Visit the preview URL - docs shows the change, marketing and dashboard use fallbacks
Commit
git add -A
git commit -m "docs: update docs homepage heading"
git pushDone-When
- All three projects deployed to Vercel
- Microfrontends group created with all projects
- Preview URL routes correctly to all apps
- You understand fallback behavior for partial builds
Independent Deployments
The DX win becomes clear now:
| Change | What Rebuilds | Deploy Time |
|---|---|---|
| Marketing only | marketing | ~1 min |
| Docs only | docs | ~1 min |
| Dashboard only | dashboard | ~1 min |
| All apps | all | ~3 min parallel |
| Shared package | affected apps | depends |
Compare this to a monolith where every change triggers a full rebuild.
Production Promotion
When you're ready to go live:
- Merge your branch to
main - All apps build for production
- Set up a custom domain on the default app (marketing)
- The domain routes to all microfrontends
The same microfrontends.json that works in preview works in production.
What's Next
Cross-app navigation still causes full page reloads. Section 3 covers navigation performance, testing, and observability.
Was this helpful?