Start in the project directory created by aptl lab init. If you do not have
one yet, follow Installation.
aptl lab start runs intentionally vulnerable containers and agent tools on
the selected Docker engine. Use it for supervised work on a dedicated,
rebuildable machine. Do not treat an everyday workstation containing unrelated
credentials or workloads as disposable lab infrastructure.
The start summary and aptl lab info report the selected Docker transport and
observed host boundary. native-docker means the selected local engine's kernel
matched the CLI host at observation time; docker-vm-unverified describes a VM
runtime without a containment qualification. Remote, changed, or unreadable
endpoints report a limited or unknown result. The label does not prove that
ports, devices, egress, or other host resources are contained. See the
tested profiles and limits.
For agent-driven or multi-user work on Linux/KVM, the disposable
aptl seat start path provides a
stronger VM boundary around Docker and the lab. Neither containers nor a VM
are an absolute sandbox. Keep the host kernel and hypervisor current and
control the surrounding network.
Run the read-only prerequisite check from the project directory:
aptl doctorIt checks the project configuration, the host tools that aptl lab start
runs, and the Docker engine the project selects. For that engine it checks that
it answers, runs rootful without userns-remap, provides cgroup v2 with Docker
Engine 28.0 or newer, and has the Compose and Buildx plugins. It warns when
Compose is older than 2.24.4, which lab start requires for a scenario that
consumes generated certificates or volumes. It reports the engine memory but
does not check it, because no scenario declares a memory need yet. On a native
Linux engine it also checks vm.max_map_count. For a remote engine, or one
whose host it cannot identify, it warns instead and prints the setting to apply
on the host that runs that engine. Each failed check prints its fix. The command changes nothing on the
host, in the project, or in the Docker engine. It exits with status 0 when no
check failed and 1 when at least one did, so a script can run it before
aptl lab start.
List the validated scenarios supplied by the installed environment pack:
aptl lab scenariosFor the standard released lab, select the techvault catalog identity. Use
the identifiers printed by the command rather than a copied list: availability
and qualification belong to the installed pack version.
An explicit --scenario-path is a development surface for a project-local SDL
file. It is not the normal released-package path.
Start the selected scenario:
aptl lab start --scenario techvaultStartup validates the project and scenario, prepares keys and certificates, realizes the requested topology, starts its containers and MCP artifacts, and waits for required readiness checks. Read the final structured result. A container shown as running is not by itself proof that the scenario is ready.
Verify the current state and print runtime-derived access information:
aptl lab status
aptl lab infoIf startup reports degraded or failed, follow its named diagnostic before
starting an exercise. The troubleshooting guide
shows the safe inspection and recovery commands.
The realized scenario determines which services exist. Discover them at runtime:
aptl container list
aptl lab infoaptl lab info reports current URLs, remapped host ports, usernames, and the
project-local locations of credentials. For a remote Docker daemon it reports
ports on the remote host rather than making a local localhost URL claim.
Read the values from your own project;
do not use a password or port copied from documentation. Wazuh values such as
INDEXER_USERNAME and INDEXER_PASSWORD are scenario credentials, not APTL
control-plane logins.
Open the Wazuh Dashboard or another realized service at the URL printed by
aptl lab info. For a shell in a listed container, use:
aptl container shell aptl-victimOnly use a container name that appears in aptl container list for the
selected scenario. LilRAE refuses a shell on aptl-kali while session
capture runs, as it does on TechVault; see
Kali Red Team Container.
Generate activity only inside the authorized lab range. A simple local event from a realized victim shell is enough to verify the telemetry path:
logger "APTL first-lab test event"
exitUse the lab walkthrough for a complete guided exercise. It pairs activity with observations and keeps target selection inside the realized scenario. Do not copy lab commands to systems outside the range.
Use the SOC interfaces reported by aptl lab info to inspect alerts and
service data. APTL also records scenario runs in the project-local run store:
aptl runs list
aptl runs show <run-id>
aptl runs path <run-id>The commands distinguish runtime health, service observations, and archived
run evidence. Use aptl runs export-bundle <run-id> when you need a portable,
self-describing evidence bundle; see the
evidence bundle reference.
Use normal, project-scoped teardown at the end of a session:
aptl lab stopThis stops the realized lab while preserving its Docker volumes. To return the project to a clean state, reset it:
aptl lab resetReset removes the project's containers, networks, and volumes, then finishes
any pending host-side cleanup, so the next aptl lab start begins clean. It
asks for confirmation and destroys lab indexes, tool data, and other
volume-backed state. Beyond the host state that a pending cleanup record
names, it keeps aptl.json, .env, SSH keys, certificates, and run records,
and it does not remove unrelated Docker resources. Running it again is safe: it
reports what it found and retries any cleanup that failed.
aptl lab stop -v performs the same teardown.
aptl kill is an emergency process-control command, not normal teardown or a
credential reset. Do not use docker system prune for APTL cleanup; it is
daemon-wide rather than project-scoped.