Do I Need to Run All Microfrontends Locally?

“For This Change, Please Start the Entire Product First”

“For a change in this remote, please start the host, all other remotes, and the complete product environment first.”

What follows often looks roughly like this:

Host
├── Remote A
├── Remote B
├── Remote C
├── Remote D
├── identity provider
├── shared test data
└── multiple backend services

Only once everything is running can the actual work on Remote C begin.

The obvious question is: Why does the entire product have to run on the developer’s machine for a change in Remote C?

A complete local composition can be useful for selected integration checks. It shows how the host loads a remote, how URLs behave, whether the available layout space fits, or whether shared sign-in works within the product composition. But it should not be the required default for every domain change.

If a remote needs the complete host and several unrelated remotes for its normal development cycle, its delivery may be more independent than its actual development.

The decisive question is therefore not which tool can start several applications at once. The more interesting question is:

Why should an autonomous microfrontend need the host or other remotes for its daily development?

Separate Deployments Are Not Yet Development Autonomy

A dedicated build and deployment are important prerequisites for independent releases. But they do not prove that the remote also works as an independent development unit.

The claimed independence often looks like this:

claimed independence
├── dedicated build
├── dedicated deployment
├── dedicated source-code area
└── dedicated remote entry

Actual development autonomy goes further:

actual development autonomy
├── dedicated mount point
├── own domain responsibility
├── own state
├── own internal routing
├── own authentication integration
├── own API integration
├── own tests
└── independent local startup

A remote can be released separately and still require user state from the host, permissions calculated by the host, domain data from a shell service, global store slices, or internal navigation services for every local change. It may even start meaningfully only when additional remotes and a fully prepared product environment are available.

The coupling has not disappeared. It has moved from the build into runtime and the development process.

This is not purely an organizational problem. The local development cycle reveals who actually owns the prerequisites. If the host must prepare state, create user objects, or retrieve domain data before a remote can work at all, the remote does not own its own operating conditions.

Separate deployments can therefore suggest autonomy that does not exist in daily development.

Why the Host Should Not Become a Runtime Prerequisite

The host is an integration partner. It knows the product composition and provides one possible mount point. That role matters, but it is limited.

Problems begin when the host does not merely integrate, but supplies the remote:

Host
├── loads user state
├── calculates permissions
├── retrieves domain objects
├── manages remote state
├── provides internal services
└── activates the remote
        ↓
Remote
└── works only within this context

Such a contract is technically possible. Large objects can be passed during mounting, central services injected, and shared state made available. But this is not a neutral technical decision.

Every handoff creates a contract. The host must know which information the remote needs. It must own or retrieve that information, define its format, and coordinate changes. The remote, in turn, works only as long as that contract is fulfilled completely.

The more domain responsibility and runtime context the host passes in, the less the remote resembles an autonomous application and the more it becomes an extracted UI fragment of the shell.

A strict boundary is therefore useful: the host may activate the remote and place it within the product. It should not provide domain or operational prerequisites without which the remote cannot function.

The Remote as an Independently Startable Application

The target model begins with the capability itself:

Capability
├── domain responsibility
├── UI
├── state
├── internal routing
├── authentication integration
├── API integration
├── error handling
└── bootstrap

The capability owns its domain state, its API boundary, its internal navigation paths, and its failure cases. It integrates required infrastructure such as authentication or configuration itself.

That does not mean it works without external systems. A capability may require APIs, an identity provider, feature configuration, or controlled test data. Development autonomy does not mean complete isolation. It means independence from the host as a domain or technical runtime provider.

An autonomous remote may depend on external systems. It should not depend on the host as a runtime service.

Host Mount Point and Remote Mount Point

The capability can be activated through two technical entry points:

Product runtime
Host mount point
└── mounts the remote

Local development
Remote mount point
└── mounts the same remote

Both entry points start the same application.

The capability itself should not need to know whether it was activated by the host or by its local remote mount point. The host mount point places it within the composed product. The remote mount point provides a small, independent application entry point for local development.

