Memory leak Module Federation (SSR)

[MaykonMorais]

We reproduced this issue on both Next.js 14 (Pages Router, SSR) and a custom React SSR shell using Rspack (no Next.js), confirming the leak originates from the Module Federation runtime itself and is not framework-specific.

In our SSR applications acting as a shell/host, we dynamically load multiple remote micro-frontends using the Module Federation runtime API. Remote definitions are fetched from a registry and refreshed periodically by calling registerRemotes(remotes, { force: true }).

Over time, the Node.js heap memory grows continuously and never stabilizes, eventually causing the container to be OOM-killed. The leak rate is directly proportional to the refresh interval — shorter intervals reproduce the issue faster.

How we use the runtime

Our shell fetches a list of remote MFE definitions from a registry service and registers them at runtime. This happens on every incoming request (with a time-based cache) so that new MFE deployments are picked up without restarting the shell process.

Remote registration (simplified from our codebase)

import {
  loadRemote,
  registerRemotes,
} from "@module-federation/enhanced/runtime";
import { lazy } from "react";

const configMap: Record<string, () => Promise<{ default: any }>> = {};
const componentMap: Record<string, React.LazyExoticComponent<any>> = {};

let definitions = [];
let lastUpdate = 0;

// Called on every request, with time-based throttling
async function prepareRemotes(force = false) {
  if (!force && Date.now() - lastUpdate <= REFRESH_INTERVAL_MS) return;

  const { data } = await fetchRemoteDefinitions();
  refreshDefinitions(data);
  lastUpdate = Date.now();
}

function refreshDefinitions(defs) {
  definitions = defs;

  const isServer = typeof window === "undefined";
  const remotes = defs.map((def) => ({
    name: def.moduleFederationName,
    entry: getRemoteUrl(def, isServer ? "ssr" : "chunks"),
    entryGlobalName: def.moduleFederationName,
    shareScope: "default",
    type: "global",
  }));

  // Register components for lazy loading
  for (const def of defs) {
    for (const component of def.components) {
      registerComponent(component);
    }
  }

  registerRemotes(remotes, { force: true });
}

function registerComponent(component) {
  const configLoader = () => loadRemote(component.importPath);

  configMap[component.contentType] = configLoader;
  componentMap[component.contentType] = lazy(async () => {
    const config = await configLoader();
    return { default: config?.default?.component };
  });
}

Plugin registration

import {
  type ModuleFederationRuntimePlugin,
  registerPlugins,
} from "@module-federation/enhanced/runtime";

const plugin: ModuleFederationRuntimePlugin = {
  name: "shell-error-handler",
  errorLoadRemote: async (args) => {
    throw new Error(
      `Failed to load MFE ${args.id}: ${args.error?.toString()}`,
      {
        cause: args.error,
      }
    );
  },
};

registerPlugins([plugin]);

Heap growth evidence

With a refresh interval of 30 seconds under moderate load (~50 req/s):

• Memory grows approximately 5-10 MB per minute
• After ~10 minutes, heap reaches container memory limits (~512 MB)
• Container is OOM-killed and restarts
• The cycle repeats indefinitely

With a refresh interval of 5 minutes, the leak is slower but still present — memory never reaches a stable plateau.

Environment

• Runtime: @module-federation/enhanced 0.2.5 (initially reproduced), also tested on 2.2.2
• Framework: Reproduced on Next.js 14 (Pages Router, SSR) and also on a custom React SSR shell using Rspack (no Next.js)
• Node.js: 20+
• Deployment: Containerized (Kubernetes), long-running Node.js process

Is there something we might be doing wrong on our side, or is this an intrinsic limitation of the runtime when used in long-running Node.js processes? Any suggestions for a workaround or fix would be greatly appreciated.

[leondavidtb]

I am experiencing the same issue. I look forward to an update on this.

[MaykonMorais]

I’ve been running some tests with disabling the force flag (force=false) and I’m getting very good results regarding memory usage. This may indicate that the issue is indeed related to passing force=true in registerRemotes. In my tests, even with a 30-second revalidation interval, memory consumption remained well under control.

@ScriptedAlchemy @2heal1, could you please help us better understand this issue?

[2heal1]

registerRemotes with option { force: true } may not clear the cache , let me try to fix it .

[MaykonMorais]

Hi @2heal1, thanks for your help! Is there any update regarding the issue solution?