AngusTester: A YAML Test Language With a Documentation-Only Repository
AI-native software testing platform — one YAML test language covering API, Web, mobile, messaging, data, and LLM scenarios. Self-hostable.
At a glance
- What is it?
- AngusTester promises one declarative test language for API, Web, mobile, messaging, data and LLM scenarios, delivered as a self-hosted Docker stack. The catch is that the GitHub repository hosts documentation only, and the free Community Edition ships API and basic performance testing without the plugin families.
- Who is it for?
- Adopt AngusTester Community if you need API and basic performance testing under a single YAML format, you can run Docker Compose on at least 2 cores and 4 GB, and you accept that Web, mobile, messaging and LLM plugins sit behind the paid tiers. Do not adopt it if you need to read, patch or vendor the source, because this repository holds documentation only and the code arrives inside the downloaded zip.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 16 days ago.
- What is it written in?
- GitHub does not report a main language for this repository.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem AngusTester Targets: Test Tool Sprawl
Most QA stacks accumulate tools rather than choose them. A team ends up with one runner for HTTP assertions, a browser driver for UI flows, a separate harness for load, and something else again for message queues. Each has its own config format, its own reporting, and its own notion of what a passing run means. AngusTester's stated goal is to collapse that into one declarative language, AngusScript YAML, executed by a single engine. The README describes the product as replacing "tool sprawl and code-script barriers" with one test language that covers API, Web, mobile, messaging, data and LLM scenarios.
The audience is QA and platform engineers who write tests but do not want to write Java, JavaScript or Python to do it. The README is explicit that AngusScript declares requests, assertions and extractors without scripting. That is a real constraint as much as a feature: teams whose tests depend on custom logic, generated payloads or non-trivial state machines will hit the edge of a declarative format quickly. The second audience is organisations that cannot send test traffic to a hosted service, which is why the Community Edition is distributed as a self-hosted Docker stack rather than a cloud endpoint.
One Engine, Four Asset Types, and a Plugin Boundary
The architecture described in the README has two layers. The first is the asset model: plans, cases, scripts and reports. A plan scopes a testing effort, cases describe what is checked, scripts attach executable YAML to those cases, and reports come out the other end. Automated runs feed results into release decisions, which is where the report gating feature lives. That gating is listed as a paid-tier capability, so the free edition produces reports without the policy layer that blocks a release on them.
The second layer is the engine itself, extended through plugins. The README names protocol, Web, mobile and LLM plugins as separate modules that plug into the same execution model. This is the design decision worth noting: the single-engine claim is really a single-engine-plus-plugins claim, and the free Community Edition ships API and basic performance testing only. According to the comparison table, Web, mobile, messaging and LLM plugins, report gating, Testing Copilot and MCP are not included in Community. So the breadth advertised at the top of the README is largely a paid-tier property.
Performance testing is handled by multi-thread concurrency with ramp-up load, SLA threshold checks and live metrics. The README does not describe the load generator's internals, so how it distributes threads across execution nodes is not something the supplied material answers.
Installation: Four Commands and One Mandatory Extra Node
The README gives a four-command quickstart. Download the Community zip, unzip it, copy the environment template, and bring up the stack with the MySQL profile:
curl -LO https://repo.anguskit.com/raw/raw-public/AngusKit/tester/AngusTester-Community-2.0.0.zip unzip AngusTester-Community-2.0.0.zip cd AngusTester-2.0.0/docker cp env.example .env docker compose --profile mysql up -d
Hardware minimums are 2 cores and 4 GB, with 4 cores and 8 GB recommended. Disk needs 40 GB before execution logs and plugins are counted, which is the number that will surprise people running this on a laptop. After install, AngusGM listens on port 8801 for sign-in and AngusTester on 8807. The zip bundles both products, so even a team that only wants the tester gets the management component alongside it.
The constraint that matters most is stated plainly: the server does not execute scripts. You must attach at least one execution node, an Agent, before any job runs. A successful `docker compose up` therefore proves almost nothing about whether your tests will execute. The README points to the full installation guide for host ZIP, Kubernetes and Helm, TLS, upgrades and execution node setup, which is where the Agent configuration actually lives.
The Repository Is Documentation, Not Source
This is the fact that should shape any evaluation. The README states that the repository hosts documentation only, and that earlier revisions contained application source before distribution moved to AngusKit's packaging pipeline. The Community Edition source is GPL-3.0, but it is distributed with each installation package rather than through GitHub. The repository does not accept source code pull requests, and its Issues are scoped to documentation feedback and install troubleshooting.
For an engineer deciding whether to adopt, that changes the workflow. You cannot read the engine before downloading it. You cannot diff versions on GitHub, follow a commit history, or check whether a bug you hit was fixed on main. You also cannot fork and maintain a patched build in the ordinary way, because the upstream you would track is a zip on a vendor repository, not a git remote. The GPL-3.0 licence on the Community source still grants the freedoms that licence grants, but exercising them starts with unpacking the archive.
The practical consequence is that the download is the audit. Teams with procurement or security review processes that require reading source before deployment will need to run that review against the extracted package, and they should budget time for it rather than treating the GitHub page as the artifact under review.
Where the Community Edition Stops
The free tier caps users at 10, test projects at 20, and test concurrency at 1,000. Those are workable numbers for a single team and restrictive for an organisation standardising across departments. The feature gap is sharper than the numeric caps. If your testing need is Web UI, mobile, messaging or LLM scenarios, the Community Edition does not cover it, because those plugins are paid-tier only. The product's headline claim, testing everything through one language, describes the Team, Enterprise and SaaS editions rather than the free one.
There is a second limitation in the distributed model itself. Because the source arrives inside the installation package, upgrade mechanics are not visible from the repository. The README references an upgrades section in the full installation guide, but the supplied material contains no release notes and no retrieved releases, so there is no way to judge how often the Community package is rebuilt, whether schema changes to AngusScript YAML land between versions, or what migration looks like. That is a genuine unknown, not a criticism.
AngusTester is also the wrong tool if your tests are fundamentally code. Declarative YAML is a poor fit for suites that need loops over dynamically generated data, complex setup teardown graphs, or assertions computed from external state. The README frames the absence of scripting as the benefit. For some suites it is a ceiling.
How It Differs From Postman, k6 and Playwright
The closest comparison is a collection runner plus a load generator plus a browser automation library, stitched together by CI. Postman covers API testing with a GUI and its own script format, k6 covers load testing in JavaScript, and Playwright covers browser flows in TypeScript. Each is strong in its lane, and each requires its own configuration and produces its own reporting format.
AngusTester's difference is the unification of the asset model rather than the execution technology. Plans, cases, scripts and reports share one surface, and the same YAML is meant to drive functional and performance runs. That is a real structural difference from gluing three tools together. The cost is that you inherit the vendor's plugin boundary: the free edition gives you API and basic performance, so a team that needs browser coverage is comparing a paid AngusTester tier against a free Playwright install. That comparison usually favours Playwright unless the unified reporting and gating are worth the licence.
The other difference is deployment. Postman and Playwright run on a developer machine with no server. AngusTester requires a Docker host, a MySQL profile, and at least one Agent node before anything executes. That is more operational surface, and it buys you centralised assets and shared reports.
Licence, Maintenance and What to Verify
Licensing splits across three products. The documentation in this repository is GPL-3.0, matching the Community Edition source it describes. The Community Edition product source is also GPL-3.0 and ships with each installation package. Team and Enterprise editions are proprietary under the XCan Business License, Version 1.0, available only through a paid subscription. If you deploy the Community Edition inside a commercial organisation, the GPL-3.0 obligations attach to the source you received. This is not legal advice, and the interaction between the free edition and the paid proprietary editions is worth a lawyer's read if you plan to redistribute anything.
Maintenance cost has two components. The infrastructure side is a Docker Compose stack with MySQL, an Agent node, and 40 GB of disk before logs and plugins. That is a service to keep alive, not a binary to install. The upgrade side is harder to estimate from the supplied material, because the repository carries no releases and no changelog. The last push date on the repository is 2026-08-31, so the documentation is being maintained, but that says nothing about the cadence of the Community package itself.
What to verify before adopting: download the 2.0.0 zip and confirm the bundled GPL-3.0 source is complete enough for your review process. Stand up the stack and attach an Agent, since a running server without one executes nothing. Then check the pricing page against the exact protocols you test, because the plugin boundary, not the user or concurrency cap, is what decides whether the free edition fits.
Editorial conclusion
Adopt AngusTester Community if you need API and basic performance testing under a single YAML format, you can run Docker Compose on at least 2 cores and 4 GB, and you accept that Web, mobile, messaging and LLM plugins sit behind the paid tiers. Do not adopt it if you need to read, patch or vendor the source, because this repository holds documentation only and the code arrives inside the downloaded zip. Before committing, download the 2.0.0 Community package, inspect the GPL-3.0 source bundled with it, and confirm the plugin matrix on the pricing page matches the protocols you actually test.
Community notes