Launching Your Build
With your VLANs configured, machines placed, and plugins attached, the canvas design is done. The next step is to launch a build, which turns the blueprint into real virtual machines.
Lab Time
Section titled “Lab Time”Designing a canvas and its curriculum is free. A build runs on lab hardware, so Launch Build needs lab time: VM hours from a Lab plan or hour pack, or a booked event. See VM Hours and Lab Plans.
Without lab time, a Limited Rogue Architect bar sits at the top of the canvas. You can keep designing. Clicking the bar or Launch Build opens Get VM hours, which lists your options.
If your VM hours run out while a build is up, the build is saved and powered off, and a VM hours ran out notice appears with Turn back on. While your Lab plan is active, the build stays saved until you have hours again. Otherwise it’s removed if it stays off, 72 hours after it stopped or on the date the notice shows. Your canvas design is kept either way.
Pre-Checks
Section titled “Pre-Checks”When you click Launch Build in the top-right corner of the canvas, the system runs pre-checks on your canvas configuration. They look for problems such as:
- Missing required plugin parameters
- Missing firewall rules between connected VLANs
- Configuration conflicts
Any warnings appear in a modal. They are advisory and won’t block your build, but review them before you continue.
The Pre-Check step of Launch Build. The four steps are shown at the top (Pre-Check → Review → Configure → Build), and every validation is listed below. Green checks mean you can continue.
For a new build, the last row is Checking lab funding. Like a deployment, a build takes a seat in your deployment pool and needs VM hours from one of your funding sources. The result appears under the list, and Continue stays disabled until the funding check passes. Redeploying an existing build skips this check.
If your team’s storage is full, the build can’t start. The check shows a Manage storage button that opens the Storage page, where you can free up space.
Build Configuration
Section titled “Build Configuration”After the pre-checks, the build configuration dialog opens with three options:
The build configuration dialog. Before the build starts, you set error handling, log verbosity, and how often snapshots are taken.
Continue on Error
Section titled “Continue on Error”The deployment keeps going when a plugin fails. You can publish a build with errors for interim testing, though we don’t recommend it. This option helps during development, when you want to see which plugins succeed and which need work instead of stopping at the first failure.
Verbose Logging
Section titled “Verbose Logging”Writes full Ansible output for every step. Turn it on when you’re tracking down a hard-to-find bug. The build logs become far more detailed and much larger.
Snapshot Interval
Section titled “Snapshot Interval”Adds checkpoints throughout the build. If you change a parameter and click Redeploy Build at the lower right of the canvas while the build is still deploying, the build resumes from the last snapshot instead of starting over.
Options:
- 45 minutes (default)
- 30 minutes
- 15 minutes: the most frequent option, with the most recovery safety
- Custom: any interval from 1 to 120 minutes
More frequent snapshots mean you lose less work when you recover from a failure, but they add time to the build.
Starting the Build
Section titled “Starting the Build”Starting the build switches the Architect GUI into building mode. The canvas updates in real time as VMs are cloned, powered on, and configured step by step by their plugin sequences.
Click Launch Build in the configuration dialog to begin. The system will:
- Clone infrastructure VMs (Network Router, APT Mirror, File Share)
- Clone your scenario VMs from their base templates
- Power on all infrastructure
- Power on your VMs
- Run plugins in order on the platform’s play workers