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:

1. Each app deploys independently - Marketing, docs, and dashboard are separate Vercel projects
2. Vercel stitches them together - The proxy routes requests based on microfrontends.json
3. Fallback ensures availability - If an app wasn't built at a commit, Vercel uses a previous deployment

Fast Track

1. Create three Vercel projects (one per app)
2. Create a microfrontends group containing all three
3. 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 main

Part 2: Create Vercel Projects

You need three Vercel projects. One for each app.

Option A: Via Vercel Dashboard

1. Go to vercel.com/new
2. Import your acme-platform repository
3. Configure each project:

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-dashboard

Project names must match the application keys in microfrontends.json, and here they match the package.json names too. If you pick a different project name, rename the key to match it and add packageName with the package.json name.

Part 3: Create a Microfrontends Group

1. Go to your Vercel team's Settings → Microfrontends
2. Click Create Group
3. Name it acme-platform
4. Add all three projects:
   • acme-marketing (default)
   • acme-docs
   • acme-dashboard
5. Set acme-marketing as 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": "acme-marketing.vercel.app",
        "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
  }
}

Two things to check against the Vercel dashboard:

• Each key (acme-marketing, acme-docs, acme-dashboard) is the exact name of a project in the group.
• development.fallback is the marketing project's production domain. Vercel may have given you something other than acme-marketing.vercel.app if that name was taken, so copy the real one from the project's Domains settings.

Push the updated configuration:

git add -A
git commit -m "feat: configure microfrontends for Vercel deployment"
git push

Part 5: Deploy and Test

After pushing, Vercel will build all three projects. Once complete:

1. Go to your default project (acme-marketing)
2. Find the preview URL (e.g., acme-platform-abc123.vercel.app)
3. Test the routes:

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:

1. Same commit - Use deployment built at this commit
2. Same branch - Use latest deployment on this branch
3. Fallback environment - Use the group's configured fallback environment

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:

1. Edit apps/docs/app/docs/page.tsx - change the heading
2. Commit and push
3. Watch the deployments - only docs should rebuild
4. 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 push

Done-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:

Compare this to a monolith where every change triggers a full rebuild.

Production Promotion

When you're ready to go live:

1. Merge your branch to main
2. All apps build for production
3. Set up a custom domain on the default app (marketing)
4. 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.