#The Module Library

The library is where you prepare modules before releasing them to a classroom. Create, edit, share, and track builds here.

#Anatomy of a module

A module brings together a few distinct parts.

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.

Students cannot start a module until its build succeeds and is promoted to stable. The library shows the 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.

#Forking a module

A fork is an independent copy owned by your organization. From the module's page, open the right-hand Actions menu, choose Fork module, give the copy a unique name, and choose Create fork. You must be an organization admin, and your organization must be permitted to create modules.

Your organization must own the module or have an explicit Source access or Maintainer share to fork it. Public visibility, consumer shares, and access through a shared stack do not grant fork permission. Building or adopting a module in a non-public deployment zone does not grant it either; those permissions allow use, not copying its definition.

Source access and maintainer shares allow recipients to make an independent copy of all authoring content, including the manifest, teacher notes, and rubric answer key. The recipient owns the copy permanently and can edit, share, or publish it independently. Removing source access or maintainer access, or downgrading to consumer, prevents new forks of the source; archiving the source prevents all new forks. Neither revokes existing copies or prevents their owners from forking those copies.

A fork copies the current saved briefings, manifest, rubric, time allowance, helpdesk content, and descriptive tags—not a particular stable build. It starts private, unshared, and without marketing approval. The permission-granting Base Image tag is not copied; the new owner can opt in separately.

Builds, stable pointers, adoptions, VMs, releases, grades, votes, and history are not copied. Build and promote the fork separately before releasing it. Existing base-image references are preserved, but no access to those dependencies is granted; inaccessible dependencies are flagged and existing build-time checks still apply.

Changes never flow back to the source, and source updates do not update the fork. The module page records when it was forked and links to its immediate source only while you have access to that source. Otherwise it shows Source unavailable. Forking a fork records that fork as the immediate parent.

#Tags

Tags help people find modules in the library. Choose a category, such as topic or difficulty, then select a value or add your own. A module can have tags from several categories.

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.

#Public website preview

The public module library preview is a curated selection of real modules, not the full catalog. Making a module public in the application does not automatically feature it on the website.

Superusers manage this selection under Marketing Library in the side menu. Search for a module, review its description, then choose Approve for marketing. Approval exposes its name, description, standard tags (Content Area, OS, Difficulty, and Contest), configured time limit, internet requirement, and whether it has a grading rubric. Briefings, teacher notes, rubric contents, manifests, and build details are not included in the anonymous preview. The preview reads the current metadata, so edits to approved descriptions and tags appear there too.

A featured module must remain public and active, belong to an active organization, and have a usable stable build in at least one public, non-retired deployment zone. Losing any of those conditions hides it automatically. Revoke approval removes it from the preview without changing its visibility inside the application.

Module cards show their real tags to help visitors understand the content, without catalog counts or a separate filter panel. Module overviews link directly to signup and login. No module selection is saved or carried into onboarding; users can find the module again in their organization’s library. Existing access rules, internet-module visibility preferences, build availability, and capacity requirements still apply. Signup does not start a VM.

#Sharing with other organizations

A module can be shared from your organization to another at one of three levels:

• Consumer. The other organization can release the module to its classrooms, and preview it to try it first, but cannot edit it.
• Source access. The other organization can view the full manifest and fork the complete definition, including teacher notes and rubric answers, but cannot edit the original. Forking still requires an organization admin and permission to create modules. This level does not grant build operations on the original: the non-public-zone adoption rules still apply.
• Maintainer. The other organization can edit, build, and fork the module as well as release it. Use this when you genuinely want a co-author elsewhere; choose Source access for read-only authoring access or Consumer for use only.

Only the owning organization can grant these shares. Public visibility and module access inherited through a stack remain Consumer; they never grant Source access. Existing shares keep their current level.

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.

To share a whole sequence of modules at once, put them in a stack and share that instead.

#Adding an organization you have not shared with before

The share dialog lists the organizations you have already shared something with. It is not a directory of everyone on the platform, and it never was meant to be one.

To reach someone new, choose Add an organization and enter the email address of one of their admins. Ask them for it directly. You cannot search by organization name, because a name is something anyone could guess and an address is something they chose to give you.

That address may belong to someone who administers more than one organization, so the next step asks which one you meant. Organization names are not unique, so read the line under each name: it shows the admin's email domain, the deployment zone, the date the organization was created, and how many classes and students it has. Two organizations called "My Organization" are told apart there.

If nothing comes back, either the address is wrong or that organization has sharing turned off. Check the address with them first.

#Letting other organizations share with you

Your organization settings have a Accept shares from other organizations switch, on by default. Turn it off and nobody can find your organization by any of your admins' addresses, and no new share can be sent to you. Shares you already have keep working, and you can always remove them.

Your settings page also lists your own admin addresses. Give one of those to an organization that wants to share with you.

#Sharing a base image

Consumer and Source access shares do not let the other organization edit your module. But either 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:

1. Tag the module Base Image (owner only, from the module's page).
2. 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 consumer and source-access recipients, 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 an administrator in a non-public deployment zone can request that rebuild with Build in this zone.

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

Organization admins assigned to an active non-public deployment zone can build modules they consume, including public modules, in that zone. Public-zone membership alone does not grant this permission. Owners and maintainers retain their existing build rights.

From the library list, a module built in another zone but not yet requested in yours offers Build in this zone alongside the disabled Release to class button. This builds the module without forking it or changing its owner. Follow progress in the module's Builds tab; once a stable build is available, you can preview and release it. The module's page does not have a separate deployment-zone panel.

Required base modules are built in your zone first, automatically and in dependency order. Publishing a module authorizes dependency-only builds of its publisher-owned base chain in an active non-public zone, including private bases without a separate share or Base Image tag. This does not make those private bases browsable, expose their source, permit forking them, add them to the Base Image picker, or grant independent use of them.

This permission follows only dependency links between modules owned by the public module's publisher. Third-party bases still need their own grant: they must be shared with you (or public in an active non-public zone) and tagged Base Image; maintainer shares do not require the tag. Archived bases remain blocked. If a dependency is unavailable, the request is refused before anything is adopted. Private shared modules do not implicitly grant access to their hidden bases.

#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 the manifest needs Source access or a maintainer share; editing still needs maintainer access. A consumer builds the module without being granted 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, use Launch Build in the module's Builds tab to rebuild against the owner's 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 an admin in their non-public zone use Build in this zone on it once. After that it appears in their Base Image dropdown as a layering source.