Shipping UI to a Live Trading Client Without a Redeploy: A Module Federation Case Study

Self-hosted software has a deployment problem that SaaS never faces: the client runs on the user's machine, not yours. For a trading platform where members run the automation client on their own device or cloud, that raises a hard question — how do you ship an interface improvement without making every user pull, rebuild, and redeploy, and without interrupting the automation that is actively managing positions? The answer StaxInvesting uses is a Vue micro-frontend on Module Federation, and it is a genuinely interesting piece of engineering independent of the trading context.

The Core Idea: Ship the Remotes, Not the Shell

Module Federation splits an application into a host (the shell) and one or more remotes — independently built bundles that the shell loads at runtime rather than at build time. The self-hosted client ships as a thin shell: it knows how to boot, authenticate, connect to the local automation process and backend API, and fetch its UI remotes from a manifest. The actual interface — dashboards, trade tables, settings panels — lives in remotes hosted on Cloudflare Pages. When you push a UI change, you deploy the remote to the CDN; the next time the shell loads, it pulls the new version. The user redeploys nothing. Critically, the automation engine runs as its own layer, so replacing a UI remote never restarts the process placing trades.

2026 Makes This Easier Than It Used To Be

Micro-frontends earned a bad reputation from 2021 to 2023, when shared state was a nightmare and two teams needing the same framework version could break everything. Module Federation 2.0, stable across the ecosystem in 2026, addresses the worst of it. The 2.0 release decouples the federation runtime from the underlying bundler, so it now works across Webpack, Rspack, Rollup, and Vite through a common runtime rather than being welded to Webpack. It adds manifest-based dynamic discovery, cross-remote TypeScript type sharing, runtime plugins, and preloading — and it added first-class Node.js runtime support, which matters for a stack whose backend is a Node and Express server handling high-concurrency I/O, because the same module-delivery model can extend to server-side rendering and backend-for-frontend layers.

The Hard Part: The Shell-to-Remote Contract

Here is where the honest version diverges from the marketing version. The moment your UI loads at runtime from a separate deployment, you have introduced distributed-systems concerns into your frontend, and they do not disappear because the demo worked.

The first and sharpest is shared dependency versioning. The shell and every remote must agree on a single, compatible instance of Vue — Vue has to be a singleton in the shared configuration — or you end up with two framework instances, broken reactivity, and duplicated runtime shipped to the browser. Managing those version ranges is most of what keeping the contract stable actually means in practice. Bump Vue in the shell without a compatible range in the remotes and you get a runtime failure, not the build-time error that would have caught it.

The second is interface stability. The exposed surface of each remote — the modules it exports, the props and events it expects, the shared libraries it assumes — is a contract with the shell. Break it in a UI push and you break a client that is running live. The discipline is the same as versioning a public API: additive changes are safe, removals and signature changes are not, and you need a deprecation path rather than a hard cutover.

The third is runtime availability. Remotes load over the network from the CDN, which means a remote can be slow, stale, or briefly unreachable. Without an error boundary and a fallback, a failed remote fetch is a blank screen on a trading interface. The manifest and preload features in Module Federation 2.0 help with the request-waterfall problem that micro-frontends are prone to, but they do not remove the need to design for the remote simply not being there.

Why It Is Worth the Complexity Here

Module Federation adds real operational overhead, and for a small single-team app it can be overkill. It earns its place when the deployment constraint is genuinely hard, and a client that runs on the user's machine and has to keep automating through updates is exactly that constraint. The separation also enforces a clean boundary: the UI layer and the execution layer are decoupled by construction, so interface iteration cannot accidentally take down automation, and the automation, running on self-hosted, low-latency nodes, is insulated from the front-end release cadence. That decoupling is the same principle behind the whole platform: StaxInvesting is Software — Not Signals, self-hosted with zero account access, and the architecture is what lets the interface evolve weekly while the engine underneath keeps running.

This article is a technical overview and not financial advice or a recommendation to buy or sell any security. StaxInvesting provides self-hosted trading software — not signals or a managed account — that runs on the member's own connected brokerage; StaxInvesting never accesses member funds, credentials, or trades. Tooling and version details reflect the state of the ecosystem as of July 2026 and are subject to change.