Browse and manage the module catalog

Modules are trusted, signed, in-process components that extend the platform. Each module ships a manifest declaring its stable ID and version, compatible Core/API/SDK ranges, dependencies, publisher and provenance, permissions, configuration schema, UI contributions, job types, health checks, and lifecycle behavior.

The reference implementation is cloudgrange-module-example — a harmless echo/system-information module that exercises the full lifecycle and every integration surface.

CloudGrange is in active development and is not GA. Module signing is planned but not yet implemented — current builds are unsigned test builds. See current product and release status.

Where modules run

A module is a container workload the platform starts, routes to and scales, so modules need a container runtime the platform controls. Every Kubernetes path has one: the appliance VHDX, the Windows and Linux installers, bring-your-own Kubernetes, and AKS.

Modules and the Container Apps path

Modules are not available on Azure Container Apps. That deployment has no Kubernetes cluster to put a module workload in, and CloudGrange does not yet run modules as Container Apps of their own.

The product states this rather than letting you find out:

  • the Module Catalog shows the reason and the Install button is disabled;
  • POST /api/v1/modules/{id}/install, the enable endpoint and the module proxy answer 501 Not Implemented with the problem code module-runtime-unsupported and the reason in detail. It is 501, not 503, because the condition is permanent — retrying will not help;
  • nothing is written, so a refused install leaves no module to clean up;
  • the API reports the host's capability on GET /api/v1/modules/catalog as runtime { kind, supported, available, reason }, which is what the portal reads.

If you need modules on Azure, use AKS — the same product, the same chart, and modules run normally.

Trust model

Modules run in the platform host process. A shared process is not an isolation boundary: module permissions describe which platform actions a module may take and what an operator consents to, but they cannot sandbox arbitrary .NET code running in the host. Untrusted community code requires isolation and certification before admission. Independent module versions must belong to a certified, compatible portal/Core composition — there is no arbitrary remote code loading.

Lifecycle

Install, upgrade, disable, and removal go through the platform lifecycle:

  • Install/upgrade validates version ranges and dependencies before any code loads, and may restart the host. There is no hot-unload.
  • Disable blocks new module actions while retaining audit and reconciling in-flight operations.
  • Removal retains module data by default; purging data is a separately authorized action.

Catalog operations

The catalog is browsable from the portal, the cg CLI, and the REST API:

cg module catalog list                 # browse the published catalog
cg module catalog list --verified      # only cosign-verified modules (once signing lands)
cg module list                         # installed modules
cg module install <id>                 # install from catalog
cg module enable <id>                  # enable / disable
cg module disable <id>

Equivalent API routes are under /api/v1/modules (see REST API reference).

See current product and release status.