This local mount point is not a second shell. It does not rebuild the host. It runs the same bootstrap, initializes the router, sets a local base path, loads its own configuration, starts the authentication integration, and mounts the capability into a DOM target.

It does not recreate domain state from the host or a global product store, invent host user objects, or copy shell services. It merely activates the same capability in a smaller runtime environment.

The local mount point does not replace the host. It proves that the remote does not need the host in order to function.

A Mount Contract Activates—It Does Not Supply

A mount contract should remain deliberately small:

Mount contract
├── remote entry
├── container or route
├── base path
├── mount
└── unmount

Depending on the integration style, it may be even smaller. What matters is not the exact technical signature, but its responsibility.

A mount contract activates an application. It does not supply its domain responsibility.

In this target model, user state, permissions, domain entities, global product state, foreign store slices, shell services, domain configuration, a central event bus, or internal router objects do not belong in the mount contract.

Not every handoff is technically impossible or forbidden in every context. A deliberately strict architectural position does, however, make the consequences visible. As soon as the host passes domain state, it has to understand that state. As soon as it calculates permissions, it owns part of the authorization logic. As soon as it retrieves domain objects, it becomes coupled to the APIs and lifecycle of another capability.

The mount contract should therefore describe technical activation, not domain supply.

Shared Sign-In Without Auth State in the Host

Authentication is the most common argument for starting a remote only inside the host. Shared sign-in is then treated as equivalent to shared authentication state in the host.

It does not have to be.

not:
Host
└── passes user, token, and permissions
        ↓
      Remote

instead:
Identity provider and existing browser session
├── Host integrates itself
└── Remote integrates itself

The host and remote can use the same identity provider, the same sign-in, and the same browser session. That does not mean the host must own the authentication state of every remote.

The remote remains responsible for initializing its authentication integration, obtaining required tokens, securing API calls, and handling a missing or expired session. Permission decisions within the capability also remain where their domain meaning is known.

The same principle applies to local development:

Remote mount point
└── starts the remote
    └── Remote uses its own authentication integration

The authentication integration that works in the product runtime must also be initializable through the remote mount point without the host passing in user state or permissions.

Shared infrastructure is not a handoff by the host.

Domain Data Belongs to the Capability

The same applies to domain data.

problematic for autonomy:
Host loads customer data
→ passes it to the remote

more autonomous:
Remote loads the required projection
→ through its own API

The host should not need to understand another capability’s domain. The remote should retrieve the data its capability requires. Its API boundary belongs to its responsibility, or to the responsibility of the capability it represents.

Passing data through the host may be convenient in the short term. It may save one visible API call or reuse data that is already available. At the same time, it couples lifecycles, responsibilities, and local development environments.

For independent startup, the remote mount point would have to recreate that data handoff. This is exactly where the runtime coupling becomes visible: the remote is not simulating its own external dependency, but a host that normally prepares domain data for it.

Daily Development, Local Integration, and Product Validation

Not every check needs the same runtime environment. Three clearly separated modes prevent the complete product composition from becoming the reflexive default.

1. Daily Development

Remote mount point
└── Remote
    ├── own domain responsibility
    ├── own APIs
    ├── own authentication integration
    └── own test data

In the innermost development cycle, only the remote being changed and its genuinely required external dependencies are started.

This mode is suitable for domain changes, UI work, local state changes, error handling, API integration, and tests within the capability. It keeps feedback loops short and makes the responsibility of the remote visible.

2. Focused Local Integration Check

Host
└── remote under development

Here, the subject of the check is not the capability alone, but its concrete integration into the product.

Typical checks include correct loading and mounting, entry through the product URL, base paths and deep links, available layout space, technical navigation between product areas, shared sign-in behavior in the composition, or a remote loading failure.

A tooling mode that starts the host together with exactly the remote under development is useful for this. Other areas can be loaded from existing preview versions or disabled; they do not all have to run as local development servers.

Host plus development remote is a useful integration mode. It does not have to be the normal development mode.

