Building in Code

If you build in the UI, you can skip this section. If you build in code, this is the part of 2.0 that changes most.

The language

The base language moves from YAML to HCL. This is not a syntax swap. In V1 a track was configuration, and anything the configuration could not express ended up in a script. In 2.0 the environment is declared as a set of typed resources that reference each other directly, so a container can point at a network, a task can point at a container, and the dependency between them is part of the definition rather than an assumption in a script.

Three consequences worth knowing:

• References replace ordering by hand. Because resources refer to each other, the platform works out what has to exist first. You are not sequencing setup steps yourself.
• Fields take a literal value or an expression. A toggle on any field, including the value of a variable, decides whether you enter a fixed value or compute one.
• Values move through a lab explicitly. Secrets carry team managed values and variables carry values a lab declares itself, rather than values being passed around inside scripts.

Less scripting, and scripts that are scoped

Setup logic that used to sit in a track level script now splits in two. Anything genuinely imperative becomes an exec resource, declared like any other resource. Everything that describes the environment becomes part of the declarative definition. Challenge scripts become task and condition scripts, tied to the specific condition they validate rather than to the page as a whole.

Custom resources are gone as a concept. They were always Terraform underneath, so 2.0 exposes Terraform directly through a Terraform registry. Existing Terraform knowledge and existing modules apply.

Git replaces the CLI as the way content moves

The CLI used to push, pull, test, and validate tracks. Pushing and pulling that way bypassed version control, so changes were not recorded and could be silently overwritten when someone else edited the same track in the UI.

In 2.0:

• Every lab is version controlled from the moment it is created, with nothing to configure
• GitHub integration connects a lab to your own repository, monorepos included, and syncs changes
• Branches let you develop a complete working version that can be played and shared before it merges
• Version tags mark a known good version so you can pin, compare, and roll back
• Conflicts resolve through a pull request instead of one side losing work
• The CLI still scaffolds a new lab from a template

You can work in your own editor with the tooling you already use, and the same lab is still editable in the UI. Edit mode makes it explicit whether someone is viewing a lab or changing it.

Check before you run

A validate command checks a lab’s definition, its resource references, and its task mappings before the lab ever runs. In V1 the equivalent was launching the whole lab and waiting to see what broke. Where something does still fail at runtime, the rebuilt logs give you more information and real controls to filter it.

Assets, files, and reuse

Assets and files are part of a lab’s structure natively, in code as well as in the UI, rather than being managed alongside it. A dedicated tab in the UI shows the same structure the code describes: assets, files, and scripts together.

Reuse works through modules: a versioned package containing any part of a lab, published to a registry and pulled into as many labs as you like. Modules replace sandbox presets and arrive at general availability rather than in Early Access.

Mapping from V1

In V1	In 2.0
YAML configuration	HCL definitions
Track level script	Exec resource
Challenge script	Task or condition script
Custom resource	Terraform, through a Terraform registry
CLI push and pull	Git, with GitHub integration
CLI validate	Validate command against the lab definition
Sandbox preset	Module, versioned in a registry
Random track id	Computed id, resource.lab.{slug}