AI-native BDD test automation

Describe what it does.
Gheetah writes the tests.

Tell a model what your application is and it generates the project, writes the scenarios and runs them — with no step definitions to implement and no code to maintain. Record a session in the browser and it becomes a scenario. Link one to a JIRA issue and the result finds its way back there on its own.

Open Gheetah See it write one

What the model is told once, and then applies to every scenario it writes for this project.

Codeless or written AI projects, or C#, Java and Playwright

Docker or your own machines Containers, agents, real devices

Five data stores JSON, SQLite, PostgreSQL, MongoDB, Cosmos

Runs on your infrastructure Self-hosted, nothing leaves unless you send it

Codeless

A test suite that nobody had to implement

A codeless project has no step definitions and no build. You describe the application once, and from then on a scenario is a sentence: the model writes the Gherkin and Gheetah drives the browser or the device itself, on the same execution targets a written project uses.

✓

The project is a description

A name, what is being tested, the address it lives at, and anything the model should know — a login that must not be used, a page that is slow. That context is given to the model again for every scenario, so the tests stay about your application rather than a generic one.

✓

Scenarios written from a topic

Ask for “a customer checks out with an expired card” and the model returns the Gherkin for it. Read it, edit it, keep it — it is an ordinary scenario from that point on, with the same reports and the same run history as one somebody typed.

✓

Recorded, not written

Open the application in a recording session, do the thing you want tested, and Gheetah turns what you did into a scenario. It is the fastest way to capture a bug a tester just reproduced, and it needs nobody to know Gherkin.

✓

Any model, yours or hosted

OpenAI, Anthropic, Gemini, Azure OpenAI or a model on your own hardware through Ollama. What gets sent passes the redactor first, so a token a test happened to log does not reach the provider.

A codeless AI project open on its scenarios, with Generate Scenario ready to write the first one — The project opens on its scenarios. Generate Scenario asks the model for the first one.

Describing what a codeless project tests — the description the model is given as context — The description is not decoration: it is the context every generated scenario is written against.

JIRA

The issue knows whether its test passed

Link a scenario to a JIRA issue and the run reports itself back: a comment with the per-step breakdown, and a transition when you ask for one. Nobody copies a result into a ticket by hand.

✓

Run from the issue, not from Gheetah

The Atlassian Forge app puts the scenarios and their last results inside JIRA itself, so a tester who lives in the issue tracker can start a run and read the report without leaving it.

✓

Results that arrive by themselves

A merged pull request, a scheduled run, a pipeline calling the API — whichever started it, the linked issue gets the outcome, with the failing step named.

✓

As the person who is signed in

Gheetah calls JIRA with the signed-in user's authorisation rather than a shared service account, so what a comment says about who ran something is true.

And the rest of it

Your tests, running where they actually belong

Bring the C#, Java or Playwright project you already have — or let Gheetah write one that passes from the first run. Execute it on disposable Docker containers or on the machines that have what your tests need. Then read the report, compare it with the last twenty-five runs, and ask a model what changed.

Writing a Given step in the Gheetah editor, with the project's own step definitions offered in the suggestion list — The suggestion list is the project's own bindings, each naming the file it came from.

Getting a project in

Three ways in, one place to run them

Gheetah does not ask you to rewrite what you have. A repository it can reach, a zip from someone's laptop, or a project it writes for you — all three end up as a project whose scenarios can be run, edited and reported on.

Clone

From your repository

Connect GitHub, GitLab, Bitbucket or Azure DevOps once, with a token stored encrypted. The repositories that connection can see are then offered directly — nobody pastes credentials into a project form.

Upload

From an archive

For a project that lives somewhere Gheetah cannot reach. Upload the zip; it is unpacked into the project folder and treated exactly like a cloned one.

Generate

From a template that works

Choose the language, the test framework and the target. Gheetah writes the runner, the driver setup, the step library and a smoke scenario that passes offline — the first run is green before you write anything.

Generated projects

A project that compiles, not a skeleton

Every combination Gheetah offers is built and compiled before it ships, so a generated project is one you can run, not one you have to finish. Add HTTP or SQL step libraries at the same time, and point the build at a private registry if your packages do not come from the public feeds.

Language	Targets	Test frameworks
C#	Web, Desktop, Mobile	xUnit, NUnit, MSTest — with Reqnroll
Java	Web, Desktop, Mobile	JUnit 5, TestNG — with Cucumber
Playwright	Web	Playwright Test

Generating a project: name, language, test adapter, project type and optional API and database step libraries — Creating a C# web project with xUnit and both step libraries.

Execution

Run it where it belongs

A browser test wants a disposable container. A desktop application wants Windows. A mobile scenario wants the actual phone. Gheetah treats all three as execution targets and records which one a result came from.

Registering a Docker server: name, address, SSH port and user — Registering a Docker server — SSH, Docker, dependencies and runtimes, checked in order.

1

Docker servers

Registered over SSH. Gheetah verifies the connection, finds or installs Docker, installs what it needs and builds the runtime images on the server itself — so the machine that runs your tests is the machine that holds them. Readiness is remembered per runtime.

2

Your own machines

The GheetahAgent runs on Windows, macOS, Linux or in a container. It asks to join; an administrator approves it once. After that it appears beside the Docker servers, reporting its own availability.

3

Real devices

Device Hub attaches Android and iOS devices through node machines, drives them with Appium, and lets you take control of one from the browser when a mobile step needs investigating.

4

Policy, not guesswork

Docker-only, Docker-preferred, agent-only or local. Every run records the policy applied, the target chosen and why — so a result can always be traced back to where it ran.

Results

Know what the run means, not just whether it passed

Output while it happens, a step-by-step report when it finishes, and the runs before it kept for comparison. A failure is something to read, not something to reproduce before you can start.

