federated-compute

Experimental: Module Federation–flavored Machinen.

The consumer imports functions like any federated module — but the "remote" is actually a machine. A custom Module Federation runtime plugin claims machine entries, attaches (or boots) through a driver, and returns a virtual container whose exports are typed async function bindings. Every call is translated into an RPC into the machine. Bindgen for machines: it feels like one app, but the work runs somewhere else — in any language.

Containment is the rule: every machine is its own repo/deployment. The host never references machine source — federation entries are the multiplexer and the transport.

For end users: it's just imports

import { strings, math } from './generated';  // barrel generated by `machinen-bindgen`

await strings.upper('hi');                  // runs on the JVM machine
await math.add(20, 22);                     // runs on the Node machine
for await (const n of math.countdown(3)) {} // streams across the boundary

That's the entire API. Machine addresses come from the app's machinen.config.json, overridable per environment with MACHINEN_REMOTE_<NAME> env vars (or an optional configureMachines() call at startup). The federation instance, drivers, version negotiation, timeouts, retries, and circuit breaking are invisible — exactly like MF consumers importing from a remote without thinking about script loading or share scopes.

What is this for?

Module Federation solved "many teams, one web app" by making deployed JS composable at runtime. Point the same machinery at processes instead of bundles and a lot of distributed-systems pain becomes a config change:

• Erase the SDK industry. One typed manifest replaces a client library per language.
• Respect data gravity. Restore the code next to the data instead of dragging the data to the code.
• Kill the cold start. Snapshot machines warm — scale from zero by restoring, not booting.
• Fork reality. Fork a machine mid-task: race approaches, rehearse migrations, spin previews.
• Ship the running process. Freeze on the laptop, resume on the desktop — or debug prod heaps locally.
• Wrap the unwrappable. A thin guest turns legacy services and vendor binaries into typed imports.
• Operate it like MF. Dynamic remotes, version pinning, circuit breakers, metrics — all per machine.

The full version of each story lives in the operators guide.

Layout

packages/runtime-plugin   @federated-compute/machinen-plugin (plugin, hooks, drivers, guest runtime, bindgen)
apps/remote               machine: Node guest (Rsbuild, node target)
apps/remote-java          machine: Java 21 service (src/dev/machinen/* — server, runtime, modules, state; builds dist/java-machine.jar plus dist/java_machine.machine, zero deps)
apps/remote-python        machine: Python 3 service (machinen_guest package — protocol, registry, server, modules; stdlib only)
apps/machine-db           machine: in-memory database guest for the data gravity demo
apps/machine-analytics    machine: analytics guest co-located with the db (itself a consumer of db_machine)
apps/host                 consumer: attaches to all machines by address only (machinen.config.json); web server (src/server.ts) + dashboard pages (public/index.html, public/gravity.html)
scripts/                  dev orchestrator (stands in for per-machine deployments)
docs/guest-protocol.md    the wire protocol any guest language implements
docs/operators.md         wiring, call policy, hooks, drivers, demos, machinen.config.json
docs/machinen-driver.md   the real microVM driver and its CI validation
docs/writing-a-machine.md how to build a new machine in any language

Run it

pnpm install
pnpm test           # unit tests + cross-language conformance suite
pnpm -r build       # plugin, node apps, and the Java machine jar/bundle
pnpm demo           # boots all machines as separate services, runs the host
pnpm demo:snapshot  # boot once -> freeze -> restore elsewhere, state intact
pnpm demo:pull      # fork-by-fetch: pull a machine's image/snapshot, boot a clone
pnpm demo:machinen  # the same story on REAL microVMs (needs /dev/kvm or Apple Silicon)
pnpm demo:web       # interactive dashboard at http://localhost:3800 (+ /gravity)
pnpm demo:gravity   # data gravity comparison, CLI edition
pnpm bindgen        # pull typed bindings from the deployed machines
pnpm bindgen --check  # verify committed bindings match the machines (CI gate)

pnpm demo:machinen is runtime validation for deployment owners. Normal consumer wiring uses deployed machine addresses or published machine artifacts; Java jars are build inputs, not the machine entries consumers pass around.

Requires Node 22+, a JDK 21+ for the Java machine, and Python 3 for the Python machine. CI runs the full suite plus all three demos and the web demo smoke checks.

Docs

• Operators guide — advanced wiring, call policy, hooks, snapshot/restore, demos, machinen.config.json.
• Real Machinen driver — booting actual microVMs, whole-VM snapshots, perf numbers, CI validation.
• Writing a machine — build a new machine in Node, Java, Python, or anything else.
• Guest protocol v3 — the wire contract every machine implements.

Status

Experimental. The binding layer is real today, and so is the VM layer: machinenDriver() boots, snapshots, and restores actual microVMs through @machinen/runtime (published on npm; see the Real Machinen driver), proven end to end on x86_64/KVM with the upstream 0.4.0 quirks documented and worked around. The process driver is the lightweight local driver — same boot/port-forward model, child processes instead of VMs — for dev loops and tests, and the Machinen CI lane keeps the real-VM path continuously validated as @machinen/* releases and runner hardware evolve.