What is a 'dynamic remote' in Module Federation, and how does resolving a remote's URL at runtime differ from declaring it statically in ModuleFederationPlugin's remotes config?

## Static versus dynamic resolution A 'dynamic remote' is a remote whose location — the URL of its container/remoteEntry.js — is not baked into the host's Webpack config at build time, but is instead resolved at runtime, typically from an API call, an environment variable read at startup, or a manifest file fetched over the network. This sits in contrast to a 'static remote,' where the host's `ModuleFederationPlugin` config has a literal `remotes` entry such as { catalog: 'catalog@https://cdn.example.com/catalog/remoteEntry.js' } baked into the compiled bundle, meaning that URL is fixed the moment the host itself is built and cannot change without rebuilding and redeploying the host. ## How a dynamic remote is wired Mechanically, dynamic remotes are implemented by: - using a **Promise-based syntax** in the `remotes` config instead of a plain string, for example remotes: { catalog: () => new Promise(resolve => { fetch a config, then resolve the loaded container }) }. - or, more commonly, by manually performing the two steps the static path does automatically: injecting a script tag pointing at a remote-entry URL discovered at runtime, waiting for it to load and register itself on window under its federation name, then calling that container's `init(shareScope)` and `get(moduleName)` directly instead of going through a static `import('remoteName/module')` call resolved by the bundler. Newer tooling, including the Module Federation runtime package and manifest-driven loaders, wraps this pattern into a cleaner runtime API, letting a host register or swap remotes by URL at any point during the app's lifecycle, not only at startup. ## Why they exist The reason dynamic remotes exist is that a build-time-fixed remote URL reintroduces exactly the kind of coupling Module Federation is meant to remove: with static remotes, if a remote's deployment moves to a new environment, a new CDN path, or a new tenant-specific instance, every host that references it needs a rebuild and redeploy just to update a string, which defeats independent deployability for the host side of the relationship. Dynamic remotes decouple which remotes exist and where they live entirely from the host's build, letting that mapping live in something that can change without a host rebuild: a backend-served manifest, a feature-flag service, or per-environment configuration. ## What this unlocks This unlocks several patterns that static remotes cannot support well. - **Multi-tenant or white-label products** can serve a different remote implementation of the same federated slot per customer, resolved by looking up the tenant's ID in a manifest at runtime. - **Plugin-marketplace-style architectures** — a host application whose feature set is extended by third-party or internally-published 'apps' registered after the host has already shipped — become possible, because new remotes can be registered by adding an entry to a backend-served list rather than shipping a new host build. - **Progressive rollout and A/B testing** of a remote's version becomes a matter of changing what a manifest endpoint returns per user cohort, rather than coordinating a host redeploy. - **Environment promotion** across dev, staging, and production can point the same host build at different remote URLs per environment purely through runtime configuration. ## The cost The cost is added runtime complexity and a weaker build-time safety net: with static remotes, a build tool can at least statically see that a `remotes` entry exists, even though it still can't validate the remote's actual exposed API without extra tooling; with fully dynamic remotes resolved from a network call, there is nothing for the bundler or type checker to check against at all, and a broken or missing manifest entry only fails at runtime, in front of a real user, often as a generic 'container is not defined' or unhandled promise rejection rather than a clear error. Teams adopting dynamic remotes therefore usually pair them with - strong runtime error boundaries around each federated mount point, - a manifest schema validated at fetch time, - and staging environments that exercise the exact same manifest-resolution path production uses, since the failure mode that static remotes catch at build time, a typo'd URL, becomes a runtime incident for dynamic remotes if not otherwise guarded against. ## A concrete example A concrete example: an internal developer portal lets any team publish a 'widget,' a small federated remote, by registering its remoteEntry URL in a central catalog service; the portal's shell host fetches that catalog on load, and for each entry the user has access to, dynamically resolves and mounts the corresponding remote, so a new team's widget appears in the portal the moment they register it, with zero changes to the shell's own codebase or deploy pipeline.