Enabling Modules at Runtime
Every registered module compiles into the single binary. In the core-only base that means the seven core modules — user, notification, tenant, authz, auth, navigation, logging — 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.
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.