Module Installation

Install linked modules, service-backed module releases, catalog entries, console bundles, and service plans.

Installing a module is a host-local operator action. Discovery and installation are separate on purpose.

For the discovery side of this split, read Module Catalogs.

lenso module install is the business-capability entrypoint. The release or catalog entry decides whether that capability comes from linked Rust code, a service provider, a bundled host module, or a future sandbox. lenso service install is lower level: it connects a provider process, but it is not the primary way a user asks for a module capability.

Linked first-party modules

First-party linked modules are installed by name:

lenso module install auth
lenso module install auth-password
lenso module install auth-device

auth-password and auth-device depend on auth. Runtime Console exposes declared dependencies through module metadata so the operator can see why a module is not ready.

Profiles can change install effects:

lenso module install auth --profile redis-session-cache

The Redis session profile enables the auth Redis feature, writes REDIS_URL, and records auth.session_cache=redis as a runtime default.

Module releases

Install a packaged business module through its module release artifact:

lenso module release inspect dist/lenso-service/support-suite-provider/modules/support-ticket/lenso.module-release.json
lenso module install dist/lenso-service/support-suite-provider/modules/support-ticket/lenso.module-release.json \
  --base-url http://127.0.0.1:4110/lenso/service/v1

For source: service, the module release points at the provider service package or service manifest. For source: linked, the same release protocol can enable linked Rust code:

{
  "protocol": "lenso.module-release.v1",
  "name": "auth-password",
  "version": "0.1.0",
  "source": "linked"
}

lenso.module.v1 is the standalone module contract. It names the module before release/provider concerns:

{
  "protocol": "lenso.module.v1",
  "name": "support-ticket",
  "version": "0.1.0",
  "source": "service"
}

The host still owns install state, queues, retries, Runtime Stories, and Console evidence.

Install the owning Service through its Service manifest:

lenso service install http://127.0.0.1:4110/lenso/service/v1/manifest

After installation, reconcile the Host and verify the provider with lenso service doctor <provider> --json.

What install writes

The service/module install lane writes host-local files:

File	Purpose
`.env`	records the CLI-managed Service provider entry and declared env values
`.lenso/module-installs.json`	install receipt used by uninstall
`.lenso/module-services.json`	service commands declared by the module

Install commands from a manifest are planned but not run unless the operator opts in:

lenso service install https://example.com/lenso/service/v1/manifest

Catalog is discovery

Available Modules uses discovery data only. It does not install a module until the operator runs an install action.

Runtime Console’s Available Modules view reads, in order:

explicit .env LENSO_MODULE_CATALOG_FILE=<path>
already configured Service providers
built-in builtin:lenso-official-module-catalog

The built-in catalog is the default discovery source for fresh hosts. It is not a hidden install database.

Runtime Console install flow

Runtime Console can write the same host-local install state through:

POST /admin/data/available-modules/{module}/install

This is still host-owned installation. The browser does not install npm packages or compile third-party code into the official Console bundle.

Doctor and uninstall

Check installed service-backed module state:

lenso module doctor
lenso module doctor billing

Remove host-local remote source and console registry entries:

lenso module uninstall billing

Uninstall leaves module-owned data alone. It removes the host’s local install state; it does not drop remote service databases or business records.