Live output

The console of the run, streamed as it happens. A run that cannot start says why — no execution target, a build that failed — instead of spinning until someone gives up.

Step-by-step report

Every Given/When/Then with its outcome, duration and the error where one failed, rendered as a BDD report you can send by e-mail or post to Slack.

The last 25 runs

Every scenario keeps its recent runs by date, each opening its own report. Comparing today's failure with the last time it passed takes two clicks, on whichever data store you configured.

Analysis, on request

With a model registered, the history can be analysed as a whole: flakiness, recurring failures, duration trend, likely causes. The runs are redacted before they are sent — a token a test logged does not reach the provider.

Where it lands

Slack messages with the per-step breakdown, e-mailed reports, JIRA comments and transitions — each attached per run rather than configured globally and forgotten.

Codeless, when you want it

AI projects generate scenarios from a description and execute them without step definitions, using the same targets and producing the same reports as a written project.

Editor

Change the test where you read the failure

Every project opens in a full editor in the browser — the one Visual Studio Code is built on — with the project's own step definitions loaded into it. Writing a scenario offers the steps that exist, and Ctrl+Click on one opens the code behind it. Nothing is cloned, and nothing is installed.

✓

Steps that exist, offered as you type

Gheetah reads the bindings out of the project, so the suggestion list is this project's steps — each one saying which file and line it came from — not a generic Gherkin vocabulary. A scenario written here has somewhere to run.

✓

Straight to the code behind a step

Ctrl+Click a step, or Go to Step Definition, and the class that binds it opens at the line. It works the same in a project that arrived from your repository as in one Gheetah generated.

✓

A diff before you stand behind it

Every file that differs from the branch, side by side with the committed version. Saves carry the version you started from, so a file that moved underneath you is refused rather than silently overwritten.

✓

Review without a hosting account

Commit onto a branch, raise a pull request, comment on the lines, approve, merge — all kept by Gheetah itself. Attach GitHub, Azure DevOps or GitLab when you want the branch pushed there too.

✓

Commits that cannot carry a secret

Build output, package directories and environment files are never staged, and the content is scanned for tokens and keys before the commit is made. A commit that would carry one is refused with the reason.

The whole thing, recorded by the test suite: a new feature file, a step chosen from the project's own bindings, a save, a diff, a commit onto a branch, a pull request, a review and a merge.

Permissions assigned per group in Gheetah's administration — Permissions belong to groups, and the server checks them on every request.

Governance

Built for an installation with more than one team on it

Gheetah runs on your own infrastructure. What it stores, who may do what, and what was done are all things you can point at.

✓

Authorisation on the server

Permissions are granted to groups and enforced server-side on every request — including requests from a pipeline holding an API key, which gets exactly the permissions of its group.

✓

Your directory, your accounts

Local accounts, Azure AD, Google or any OpenID Connect provider. Directory groups map onto Gheetah's, so joining a team is what grants access.

✓

Your database

JSON files for an evaluation, SQLite for a single machine, PostgreSQL, MongoDB or Cosmos DB for a shared installation. Every feature works the same on all of them.

✓

An account of what happened

Sign-ins, projects, runs and setting changes are recorded with who and when, filtered and paged by the server, and pruned on a retention schedule you set.

Getting started

Installed in one sitting, with no second restart

Start the server and open it. A one-time token — printed to the console, so whoever can read the server can configure it — opens a wizard that asks six questions: how people sign in, where projects live, where data is stored, and what the permission groups are. Creating the first administrator signs you in with it. Nothing has to be restarted, and nothing has to be edited in a configuration file.

Open Gheetah Read the walkthrough

Choosing where Gheetah stores its data during the first installation — The data store is a decision about operations — every option supports every feature.

Pricing

Start free, scale when your team does

Community is free. Professional has transparent team pricing. Enterprise is an annual agreement tailored to the scale and operating requirements of your organisation.

Community

For evaluating Gheetah, and for a single small team.

^$0

free, no token needed

Up to 5 people, 3 projects
C#, Java and Playwright projects
Docker and agent execution
Single sign-on (Azure AD, Google)
AI scenario generation and codeless execution
Execution history, reports and AI analysis
The in-browser editor, with pull requests and review
JSON, SQLite or PostgreSQL

Start now

Professional

For a department: more people, and the integrations they already depend on.

^$249

per month

15 people and 10 projects
$19.99/month for one additional user or one additional project
CI/CD integrations
Private package feeds
Device Hub — register machines and the devices attached to them
More than one AI model provider
Everything in Community

Request a licence

Enterprise

For an installation the whole organisation runs on.

Custom

Tailored to your organisation

Annual enterprise agreement

Pricing is based on deployment scale, users, execution capacity and enterprise requirements.

Organisation-wide people and projects
JIRA Cloud integration and the Atlassian Forge app
API keys for pipeline access
Device Hub control — drive a device and run Maestro flows on it
Self-hosted MCP nodes
MongoDB and Cosmos DB
Everything in Professional

Contact Sales

Additional users and projects are each priced at $19.99 per month. For 3-month, 6-month and annual purchases, the selected Professional billing period's discount, shown in the savings badge, also applies to each additional user or project.

AI and execution costs are covered by your organisation using its own AI models or provider accounts and execution infrastructure. Gheetah does not provide its own AI model or charge an additional AI integration fee.

Only initial installation assistance is included free of charge. Training and integration services are quoted and billed separately.

GheetahAgent

Turn a machine into an execution target

Install it on the machine your tests need — a particular browser version, a desktop application, a phone on a USB port. It connects back, waits to be approved, and then takes work like any other target.

docker pull gheetah/agent:latest

Windows .exe macOS .dmg Linux .AppImage