Module model

Module model

LM Nexus is modular, but it still ships as one application.

First-party modules can add pages, settings, tools, dashboard pieces, and backend behavior through shared manifests and extension points instead of being wired directly into one giant feature tree.

Architecturally, this is a static modular monolith: modules are composed into the app at build/startup time rather than downloaded and hot-loaded as arbitrary JavaScript at runtime.

Composition

Product bundles choose which module manifests are included and in what order.

They are assembly layers, not folders where feature logic should accumulate.

Modules can contribute things such as:

• backend routes and startup/shutdown hooks;
• frontend routes and navigation;
• settings sections;
• status and dashboard surfaces;
• global actions and commands;
• Agent Tool providers;
• other declared extension points.

How modules talk to each other

When one module needs something from another, it should use a declared dependency or public capability instead of importing the other module’s private implementation.

That keeps optional integrations genuinely optional and makes failures visible instead of creating hidden coupling.

Static, not arbitrary hot-loading

Installed packages and module profiles may require a frontend reload, backend restart, or rebuild before they become active.

LM Nexus does not claim to safely hot-load arbitrary user-supplied frontend code from app-data while the application is running.

Core and first-party extensions

“First-party” does not automatically mean “core.”

Some modules are part of the foundation of LM Nexus. Others are first-party extensions that can use the same package/module system without becoming mandatory for every installation.

Next

Read Marketplace & extensions for how packages work today and what is still missing before a broader public extension ecosystem.