Testsigma: the open source engine behind a codeless test automation platform

The README describes a product, the tree describes an engine

The mismatch is the first thing a reader notices. The README opens by describing a quality intelligence platform for teams where AI made developers faster, so more code ships and coverage gaps open faster than teams can close them. It then lists customer names, an office in San Francisco with engineering in Bangalore and Chennai, and investors, before describing a codeless automation product with two named assistants, Copilot and Atto, built in.

None of that is in the repository. The tree contains `action.js`, `agent-launcher/`, `agent/`, `automator/`, `deploy/`, `server/`, `ui/`, a `Dockerfile`, and the usual `CHANGELOG.md`, `CODE_OF_CONDUCT.md`, `CONTRIBUTING.md`, `SECURITY.md` and `LICENSE`. The GitHub language for the repository is Java, and `ui/` being a separate top-level directory is what an Angular front end looks like in a Java server project.

So there are two things being sold here. Testsigma Cloud is a hosted product with a signup link, a Discord, a YouTube channel and a newsletter. The repository is the self-hostable engine, and the README is candid about that too: it offers a one-click deployment on Testsigma Cloud plus exactly two other options, a Docker setup and a downloadable package, both documented off the repository on testsigma.com.

That distinction matters for anyone deciding what to run themselves. The AI agents described in the README are a product feature list, and nothing in the tree shows how they are implemented.

Five named agents describe the intended shape of the platform

Even if the implementation is not visible, the agent names tell you how the vendor thinks test automation should decompose, and they are worth reading closely.

The Generator Agent creates test scenarios from requirements, UI or APIs, which is the step that replaces writing cases by hand. The Runner Agent executes tests across hundreds or thousands of parallel sessions. The Analyzer Agent diagnoses failures, highlights root causes and recommends fixes, which is the piece that turns a red build into something actionable. The Healer or Maintenance Agent detects UI changes and adapts to them automatically, which is the feature aimed squarely at the cost of maintaining selectors. The Optimizer Agent suggests pruning, prioritisation and coverage improvements.

Around those sit the parts that are ordinary: cross-platform support for web, mobile on iOS and Android, APIs, desktop and ERP systems; reporting with dashboards, traceability and metrics; CI/CD integrations with Jenkins, GitHub Actions, GitLab CI and Azure DevOps; and role-based access with version control and audit logs.

The README also describes an add-on system. Add-ons are custom extensions built and shared through a Testsigma Add-ons Marketplace for actions the built-in set cannot automate, and there is an SDK for writing your own. Types listed include custom actions, with the README acknowledging that some applications need actions specific to them. Built-in actions are described as plain English, which is the whole premise of a codeless layer.

The claims that deserve scepticism are the numeric ones: 10X faster test writing and 90% less maintenance time. Both are vendor figures with no methodology in the repository.

Release tags from 2023 against a branch pushed in 2026

There are three releases on record and all three are old. `v2.9.1` on 2023-03-24 fixed bugs in test step creation with the disable step option and in if-else conditions. `v3.0.0` on 2023-06-24 was a dependency upgrade release: Selenium 3 to Selenium 4 at version 4.8.2, Appium 1 to Appium 2, and Grid 4, described as being for the Selenium automation crowd.

`v3.0.1` on 2023-08-24 is the most technically specific entry and the one that dates the engine. Tests had stopped running locally on Chrome 116 and later because the chromedriver team stopped publishing releases through their traditional download repository after chromedriver 114. From 115 onwards, driver releases are only discoverable through the Chrome for Testing JSON endpoints, which broke the traditional automatic management path in WebDriverManager. The fix was to upgrade the version of webdrivermanager that manages driver versions.

Read together, the release history describes an open-source engine whose last tagged state predates the current Chrome driver distribution system. Against that, the repository records a last push on 2026-08-05 on a default branch named `dev` rather than `main`. Both facts are true, and they point in different directions. Tagged releases stopped in 2023; commits continued on an untagged branch afterwards.

