HydraLab: a self-hosted center-agent test cloud for phones, browsers and Windows apps

The problem HydraLab addresses: scattered devices with no shared scheduler

Most teams that write mobile or cross-platform UI tests end up with the same shape of problem. There are phones and laptops somewhere in the office, each one has a different OS version, and running a suite means someone physically plugs in a device, waits, and unplugs it. HydraLab is aimed at that situation. The README describes it as a framework that helps you "build a cloud-testing platform utilizing the test devices/machines in hand", which is a precise statement of scope: it does not supply devices, it supplies the scheduling, registration and result layer on top of devices you already have. The intended user is a test or platform engineer inside an organization that has hardware but no central way to book it, dispatch a run to it, and collect artifacts afterward. The listed capabilities are device management under a center-agent design, test task management with result visualization, and case-free automation in the form of Monkey tests and a smart exploratory mode. That last item matters for teams whose manual testers do not write scripts at all.

Center and agent: how the distributed design is put together

The architecture named in the README is a center-agent split. The center is a Java Spring Boot service, described in the build instructions as "a runnable Jar", and it is the piece that serves the web portal and holds task state. Agents are separate processes that run on the machines with devices attached. An agent authenticates with an ID and a secret, both of which are generated from the portal: the source-build instructions tell you to visit http://localhost:9886/portal/index.html#/auth to generate a new agent ID and agent secret. That pair is then written into the agent's application.yml, copied from agent/application-sample.yml. The README names the three values to update as YOUR_AGENT_NAME, YOUR_REGISTERED_AGENT_ID and YOUR_REGISTERED_AGENT_SECRET. The data flow implied by the portal is straightforward: an agent registers itself against the center, the center lists its connected devices on the front end, a test task is created in the Runner tab, the center dispatches it to an agent that owns a suitable device, and results land in the Task tab. Storage is pluggable. By default the README says Hydra Lab uses the local file system, and it also states that the project has "native, consistent, and validated support" for Azure Blob Storage, which it recommends. Local storage is fine for a demo and awkward for a multi-agent deployment, because artifacts live on whichever machine ran the job.

Getting a working instance: the Uber container versus a source build

There are two paths and they are not equivalent. The fast one is the Uber Docker image, which the README describes as an out-of-box experience containing both a center instance and an agent instance. You pull ghcr.io/microsoft/hydra-lab-uber:latest, then run docker run -p 9886:9886 --name=hydra-lab ghcr.io/microsoft/hydra-lab-uber:latest, and open http://localhost:9886/portal/index.html#/. The README flags the pull as necessary, warning that skipping it can leave you on a locally cached image tagged latest. The important caveat is stated plainly: for Android the Uber image only supports Espresso/Instrumentation tests. If you want the rest of the matrix you are on the source path. That path requires JDK11, NPM and Android SDK platform-tools. You build the React front end first with cd react, npm ci, npm run pub, then return to the root and run gradlew :center:bootJar, then java -jar center/build/libs/center.jar. On the agent side you build the Android client with ./gradlew assembleDebug from android_client, copy app-debug.apk into common/src/main/resources/record_release.apk, copy agent/application-sample.yml to application.yml, edit the three agent keys, run gradlew :agent:bootJar and finally java -jar agent/build/libs/agent.jar. The README also documents a Node/OpenSSL failure on the front-end build, error:0308010C:digital envelope routines::unsupported, with the fix being to set NODE_OPTIONS to --openssl-legacy-provider and restart the terminal. Agents themselves run on Windows, macOS and Linux, with a Docker option documented in agent/README.md.

The framework matrix is the real adoption constraint

