Running TestZeus Hercules with docker#
| Author | Juha-Matti Hietala |
| Last Updated | 30.07.2025 |
| Status | In Progress |
Requirements#
* Ubuntu 24.04 * Docker installed
Introduction#
This guide is taken pretty much straight from the official TestZeus Hercules documentation with a few additions from myself, as I couldn't get it to running properly. I have mentioned in the text to what point I managed to get and the official guide will continue further.
QEMU#
TestZeus Hercules docker image supports arm64 processor architecture and the Ubuntu 24.04 architecture uses amd64. When trying to run the image there will be and error message that the image's architecture is not supported. A way to fix this I found was to emulate the amr64 processor architecture with QEMU. From wikipedia: "QEMU is a free and open-source hypervisor. It emulates the machine’s processor through dynamic binary translation and provides a set of different hardware and device models for the machine, enabling it to run a variety of guest operating systems."
There are different ways to try to fix this problem, like building the docker image again with the right architecture, but due to time constraints I chose emulation as it seemed the fastest solution, not necessary the best.
Installing QEMU#
First look what platforms your docked driver supports:
You should see something like this:
NAME/NODE DRIVER/ENDPOINT STATUS PLATFORMS
default * docker
default default running linux/amd64, linux/386
NAME/NODE DRIVER/ENDPOINT STATUS PLATFORMS
default docker
default default running linux/amd64, linux/386, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x, linux/arm/v7, linux/arm/v6
Using Docker#
- Pull the image:
Non-Bulk Mode (Default)#
-
Prepare your local directory structure:
-
Run the container with environment file and specify platform to linux/arm64, otherwise it tries to run it with amd64. Example .env file a step further below. Create the .env file to where you run the command:
Example .env file, change accordingly#
LLM_MODEL_NAME=PUT YOUR MODEL NAME HERE, for example: gpt-4o, gpt-4o
LLM_MODEL_API_KEY=PUT YOUR MODEL API KEY HERE
# LLM_MODEL_BASE_URL=IF YOU ARE USING OpenAI, remove this line, otherwise add the base URL, for example: https://api.groq.com/openai/v1
# If you want to use json file for config (see sample agents_llm_config.json and the Readme)
# AGENTS_LLM_CONFIG_FILE=agents_llm_config.json
# AGENTS_LLM_CONFIG_FILE_REF_KEY=The key for the config stanza to use from the file
# PROJECT_SOURCE_ROOT=folder where to save data.
# optional
# CDP_ENDPOINT_URL=ws://localhost:9222/devtools/browser/b12de40a-fc1c-4ebb-81d9-046e901f376d
TOKENIZERS_PARALLELISM=false
MODE=prod
HEADLESS=false
RECORD_VIDEO=false
TAKE_SCREENSHOTS=true
BROWSER_TYPE=chromium
CAPTURE_NETWORK=true
HF_HOME=./.cache
# select the device from this file https://github.com/microsoft/playwright/blob/main/packages/playwright-core/src/server/deviceDescriptorsSource.json
# RUN_DEVICE="iPhone 15 Pro Max"
# GEO_API_KEY=
# GEO_PROVIDER=maps_co
# LOAD_EXTRA_TOOLS=true
# EXECUTE_BULK=true
Important Note: Docker runs are always in headless mode (no visible browser). To connect to a visible browser, you'll need to use the CDP_ENDPOINT_URL environment variable to connect to an external browser instance, more on that further down.
This is how far I got successfully. Now the image runs but for some reason seems to try to open a browser and gives an error message, even though the image should run in headless mode by default. The .env file has HEADLESS=true also but doesn't help. Tried external browser, which is explained more further down, but ran out of time to get it working, had timeout on trying to connect. Might be the solution if worked on further.
Bulk Mode in Docker#
-
Set up environment file (
.env): -
Prepare multiple test directories locally:
-
Run the container:
Expected outcome:
- Tests execute sequentially in headless mode
- Each test directory processed independently
- Results stored in respective test directories under opt/tests/
Connecting to External Browser (Docker Mode)#
To run tests with a visible browser while using Docker:
- Set up a Chrome instance with remote debugging enabled
- Add to your
.envfile:
This allows Hercules running in Docker to connect to an external browser instance, enabling visible test execution even when running in a container.
Browser Cookie Configuration#
To set cookies for the browser context, you can use the BROWSER_COOKIES environment variable:
export BROWSER_COOKIES='[{"name": "session", "value": "123456", "domain": "example.com", "path": "/", "httpOnly": true, "secure": true}]'
The cookies must be provided as a JSON array of cookie objects with the following properties:
- name: Cookie name (required)
- value: Cookie value (required)
- domain: Cookie domain (required)
- path: Cookie path (defaults to "/")
- httpOnly: Whether the cookie is HTTP-only (defaults to false)
- secure: Whether the cookie is secure (defaults to false)
- expires: Cookie expiration time in seconds since epoch (defaults to -1, session cookie)
Cookies are added to the browser context after it's created, ensuring compatibility with all browser types (Chromium, Firefox, WebKit).
Remote Browser Testing Platforms#
Hercules supports running tests on various remote browser platforms using the CDP (Chrome DevTools Protocol) endpoint URL. Here's how to configure different providers:
BrowserStack#
-
Set up your credentials:
-
Generate CDP URL:
Note: Video recording is not supported with BrowserStack as it uses the connect API.
LambdaTest#
-
Set up your credentials:
-
Generate CDP URL:
Note: Video recording is not supported with LambdaTest as it uses the connect API.
BrowserBase#
- Set the CDP URL directly:
BrowserBase supports connect_over_cdp, so video recording will work on the test execution host.
AnchorBrowser#
- Set the CDP URL directly:
AnchorBrowser supports connect_over_cdp, so video recording will work on the test execution host.
Important Notes About Remote Browser Testing#
- When using CDP_ENDPOINT_URL, Hercules will connect to the remote browser instance instead of launching a local browser.
- Video recording capabilities depend on the platform:
- Platforms using Playwright's connect API (BrowserStack, LambdaTest) do not support video recording
- Platforms using connect_over_cdp (BrowserBase, AnchorBrowser) support video recording on the test execution host
- Each platform may have different capabilities and configurations available through their respective helper scripts
- Remote browser testing is particularly useful when running tests in Docker containers or CI/CD pipelines
Viewing Results#
After test execution, results can be found in several locations:
-
Test Reports
- HTML Report:
opt/output/run_<timestamp>/test.feature_result.html - XML Report:
opt/output/run_<timestamp>/test.feature_result.xml
- HTML Report:
-
Execution Logs
- Agent Thoughts:
opt/log_files/<scenario_name>/run_<timestamp>/agent_inner_thoughts.json - Communication Logs:
opt/log_files/<scenario_name>/run_<timestamp>/log_between_sender*.json
- Agent Thoughts:
-
Execution Artifacts
- Screenshots:
opt/proofs/<scenario_name>/run_<timestamp>/screenshots/ - Videos:
opt/proofs/<scenario_name>/run_<timestamp>/videos/ - Network Logs:
opt/proofs/<scenario_name>/run_<timestamp>/network_logs.json
- Screenshots: