Skip to content
Intellia Overview
Modules

Modules

A module is a registry entry that packages one or more of your existing app sites and/or workflows into a single, named product — { slug, name, description, version, visibility, category, tags } plus a set of roots.

Modules are authored by Hutly and browsed by every organization in a shared catalogue. Think of a module as the definition of a product; a later release will let an organization bring a module into its own workspace.

Roots

A root points at a resource that already exists in the authoring organization — a module doesn’t create anything new, it names and describes resources that are already built:

  • app_site — an existing app site, by id.
  • workflow — an existing workflow, by id.

Every root carries its own human-readable description — required, not optional. That description is what a browsing organization reads in the catalogue, so a module can’t be registered with an undescribed root.

Authored by Hutly, for now

Registering a module is currently restricted to Hutly’s internal authoring organization — a module’s roots must reference resources that live in that same org. This keeps the registry’s contents Hutly-curated while the rest of the system is Hutly-curated on the authoring side; bringing a module into your own organization — activation — is described below.

Activation

Activation clones a module’s resources into a consumer org. It runs as a stepped activation session, not a single call, because a module can carry secrets or integration references the consumer org hasn’t configured yet:

preview → holes → configure → accepted → deploying → done | failed
  • preview — the session is created; it snapshots the module and returns a summary plus any unresolved holes.
  • holes — unresolved secrets or integrations the module’s resources depend on. A session can’t be accepted while holes remain; resolve them (vault items / integrations) in the consumer org, then recompute.
  • configure — set the app_site slug (workflow-only modules have none) and any params.
  • accepted — a strict gate: accepting fails if any holes are still unresolved.
  • deploying — the accepted session’s resources are cloned into the org asynchronously.
  • done / failed — the terminal states.

A session has one of two snapshot origins:

  • registry — the session snapshots the module exactly as currently registered in the catalogue. This is the standard path: activating a module by its catalogue id.
  • uploaded — the session snapshots a bundle supplied by the caller instead of the registry — the shape hutly modules project emits, typically after Sammy has edited the projected tree. Uploaded origin currently supports workflows and agents only.

Drive a session step by step with hutly modules activation ..., or run the whole thing in one shot with hutly modules activate <target> (<target> is a registry module id, or a directory for uploaded origin). See the CLI reference and API reference for the full command/endpoint set.

Once activated, an org can hide or unhide the module without deactivating it — useful for temporarily removing it from view without losing its resource mappings.

Two authoring channels

A module can be authored two ways, over one shared engine:

  • Interactively (Sammy). Sammy builds the workflows, agents, tables, and apps in the authoring org, then registers the module with hutly modules define — no files, no git; the registry references the live resources.
  • Code / CI (curated modules). A module is committed as a projected YAML tree under modules/<slug>/ in the repo (ids stripped, resources linked by !ref), and a CI action deploys it into the authoring org and upserts the registry entry with hutly modules deploy. This is the channel for curated, version-controlled modules; the YAML tree is the CI transport, not a per-module requirement.

Projecting a module

A registered module can be projected to a portable YAML package on disk — useful for review, diffing, or committing under modules/ — via hutly modules project. Deploying a projected tree back into the authoring org (and re-registering it) is hutly modules deploy, the code/CI channel above. Bringing a module into a customer organization is activation, described below.

Browsing the catalogue

Any organization can list the modules in the registry:

hutly modules list

This returns each module’s slug, name, description, version, visibility, category, and tags. See the CLI reference for the full command set, including how a module is registered.