Local containers

Run the supported Ubuntu subset as one fresh Docker container per run unit. This is the lightest local provider, but it is not a full virtual machine and does not support Windows tasks.

What runs where

The docker provider starts agentslastexam/ale-ubuntu22-docker. The image is an export of the ale-ubuntu22 VM userspace, including its applications, Python environment, Node runtime, CUA server, and filesystem paths. A virtual X display provides the desktop surface.

The task runs directly in the container and shares the host kernel. Use the QEMU/KVM VM provider when a complete guest operating system or Windows is required.

Host requirements

• Docker capable of running Linux amd64 containers. The supported profile targets rootless Docker on a Linux host.
• Enough disk for the published image, about 105 GB uncompressed and 42 GB compressed.
• Enough CPU and memory for each concurrent task container.
• Approved access to the gated task-data dataset on Hugging Face.

docker info
df -h .
uv sync --all-packages

Fetch task data once

The container image intentionally ships without task inputs or references. Request access to the ALE task-data archive, authenticate with Hugging Face, then run:

huggingface-cli login
scripts/fetch_task_data.sh

The script extracts the canonical data tree into ./task-data. Before the agent runs, ALE copies input/ and software/ into the container. It copies reference/ only after the agent finishes.

Use the shipped environment

environment: configs/environments/docker.yaml
tasks: selected_tasks/docker_support.txt

The environment uses task_data_source: local:task-data and output_path: local. Local task data and output both use host-side docker cp, avoiding per-file transfer through the CUA API.

Resource sizing

By default the provider translates each task card's GCE machineType into Docker CPU and memory limits. The schema also accepts explicit vm.vcpus and vm.memory_gb values. Set docker.cpus or docker.memory in a copied environment profile to impose a provider-level cap.

Output options

The default local path copies produced files into the run directory. GCS output is also supported when gcs_sa_key and a gs:// output path are configured. See Choose where task output goes.

Current limits

• Linux tasks only. Windows and GPU snapshots are not mapped.
• The sandbox shares the host kernel and is not VM-isolated.
• Six Linux tasks are excluded because they require another container runtime inside the sandbox: four use Docker, and two use Apptainer or Singularity GUI bundles.
• The shipped profile intentionally remains a simple rootless-Docker path. Use the QEMU/KVM VM provider for those nested-runtime tasks so Docker, Apptainer, or Singularity runs inside a complete Ubuntu guest.
• Opt-in privileged DinD hooks remain available for custom development setups, but they are not part of the supported default task list and can add substantial I/O at high concurrency.