#The Module Library
The library is where modules live before they reach a classroom. From here you create new modules, edit the ones you own, share them with other organizations, and watch their builds promote into the deployment zones where students will run them.
#Anatomy of a module
A module is the combination of a few things, authored together but conceptually separate.
| Part | What it is | Where it is documented |
|---|---|---|
| Manifest | The YAML that describes the VMs, their base images, ISOs, provisioners, and networking. | Building VM images |
| Briefing | The HTML prompt students read when they open the module. | Briefings |
| Teacher briefing | An optional second prompt only teachers see, for solution notes or proctor hints. | Briefings |
| Rubric | The autograder spec: which commands run on the VM and how output becomes points. | Writing a rubric |
| Tags | Categorized labels (e.g. topic, difficulty) used to find and filter modules. | This page. |
| Time limit | Optional minutes-allowed cap surfaced to students. | Timers |
You will find all of these on the module's page in the library.
#Creating a module
From your organization's library, click Create New Module. The creation form takes a name, a short description, the briefing and teacher briefing, an optional rubric, an optional time limit, and the manifest YAML. Tags are added after the module is created; the create form itself does not have a tag picker.
Once you save, the platform queues a build in your organization's zone: it runs the manifest, captures the resulting disks, and stores them as the cloneable image set students will run. See Building VM images for what the manifest contains. Builds happen per zone, so the same module can have separate builds in separate zones.
Until a build succeeds and is promoted to stable, students cannot start the module. The library shows each module's current build status.
#Editing and updating
Open a module from the library to edit it. The manifest, briefing, teacher briefing, rubric, tags, and metadata can all be changed. Saving a manifest change kicks off a new build; saving a briefing or rubric change does not.
Released modules are pinned to a specific build. Updating the module after it has been released does not change the version your current students are running. To ship an update to an active classroom, create a new release after the new build is stable. See Classrooms.
#Tags
Tags are categorized labels that drive the library's search and filter UI. The platform ships with a curated set of categories (for example, topic and difficulty). When you tag a module, you pick a category and either choose one of its predefined values or enter a custom value. Multiple categories can apply to the same module.
Most tags are visual metadata: they do not affect grading or VM provisioning. Use them to make modules findable for the teachers in your organization and the organizations you share with.
The one exception is Base Image. Tagging a module Base Image is a functional opt-in, not a label: it offers the module as a foundation that other builds can layer on top of. Only the owning organization can set it. See Sharing a base image below and Layered builds.
#Sharing with other organizations
A module can be shared from your organization to another at one of two levels:
- Consumer. The other organization can release the module to its classrooms, and preview it to try it first, but cannot edit it.
- Maintainer. The other organization can edit the module as well as release it. Use this when you genuinely want a co-author elsewhere; otherwise prefer consumer.
Sharing is per-organization, not per-module-version. The shared organization always sees the latest stable build. To revoke, change the share back from the same UI.
#Sharing a base image
Neither level lets the other organization edit your module. But a consumer share plus the Base Image tag lets them build their own modules on top of yours, without touching yours at all. This is how you publish a common foundation — a hardened OS with your guest tools and certificates already installed — that other organizations extend for their own courses.
To offer a module this way:
- Tag the module
Base Image(owner only, from the module's page). - Share it to the other organization at consumer level.
They then pick your module from the Base Image dropdown when authoring a VM in their own module. Their module is theirs: they own it, build it, and release it. Yours stays read-only to them, and they see the module's current stable build, so improvements you promote flow into their next build automatically.
A maintainer share does not need the tag; maintainers can already layer on any module they co-maintain. The tag is what extends that ability to consumers, which is why only the owner can set it.
#Sharing a layered module shares its base images
If your module is built on a base image, sharing it shares that base image too. There is no way around this: the other organization's deployment zone rebuilds the whole layer stack, so the base's contents run there as well. The share dialog names the base images involved before you commit to it, and marks any that belong to a third organization — tagging Base Image is that owner's agreement to being built on, but they are not told who you pass it along to.
Your module must have a stable build in their deployment zone before it appears in their picker. If both organizations are in the same zone, this is already true. If they are in a different zone, they build it there themselves — see the note below.
#Builds across zones
Each deployment zone maintains its own build of a module, because the binary disk images are produced inside the zone where they will run. A module's definition is global; its builds are not.
A build is never copied from one zone into another — the disk images live inside the cluster that produced them. Instead the receiving zone rebuilds the module from its manifest, and you ask it to with Make available here.
This matters when you share across zones. The receiving organization gets the module's definition immediately, but their zone has no build until it makes one. Until then the module shows no stable build for them, and controls that depend on one — Release to class, Preview, and the Base Image dropdown — stay unavailable.
#Making a module available in your zone
Any organization that can see a module can build it in its own zone. From the library list, a module that has no build in your zone offers a download button in place of the disabled Release to class; the module's own page carries the same control under Availability in your deployment zone. Either one starts the build. It takes the same few minutes any build takes, and the module becomes releasable when it finishes.
If the module layers on Base Image modules, those are built in your zone first, automatically and in the right order. You must be entitled to each of them — a base image has to be shared with you and tagged Base Image, exactly as if you were layering on it yourself. If one is not, the request is refused and names the module to ask for, and nothing is half-built.
#What an organization can do with a module it builds here
Building a module in your zone means running it: its manifest executes on your infrastructure, and its provisioner output lands in your logs. So once a module is available in your zone, your organization can work with those builds like any other — see the build, read its logs, complete a handbuild step, and promote a build to stable for your zone. None of that touches the owner's zone or their copy of the module.
What stays with the owner is the module's definition. Reading or editing the manifest needs a maintainer share; a consumer builds the module without ever seeing its source. Note this is a product boundary rather than a secret: anyone building a module necessarily sees a great deal of what it does, from provisioner names and logs to the instructions a handbuild step displays.
Every organization that can see a module also sees a read-only list of that module's builds in its own deployment zone — enough to tell whether a usable build exists and when it was made. Failure detail, logs and consoles stay with the organizations that can act on those builds.
#Updates are yours to take
Your zone stays on the version of the module it built. When the owner publishes changes, the module's page shows Update available with a button to rebuild against the latest version. Until you take it, your students keep getting the image you already have — an owner's edit cannot change an environment your class is partway through.
Pressing Launch Build on a module you adopted takes the owner's current version and builds that, so it is also how you move to a newer one deliberately.
One exception, worth knowing: this pins the image, not the rubric. Rubrics are part of the module's definition and are shared everywhere immediately, so if the owner changes how the module is graded, that applies to your students at once, even though your image has not moved. If a module's grading matters to you and its owner is outside your organization, watch for rubric changes as well as image ones.
If you are sharing a module specifically as a base image to an organization in another zone, have them use Make available here on it once. After that it appears in their Base Image dropdown as a layering source.