3. Product Validation

Preview or test environment
├── Host
├── real remote versions
├── real infrastructure
└── selected product-wide flows

This mode validates the actual product composition. Real remote versions, shared infrastructure, and selected product-wide flows matter here.

The complete product landscape does not have to be reconstructed permanently on every developer’s machine. A preview or test environment is often more realistic and reproducible than a local collection of differently configured services.

These three modes do not form a quality ranking. They answer different questions.

When the Host Is Actually Needed Locally

The host is needed locally when integration with the host is the subject of the check.

That sounds obvious, but daily practice often reverses it: the host is always running, so every change is automatically developed inside the complete composition. The boundary between capability development and product integration then becomes blurred.

For a change to a validation rule, a result view, or internal state, the host usually adds no meaningful insight. For a new entry path, changed mounting behavior, or handling of a loading failure, it does.

The host is therefore not generally unnecessary for local development. It is a deliberately used integration partner.

External Dependencies Are Not Automatically Host Dependencies

An independently started remote does not have to work without infrastructure. Depending on the capability, it may need its APIs, an identity provider, feature configuration, or controlled test data. The corresponding services may themselves require databases, object storage, or other technical infrastructure.

For local development, those dependencies may be available for real or replaced deliberately. API mocks, simulated error responses, a local or shared identity provider, and temporary capability environments are legitimate tools.

The decisive distinction is:

legitimate:
Remote simulates its own external systems

problematic for the claimed autonomy:
Remote simulates the shell because the shell normally supplies it

The remote may simulate its external systems. It should not have to simulate the host.

This distinction prevents a misunderstanding: development autonomy does not mean that every remote must be a separately marketable product or reproduce all infrastructure locally. What matters is who owns the dependency in domain and operational terms.

What Local Startup Reveals About the Architecture

Local startability is a practical architecture test.

If a small change first requires the host, additional remotes, and several central services to be started, every one of those dependencies should be questioned:

start the host
→ start additional remotes
→ initialize global product state
→ prepare central test data
→ complete the full sign-in flow
→ navigate through the product to the capability

The causes rarely lie in the start command itself. Domain logic may live in the host. The shell may own domain state, calculate permissions, or provide internal services. The remote may read foreign store areas, lack its own API boundary, or depend on internal navigation objects from the host.

Another finding is also possible: several remotes actually form one capability together. In that case, not every remote is necessarily implemented incorrectly, but the claimed domain independence does not match runtime reality.

Not every dependency automatically proves a poor boundary. A remote can start alone and still be poorly divided in domain terms. Local startability is a strong indicator of autonomy, but not proof on its own.

Conversely, a remote that cannot be operated or validated meaningfully without the host is very likely not an autonomous application unit.

Anything that would have to be rebuilt from the host for local startup should therefore be made visible as potential runtime coupling and justified deliberately.

Development Autonomy as a Consequence of Clear Boundaries

Local development autonomy is not merely a convenience. It is an observable result of clear boundaries.

A dedicated remote mount point does more than shorten startup. It forces an honest answer to which responsibilities actually belong inside the capability. If the capability owns its domain state, API integration, and authentication integration, it can be activated through a small application entry point.

The host remains important: it integrates the remote into the product and is needed for focused integration checks. But it does not have to participate in every daily change within the capability. Shared sign-in, shared infrastructure, and technical standards remain possible without passing user state, permissions, or domain entities through the host.

The local mount point does not build a second shell. It activates the same capability in a smaller runtime environment. Its own external systems may be simulated; the host should not have to be simulated.

A microfrontend should therefore not only be buildable and deliverable separately. It should be startable, developable, and domain-testable as an independent application through its own mount point. Local startability does not prove a good domain boundary, but it makes runtime coupling immediately visible.

If a remote needs the host, unrelated remotes, and their state for normal local startup, the architecture should be examined to determine whether an autonomous capability exists—or merely a technically extracted part of the overall product.

The host may mount a remote. It should not keep it alive.