Managing microfrontends

With a project's Microfrontends settings of the Vercel dashboard, you can:

• Add and remove microfrontends
• Delete a microfrontends group
• Share settings between microfrontends
• Route Observability data
• Manage security with Deployment Protection and Firewall

You can also use the Vercel Toolbar to manage microfrontends.

You can add a project to a microfrontends group using the CLI or the dashboard.

Using the CLI:

Run the following command from the project directory and follow the interactive prompts:

vercel microfrontends add-to-group

To pre-fill the group and default route, pass them as flags. A billing confirmation prompt will still be required:

vercel mf add-to-group --group="My Group" --default-route=/docs

Using the dashboard:

1. Visit the Settings tab for the project that you would like to add.
2. Click on the Microfrontends tab.
3. Find the microfrontends group that it is being added to and click Add to Group.

These changes will take effect on the next deployment.

You can remove a project from a microfrontends group using the CLI or the dashboard. Make sure no other microfrontend refers to this project before removing it.

Using the CLI:

Run the following command from the project directory and follow the interactive prompts:

vercel microfrontends remove-from-group

After removal, update microfrontends.json in the default application to remove the project's entry. The CLI will warn you if the project is still referenced in the configuration but will not block the removal.

Using the dashboard:

1. Remove the microfrontend from the microfrontends.json in the default application.
2. Visit the Settings tab for the project that you would like to remove.
3. Click on the Microfrontends tab.
4. Find the microfrontends group that the project is a part of. Click Remove from Group to remove it from the group.

These changes will take effect on the next deployment.

This action is not reversible.

Using the CLI:

Run the following command and follow the interactive prompts. The CLI will show how many projects will be removed but does not require the group to be empty first:

vercel microfrontends delete-group

To pre-select the group, pass it as a flag. A confirmation prompt will still be required:

vercel mf delete-group --group="My Group"

Using the dashboard:

Remove all projects from the group first, then the option to delete the group becomes available in the group's settings.

When microfrontend projects are not built for a commit in preview or custom environments, Vercel will route those requests to a specified fallback so that requests in the entire microfrontends group will continue to work. This allows developers to build and test a single microfrontend without having to build other microfrontends.

There are three options for the fallback environment setting:

• Same Environment - Requests to microfrontends not built for that commit will fall back to a deployment for the other microfrontend project in the same environment.
  • For example, in the Preview environment, requests to a microfrontend that was not built for that commit would fallback to the Preview environment of that other microfrontend. If in a custom environment, the request would instead fallback to the custom environment with the same name in the other microfrontend project.
  • When this setting is used, Vercel will generate Preview deployments on the production branch for each microfrontend project automatically.
• Production - Requests to microfrontends not built for this commit will fall back to the promoted Production deployment for that other microfrontend project.
• A specific custom environment - Requests to microfrontends not built for this commit will fall back to a deployment in a custom environment with the specified name.

This table illustrates the different fallback scenarios that could arise:

If the current environment is Production, requests will always be routed to the Production environment of the other project.

To configure this setting, visit the Settings tab for the microfrontends group and configure the Fallback Environment setting.

If your project has a project domain assigned to a Git branch, and the fallback environment is set to Same Environment, deployments on that branch will use the branch's project domain as the fallback environment instead of the production branch (e.g. main).

To use that branch across the microfrontends group, add a project domain for the branch to every project in the group.

To share settings between Vercel microfrontend projects, you can use the Vercel Terraform Provider to synchronize across projects.

• Microfrontend group resource
• Microfrontend group membership resource

Shared Environment Variables allow you to manage a single secret and share it across multiple projects seamlessly.

To use environment variables with the same name but different values for different project groups, you can create a shared environment variable with a unique identifier (e.g., FLAG_SECRET_X). Then, map it to the desired variable (e.g., FLAG_SECRET=$FLAG_SECRET_X) in your .env file or build command.

Navigations between different top level microfrontends will introduce a hard navigation for users. Vercel optimizes these navigations by automatically prefetching and prerendering these links to minimize any user-visible latency.

import {
  PrefetchCrossZoneLinks,
  PrefetchCrossZoneLinksProvider,
} from '@vercel/microfrontends/next/client';
 
export default function RootLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <html lang="en">
      <body>
        <PrefetchCrossZoneLinksProvider>
          {children}
        </PrefetchCrossZoneLinksProvider>
        <PrefetchCrossZoneLinks />
      </body>
    </html>
  );
}

Then in all microfrontends, use the Link component from @vercel/microfrontends/next/client anywhere you would use a normal link to automatically use the prefetching and prerendering optimizations.

import { Link } from '@vercel/microfrontends/next/client';
 
export function MyComponent() {
  return (
    <>
      <Link href="/docs">Docs</Link>
    </>
  );
}

By default, observability data from Speed Insights and Analytics is routed to the default application. You can view this data in the Speed Insights and Analytics tabs of the Vercel project for the microfrontends group's default application.

Microfrontends also provides an option to route a project's own observability data directly to that Vercel project's page.

1. Ensure your Speed Insights and Analytics package dependencies are up to date. For this feature to work:
   • @vercel/speed-insights (if using) must be at version 1.2.0 or newer
   • @vercel/analytics (if using) must be at version 1.5.0 or newer
2. Visit the Settings tab for the project that you would like to change data routing.
3. Click on the Microfrontends tab.
4. Search for the Observability Routing setting.
5. Enable the setting to route the project's data to the project. Disable the setting to route the project's data to the default application.
6. The setting will go into effect for the project's next production deployment.

If you are using Turborepo with --env-mode=strict, you need to either add ROUTE_OBSERVABILITY_TO_THIS_PROJECT and NEXT_PUBLIC_VERCEL_OBSERVABILITY_BASEPATH to the allowed env variables or set --env-mode to loose. See documentation for more information.