What's New in Instruqt 2.0
Instruqt 2.0 is not a coat of paint on the platform you already know. The content model, the authoring experience, and the way sandboxes are defined have all been rebuilt. There are 56 new or reworked capabilities, a set of new names for familiar concepts, ten features that now work differently, and a small number that have been removed.
Start with the new names
Section titled “Start with the new names”Almost every other change on this page depends on this vocabulary, so it is worth two minutes.
| You used to say | In 2.0 it is | What is different |
|---|---|---|
| Track | Lab | The core unit of content |
| Challenge | Page, grouped into chapters | A page holds instructions, tasks, and quizzes together |
| Check | Task | Multiple conditions per task, each with its own fail message |
| Sandbox preset | Module | Reusable across labs and versioned through a registry. Modules arrive at general availability, not in Early Access |
| Custom resource | Terraform | Standard Terraform replaces the custom abstraction |
| Track level script | Exec resource | Declared as a resource, not a separate script file |
| Challenge script | Task or condition script | Tied to the individual condition it validates |
The five shifts that explain the rest
Section titled “The five shifts that explain the rest”Sandboxes are declared, not scripted. The base language moves from YAML to HCL. Resources are declared directly and reference each other, so the environment is explicit, reviewable, and far less dependent on setup scripts.
Pages replaced challenges. A page can carry instructions, several tasks, and quizzes at once, in any order. Chapters group pages into themes, so a lab has visible structure instead of one long sequence.
Version control is built in. Every lab is versioned from the moment it is created. No integration to configure, no separate tooling. Branches, version tags, and an optional connection to your own GitHub repository sit on top of that.
Reuse is a first class concept. Modules package any combination of sandbox resources, instructions, and tabs into one versioned unit, published to a registry your whole team pulls from. Modules are not part of Early Access. They arrive at general availability.
AI is part of authoring. The AI Lab Builder is available now at general availability. It plans and drafts a lab from a description of the outcome you want, backed by a knowledge base that researches your company, products, and users first.
Sandbox and infrastructure
Section titled “Sandbox and infrastructure”The sandbox is now a set of typed resources you declare and reference, rather than configuration plus scripts.
| Feature | What it does | Available |
|---|---|---|
| Declarative sandboxes | HCL replaces YAML. Resources are declared directly and reference each other, so the whole environment reads as one definition. | Early Access |
| Containers | CPU, memory, and GPU limits, plus health checks that can test HTTP, TCP, or run a command. | Early Access |
| Network | An isolated network that containers and other resources share, for communication between them or to segment parts of a lab. | Early Access |
| Exec | Runs a command on a remote system as part of setup, replacing what used to live in a track level script. | Early Access |
| Terraform | Runs Terraform as part of setup through a Terraform registry, replacing custom resources. | Early Access |
| Kubernetes cluster | Provisions a cluster as its own resource, so it can be referenced and ordered correctly against what depends on it. | Early Access |
| Kubernetes config | Represents a kubeconfig as its own resource, so cluster access can be declared and referenced like anything else. | Early Access |
| Template | Generates a configuration file or script from a template, instead of hardcoding values into a lab. | Early Access |
| Random generators | Built in generators for creature names, IDs, numbers, passwords, and UUIDs. | Early Access |
| Dynamic values | Four building blocks for moving values through a lab, including secrets for team managed values and variables for values a lab declares itself. | Early Access |
| Expression and literal fields | A toggle on any field, whether an ordinary resource setting or the value of a variable, so you can enter a fixed value or compute one. | Early Access |
| Native assets and files | Assets and files are part of a lab’s structure, whether you work in the UI or in code. | Early Access |
| Virtual browser | A new browser engine with meaningfully better performance, more reliable behavior, and working copy and paste. | GA |
| Sidecar | An additional container that runs alongside a main container for a specialized function, sharing its context. | Post GA |
| Ingress | Routes external traffic to a service over HTTP or HTTPS, giving it a real URL instead of a raw IP. | Post GA |
| Copy | Copies files or synchronizes a directory between host and container, instead of scripting the transfer. | Post GA |
| Helm | Deploys a Helm chart into a cluster as its own resource, ordered correctly against the cluster itself. | Post GA |
| HTTP | Makes an API call as part of setup, to seed data or confirm a service is ready before learners arrive. | Post GA |
| Nomad cluster and job | Deploys a Nomad cluster and schedules a job on it, the Nomad equivalent of the Kubernetes resources. | Post GA |
| Certificates | Certificate CA and Certificate Leaf resources generate a full certificate chain declaratively. | Post GA |
| Pausing | Pausing a running lab, so a learner can stop and pick it up later. | Post GA |
Hotstarts are not available in Early Access. If your labs rely on hotstarts today, factor that into when you plan to move them across.
Debugging and validation
Section titled “Debugging and validation”Two features aimed squarely at the time between “it broke” and “I know why.”
| Feature | What it does | Available |
|---|---|---|
| Validation | A validate command checks a lab’s definition, its resource references, and its task mappings before the lab ever runs. | Early Access |
| Logs | A rebuilt logs experience with more information, real controls to filter and slice it, and a layout built for finding a cause quickly. | Early Access |
Content structure
Section titled “Content structure”How a lab is assembled, and what a learner sees on screen at each step.
| Feature | What it does | Available |
|---|---|---|
| Pages | Challenges are now pages. A single page can combine instructions, multiple validations, and quizzes. | Early Access |
| Chapters | Folders for pages, grouped by theme, so you can label the journey itself and not just its steps. | Early Access |
| Layouts | Set per page, so the screen changes as a learner moves through a lab: one tab for a reading step, a terminal and an editor for a hands on one. | Early Access |
| Persistent tabs | A tab is created once and assigned to a layout, carrying the learner’s actual state forward across every page it appears on. | Early Access |
| Notes tab | Notes are a tab type, so they can be placed anywhere in a layout, as many as you need, only where they help. | Early Access |
| Cloud credentials tab | Natively exposes the credentials for a given cloud account, so a learner sees what they need without you writing it out. | Early Access |
| Labs without instructions | A lab does not need instructions at all, which turns it into an open ended environment rather than a guided one. | Early Access |
| Sandboxless labs | A lab type with no sandbox attached, just instructional content, quizzes, and presentation material. | Post GA |
Content components
Section titled “Content components”The pieces you drop onto a page. Tasks and quizzes together are called activities, and you can place as many of them on a page as the content needs.
| Feature | What it does | Available |
|---|---|---|
| Activities | The group name for tasks and quizzes, covering everything you ask a learner to do or answer. Both sit inline on a page, in any order, and can be mixed on the same page. | Early Access |
| Tasks | Tasks replace checks as a real component on a page rather than a button. A task holds multiple conditions, each with its own fail message. | Early Access |
| Quizzes | Inline on any page, multiple questions on one screen, with new types including text input and number input. | Early Access |
| Completion component | Placed at the end of a lab with a customizable message, buttons, and links, so you control where a learner goes next. | Early Access |
| Feedback component | Feedback sits directly in the content, on a page or in a notes tab, with customizable question text. A lab can include several. | GA |
| Embedded PDFs | A PDF is embedded directly into a lab and renders inline. | Early Access |
| Embedded Google Slides | A Google Slides URL renders inline, the same way a PDF does. | Early Access |
Collaboration and version control
Section titled “Collaboration and version control”Version control is not only an integration you switch on. It is how labs work.
| Feature | What it does | Available |
|---|---|---|
| Built in version control | Every lab is versioned from creation, with no GitHub setup and no separate tools. Every change is captured with who made it and when. | Early Access |
| Branches | Any lab can have multiple branches, each a complete working version that can be played and shared on its own. | Early Access |
| Version tags | Mark a known good version of a lab, so content that drifts out of date can be pinned, compared, and rolled back. | Early Access |
| GitHub integration | Connect a lab to your own repository, monorepos included, so lab content lives alongside the rest of your code and syncs both ways. | Early Access |
| Edit mode | Separates viewing a lab from actively editing it, so it is always clear whether you are looking or changing. | Early Access |
Reuse and scale
Section titled “Reuse and scale”Built for teams maintaining many labs rather than a handful. Modules and the module registry are not available in Early Access. Both arrive at general availability.
| Feature | What it does | Available |
|---|---|---|
| Modules | A reusable package built from any collection of elements: sandbox resources, instructions, tabs, and more, versioned as a unit. | GA |
| Module registry | A central space where every module for your team lives, versioned and tracked as it changes. | GA |
| Lab templates | Save an existing lab as a template and use it as a scaffold for future labs, built to be copied safely. | Early Access |
Creator experience
Section titled “Creator experience”The day to day of building, and the part most people notice first.
| Feature | What it does | Available |
|---|---|---|
| New creator UI | Exposes what used to be hidden or implicit, with a genuinely better authoring experience built on top of it. | Early Access |
| Markdown editor | Shows content close to how a learner will actually see it, instead of the raw markdown behind it. | Early Access |
| Command center | A search bar, or cmd+k, that finds anything in a lab and jumps you straight to it. | Early Access |
| Resource usage visibility | A label on any resource shows everywhere else it is used in the lab, and clicking through takes you there. | Early Access |
| Inline comments and notes | Team documentation attached to a resource, explaining why it exists or what it is for. | Early Access |
| Assets and files in the UI | A dedicated tab shows a lab’s full structure: assets, files, and scripts together. | Early Access |
| In product documentation | Tooltips surface the relevant documentation where you are working, with a link through to the full page. | Early Access |
| Dark and light mode | Choose the theme that suits how and when you work. | Early Access |
| Feature | What it does | Available |
|---|---|---|
| AI Lab Builder | Describe what a lab should achieve and who it is for. It plans the structure, then builds it with you inside the product. | GA |
| Knowledge base | Research that happens before anything gets built, covering your company, your products, your users, and the context around them. | GA |
What works differently
Section titled “What works differently”These capabilities still exist, but the way you use them has changed.
| Previously | Now | What this means for you |
|---|---|---|
| Scripts | Exec resources and declarative sandboxes | Setup splits into two parts: exec resources for genuinely imperative steps, and declarative definitions for the environment. The environment becomes reviewable like infrastructure code, and there is less scripting overall, so setup is less fragile. |
| Challenges | Pages and chapters | A page is more flexible than a challenge. Tasks can go anywhere on a page, several can sit together, and quizzes belong on pages too. Chapters group pages so topics are visibly separated. |
| Quizzes | Inline quizzes | No dedicated page required. Place a quiz where it is relevant, put several on one page, and use the new question types for more nuanced assessment. Quizzes and tasks are now both activities. |
| Feedback in labs | Feedback component | Feedback is no longer a fixed part of a lab. It is a component you place, as many times as you like, with question text you write. Because the request sits in the content, more learners answer it. |
| Happiness score | Total of all feedback components | The score is the sum of every feedback component in a lab rather than one fixed value, so you can see which page moves satisfaction, and you collect signal from learners who never reach the end. |
| Final page | Completion component | The end of a lab is a component like any other, with a message, button label, and link you control, so you can connect a finished lab to whatever comes next. |
| Sandbox presets | Modules | A module packages a sandbox the way a preset did, and then goes further: it can bundle instructions, tabs, and other parts of a lab into one reusable, versioned unit shared across many labs. Modules are not available in Early Access, they arrive at general availability. |
| Custom resources | Terraform | Custom resources were always Terraform underneath. Now Terraform is exposed directly, so existing Terraform knowledge applies instead of a proprietary abstraction doing the same job. |
| CLI | Git, with GitHub integration | GitHub integration syncs changes directly, so pushing and pulling happen through a normal git workflow. Every change is recorded, conflicts resolve through a pull request instead of one side losing work, and you can author in your own editor. The CLI still scaffolds a new lab from a template. |
| Track ID | Computed id, resource.lab.{slug} |
The identifier is derived from the resource type and name instead of being a random string, so it is predictable, readable, and tied to the slug. |
Not in 2.0
Section titled “Not in 2.0”These have been removed with no direct equivalent. Some could return based on customer demand.
| Feature | Where it stands |
|---|---|
| Loading between challenges | Pages and resources all load at the start of a lab, so there is nothing to load between pages. |
| Notes as a loading page | Because loading happens up front, there is no notes page to read while you wait. |
| Loading customization | Notes only, full access, and default or custom loading messages are not carried forward. |
| Lab teaser | No equivalent in 2.0. It could return if customers ask for it. |
| Challenge description | No equivalent. Page and chapter structure covers how content is organized instead. |
| Hotstart for sandbox presets | Sandbox presets are gone, so this goes with them. Hotstarts for modules may follow later, depending on demand. |
Reading the availability column
Section titled “Reading the availability column”Early Access means available now, in the Early Access release.
GA means it is not in Early Access and arrives at general availability.
Post GA means it is planned for after general availability.