There is also a `CHANGELOG.md` in the tree, which is where the project would record work that never got a tag. The three topics on the repository include the misspelling `selenuim`, a small but telling detail about how the topic list was maintained.

What the Dockerfile commits you to

The `Dockerfile` is the most concrete document in the repository and it settles several questions at once. It builds from `centos:7`, which reached end of life in 2024, and that is a fact about the image rather than an opinion about it.

FROM centos:7
WORKDIR /opt/app
RUN yum install -y nginx-1.20.1; yum clean all

It installs `openssl-devel`, `openssl`, `wget`, `zip`, `unzip`, `dnf` and `which`, then Java 11 via `dnf install --nodocs java-11-openjdk`. It creates `/opt/app/lib` and `/opt/app/ts_data`, copies `deploy/docker/nginx.conf` into place, and installs `deploy/docker/cacerts` into the JVM trust store at `/usr/lib/jvm/jre/lib/security/`.

The application artifacts it copies are revealing about the build order. `ui/dist/testsigma-angular` implies the Angular front end must be built before the image, and `server/target/testsigma-server.jar` and `server/target/lib/` are Maven output paths. So the Docker build does not compile anything; it assembles artifacts someone else produced.

The environment variables are the four settings you must supply. `IS_DOCKER_ENV=true` switches on container behaviour, `TS_DATA_DIR=/opt/app/ts_data` names the data directory, `TESTSIGMA_WEB_PORT` defaults to 443, and `TESTSIGMA_SERVER_PORT` defaults to 9090, with both exposed. `MYSQL_HOST_NAME` defaults to `mysql`, so an external database is expected, and the variable is passed through with shell-style substitution. The entrypoint is `/opt/app/entrypoint.sh`, which comes from `deploy/docker/`.

Apache-2.0 is the recorded license and a `LICENSE` file is present in the tree.

Where to start if you want to run it yourself

The practical path is the documented Docker setup at testsigma.com/docs/getting-started/setup/docker/, since the repository itself carries no run commands. The `deploy/` directory in the tree is where the pieces the Dockerfile expects live, including `deploy/docker/nginx.repo`, `deploy/docker/nginx.conf`, `deploy/docker/cacerts` and `deploy/docker/entrypoint.sh`, and the tree also has a `server/src/main/scripts/posix/start.sh`.

For someone reading the code rather than running it, `automator/` and `agent-launcher/` are the two directories that answer the question the README leaves open. `automator/` is where test execution against browsers would live, and `agent-launcher/` is the one name in the tree that maps directly onto the agent story in the README. `server/` is the Java backend and `ui/` is the Angular front end, with `action.js` at the root likely tying the two together.

Two gaps are worth stating plainly. The repository does not document how the AI agents work, whether they are part of the open code or a service the hosted platform calls. And it does not document a supported upgrade path from the 2023 tagged releases, because there is no release after `v3.0.1` to upgrade to. The README's tutorial links are also worth a glance before committing, because the mobile ones appear to have their titles crossed: the link labelled to automate iOS apps points at the Android tutorials URL and the one labelled to automate Android apps points at the iOS URL.

Editorial conclusion

The gap between the README and the repository is the thing to understand before evaluating this. The README markets Testsigma Copilot, Atto, 30-plus integrations and enterprise customers, while the code you can read is a Java server, an Angular UI, an automator and an agent launcher, with the newest release tag dating from 2023 even though the default branch `dev` was pushed on 2026-08-05. If your interest is the codeless product, this repository is the engine underneath it and the hosted platform is where the features live. If your interest is self-hosting, the Dockerfile tells you what you are getting: CentOS 7, Java 11, nginx 1.20.1, a MySQL host variable, and ports 443 and 9090 exposed. Start with the `deploy/docker/` paths the Dockerfile copies from, and read the `automator/` and `agent-launcher/` directories, because those two decide whether the platform's promises are implemented in open code or delegated to a service.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. testsigmahq/testsigma on GitHub