Enabling Modules at Runtime
Every registered module compiles into the single binary. In the core-only base that means the eight core modules — user, notification, tenant, authz, auth, navigation, logging, compliance — which are always loaded and on. There are no Go build tags and no SKUs; what's available is whatever is registered in the module catalog.
This page is about the runtime enable/disable layer: a fork's optional modules (registered via internal/addons/<name>/ + a cmd/server/catalog_<name>.go) are instantiated at boot but only turned on when an operator enables them at /admin/modules. The base ships an empty optional catalog, so out of the box there's nothing optional to toggle — see the architecture deep-dive for how this works.
Toggle a module
- Log in as
administrator. - Navigate to
/admin/modules. - Flip the toggle for the module you want to enable.
The registry resolves dependencies automatically — using a fork's modules as an example:
- Enabling a module will refuse if a module it depends on is disabled.
- Disabling a module will refuse if another currently-enabled module depends on it.
The change takes effect immediately — no container restart required. Background jobs start, routes unlock, and the navigation menu updates on the next page load.
Configuration changes
Saving a module's configuration is not the same as toggling it. A module that declares HotReloadConfig() picks the new values up at once; every other module reads its configuration once, in Init(), and keeps running on the previous values until the backend restarts. The API records that gap as needsRestart on the module document, and the module detail page shows a Restart required strip for as long as it is set. The flag clears on the next boot.
What persists
Module state lives in the module_configs collection in MongoDB. On every subsequent boot, the registry honors what you set here. On the first boot of a brand-new install the document is seeded from each module's ConfigSchema().EnvVar and its EnabledByDefault value.