HydraLab does not abstract your tests away from their runner. The README's matrix is explicit about what is supported where. Android accepts Appium (Java), Espresso, Maestro and the Python Runner. iOS accepts Appium, XCTest, Maestro and Python Runner. Windows and Web (Browser) accept Appium and the Python Runner only. There is no XCTest column entry for Android or Windows, and no Espresso entry outside Android. Read that as a boundary rather than a gap: the project is a dispatcher for existing frameworks, so if your suite is written against something absent from the matrix, HydraLab cannot run it without you writing an integration. The Python Runner column is the escape hatch, since it appears on all four platforms, but the README does not describe its contract in the material available here, so treat it as something to investigate in the wiki before committing. The case-free modes, Monkey test and smart exploratory test, sit outside the matrix entirely and are described as automation without test cases, which is a different kind of coverage from a scripted suite.

Where HydraLab is the wrong tool

The clearest failure mode is expecting the Uber image to be the product. It is a demo container with one center, one agent and Espresso-only Android support. A team that pulls it, likes what they see, and then tries to onboard an iOS XCTest suite will find that the image does not carry the path they need, and that the source build demands JDK11, NPM and Android platform-tools on the build host. The second limitation is operational. Because the default storage is the local file system, a center that dispatches to several agents accumulates results in several places unless Azure Blob Storage is configured. The README recommends Blob Storage but does not present local storage as a supported multi-host configuration. Third, there is no managed layer at all: no hosted control plane, no vendor handling agent upgrades for you. The repository shows no releases retrieved in the material supplied, so there is no published version number to pin against. Anyone who needs a supported, versioned artifact with a changelog should confirm what the release page actually contains before planning around it. Finally, HydraLab assumes you have hardware. If your problem is that you own no devices, this project does not solve it.

How it compares with a hosted device farm

The obvious alternative is a commercial device farm, where you rent time on real devices through a vendor's API and the vendor owns the hardware, the OS images and the scaling. The difference in approach is not cosmetic. A hosted farm gives you capacity on demand and someone else's maintenance burden, at the cost of a per-minute bill, your test artifacts leaving your network, and a device inventory you do not control. HydraLab inverts all three: zero marginal cost per run once the hardware exists, artifacts on your own storage, and a device list that is exactly the phones on your desk. It also inverts the failure modes. With a farm, a broken device is the vendor's problem. With HydraLab, an agent that stops reporting is yours, and the center's device list is only as accurate as the agents that maintain it. The choice is really about whether your bottleneck is money or hardware. Teams with a drawer full of test phones and a fixed budget get more from HydraLab. Teams with no hardware and a deadline get more from renting.

Maintenance cost, licensing and what to check before you commit

HydraLab is MIT licensed, which permits commercial and closed-source use and modification; the repository carries an MIT badge and the license field confirms it. That is permissive, and it also means no warranty and no support obligation from Microsoft. The practical maintenance load comes from the dependency stack the README pins: Spring Boot v2.2.5 and Appium v8.0.0. Those are the versions shown in the badges, and they are what the source build expects, so an upgrade of either is a project-level change rather than a routine bump. The agent fleet is the other recurring cost. Every machine running an agent needs its application.yml kept in step with the center it registers against, and the agent ID and secret are issued per agent from the portal, so rotating them means touching each host. Upgrades are not described as automatic anywhere in the material. Before adopting, confirm three things: that the Uber image's Espresso-only Android path is enough for a first demonstration, that the framework matrix covers every suite you intend to migrate, and that the release page actually publishes artifacts, since none were retrieved here. If all three hold, the first concrete step is to generate an agent ID and secret at /portal/index.html#/auth and register one agent against a center you started yourself.

Editorial conclusion

Adopt HydraLab if you have spare Android, iOS, Windows or browser machines and your tests already run under Appium, Espresso, XCTest, Maestro or a Python runner, because the center-agent split lets you add capacity by starting another agent rather than rebuilding the platform. Do not adopt it if you need a managed device cloud, if your suite is built on a framework outside the matrix, or if you cannot run JDK11, NPM and Android SDK platform-tools on a build host. Verify first that the Uber image's Espresso-only limit is acceptable for your first demo, and that the agent YAML registers cleanly against a center instance you started yourself.

Official sources

1. Issues
2. License: MIT
3. microsoft/HydraLab on GitHub
4. README