Modules

A module is a versioned, reusable piece of lab content. It lives in its own Git repository, it is authored the same way a lab is, and labs pull it in by address and version. The registry is your team’s catalog of them.

Modules replace the sandbox presets of the previous generation of Instruqt, and they go considerably further: where a preset packaged a sandbox, a module can package any part of a lab. See What’s new for how the two compare.

What a module can contain

A module can contain everything a lab can, except the lab resource itself:

• Sandbox resources – containers, virtual machines, networks, cloud accounts, and the rest
• Tabs and layouts
• Pages
• Activities – tasks, quizzes, and notes
• Dynamic values – variables, locals, outputs, and secrets
• Files
• Other modules

Because a module has no lab resource, it also has none of the things that resource configures. A module has no chapters – its pages are a flat list – and no time limit, no lab details, no maintenance mode, and no default layout.

What a module is not

A module cannot be played or run on its own. There is no Play, no session logs, and no share link for a module. It only means something once a lab uses it, which is also why a module’s usage is tracked against the labs that depend on it rather than against sessions of its own.

Versions

Editing a module happens on branches, exactly as it does for a lab. A version is something else: a deliberate snapshot of a branch, numbered with semver, and immutable once published.

A lab either pins one exact version or gives a constraint – a semver range. A constraint is resolved against what is published at the moment the lab is opened in the editor, and again every time a session starts, so a lab can pick up new releases without being republished.

Publish and manage versions covers this in full.

Visibility

A module is either Private, meaning only the owning team can use it, or Public, meaning any Instruqt team can add it from the community registry. Visibility is set when the module is created and can be changed afterwards in the module’s settings.

Create and edit a module covers what going public commits you to.

Address

A module’s address is team-slug/module-slug – for example acme/postgres. This is the string a lab writes as the module’s source:

module "postgres" {
  source  = "acme/postgres"
  version = "~> 1.4"
}

Both slugs are immutable. A lab pins that string, so changing either half would silently repoint every lab that used it. Renaming a module is a move, not an edit.

Composition rules

Several things that would ordinarily collide are safe here, and it is worth knowing why before you design a module:

• Many modules in one lab. A lab can depend on as many modules as it likes.
• The same module more than once. Adding a module a second time gives the new block a deduplicated name – postgres, then postgres-2, then postgres-3.
• Different versions side by side. Two blocks may pin two different versions of the same module in the same lab.

None of this collides, because every resource inside a module is namespaced by the module block it came from. A container named web inside the block postgres is addressed as module.postgres.resource.container.web, and a container of the same name inside postgres-2 is a different resource entirely. Sandbox DNS names carry the block too, so the two containers answer to different hostnames – see Namespacing.

Modules nest: a module can depend on other modules, up to 10 levels deep.

How this section is organised

Page	Covers
Create and edit a module	The registry list, creating and importing a module, the module editor, inputs and outputs, settings, and deletion.
Publish and manage versions	Publishing a version, semver guidance, and revoking, restoring, and deleting versions.
Using modules	Adding a module to a lab or to another module, pinning a version or a constraint, setting variables, and referencing module outputs.
module resource reference	Every field of the module block, the source and constraint syntax, and the reference grammar.