DebuggAI
DebuggAI is an AI testing platform that drives your web app in a real browser on every code change, checking signup, login and checkout flows and posting pass or fail results with video straight into your pull requests.
What is DebuggAI?
DebuggAI is an automated application testing platform: an AI agent drives a web application inside a real browser, the way a customer would, and reports whether each journey still works. The product presents itself as AI app testing with no code needed, aimed at teams that now ship faster than their test suites can follow.
The chain is short. You connect a repository once, on GitHub or GitLab, and from the next pull request onwards DebuggAI reads the diff of each commit, builds a targeted test plan, runs it in a managed remote browser and posts a pass or fail comment back into the pull request, with screenshots and a video replay of exactly what happened. Nothing has to be written, wired up or maintained: there is no configuration file and no infrastructure to provision.
Four surfaces are documented. A VS Code extension, which also works in Cursor. An MCP server. A web dashboard for shared results and history. And Debugg CLI, for CI/CD pipelines. The MCP server is the most distinctive piece: it exposes 8 tools and 21 actions covering the browser agent, projects, test suites, test cases, environments and execution history, and its headline tool, check_app_in_browser, needs only a description and a URL. Two design choices separate it from thin browser wrappers. A secure tunnel to a locally running application is opened automatically on every call and its URL is never returned to the agent. And credentials are stored write-only, so an agent can log in by role, admin or guest, without ever seeing a password. The server is open source under Apache-2.0 and installs with a single environment variable.
A second product line, on the AI Test Suites page, takes a different route: a lightweight SDK watches the application while you develop it and turns the calls, edge cases and error states it observes into unit tests for Jest, Mocha, Pytest or JUnit.
DebuggAI is young. The domain was registered in March 2025, the company claims more than 100 development teams, and the only geographic marker on the whole site is a footer line reading Made in San Francisco.
What it does
- Test every pull request automatically in a real browser and report a clear pass or fail
- Explore an application on its own and map the pages, buttons and journeys customers actually use
- Generate browser tests from the diff of each commit, with no selectors or scripts to write
- Post results back into the pull request with screenshots and a video replay of the run
- Test a version running on your own machine through an automatic secure tunnel
- Take test instructions in plain English from an editor or an AI assistant
- Repair its own tests, telling an intentional interface change from a genuine regression
When to use DebuggAI / When not to
A quick filter to help you decide if DebuggAI is the right fit.
When to use DebuggAI
- Product and engineering teams shipping several times a day with no end-to-end test suite anyone still maintains
- Small teams with no dedicated QA function, since asking for a test needs no test-writing skill
- Open-source maintainers, whose public repositories are covered by the permanent free plan
- Revenue-critical web products where a broken checkout, signup or login costs money on the spot
- Developers working with AI coding agents in VS Code, Cursor, Claude Code or Codex who want each generated change verified in a real browser
When not to use DebuggAI
- Teams testing native mobile apps or pure APIs: DebuggAI only drives what runs in a browser, and no iOS or Android app exists
- Regulated buyers who need a compliance file, since the site names no certification, publishes no data processing agreement and discloses no hosting country or subprocessor
- Organisations that cannot let a third party clone their repository and run a copy of their application
- Solo developers with private repositories and no budget, because the free plan covers public repositories only
- Teams working in a language other than English, as both the interface and the documentation are English-only
How to use DebuggAI
A typical end-to-end flow, from setup to results.
- Create an account on app.debugg.ai; no credit card is asked for
- Install the DebuggAI GitHub app and pick the repositories you want covered, a step announced at about two minutes
- Let DebuggAI crawl the application once so it maps every page, button and flow into a knowledge graph
- Open or update a pull request as you normally would; testing starts on its own, with no manual trigger
- Read the comment posted back into the pull request: pass or fail per test, duration, screenshots and a video replay
- For editor-side work, add the extension to VS Code or Cursor and ask for a test in plain English, such as test the login flow
- To check a version running locally, point DebuggAI at a localhost URL; the secure tunnel is created for you on each run
- To drive it from an AI assistant, get a free API key, run npx -y @debugg-ai/debugg-ai-mcp with DEBUGGAI_API_KEY set, then call check_app_in_browser from Claude Desktop, Claude Code, Cursor, LangChain or any MCP client
- Store login credentials once per environment so agents can reference them by role instead of by password
- Review past runs from the execution history, inspect a failure step by step, or cancel a run that is going astray
Pros & Cons
Pros
- Setup is announced at two minutes, with no configuration file, no server to run and no code change
- No selectors or scripts to write: a test is requested in plain English
- Tests repair themselves when the interface moves, which attacks the running cost that kills most end-to-end suites
- Every run leaves visual proof, screenshot and video, inside the pull request itself
- A permanent free plan with no credit card, then a low paid entry point at USD 20 per month
- The MCP server is open source under Apache-2.0, needs one environment variable and works with any MCP client
- A version running on your own machine can be tested through an automatic tunnel, with no ngrok and no port forwarding
Cons
- The GDPR is never mentioned, no data processing agreement is published and no Article 27 representative is designated
- No certification is displayed, neither SOC 2 nor ISO 27001, and the site carries no trust or security page
- The hosting country is never stated and not a single subprocessor is named
- Whether customer data is used to train models is left entirely undocumented, in either direction
- The legal documents are dated 4 April 2024, before the domain was even registered in March 2025, and have not been revised since
- The free plan covers public repositories only, and quotas are tight at the bottom of the range: 100 tests a month, then 1,000
- Annual prices are advertised at 20 percent off but the amounts are not displayed, and claims such as 100 percent test coverage carry no source
Pricing & Plans
DebuggAI offers a permanent free plan, restricted to public repositories and capped at 100 tests per month, which requires no credit card. The cheapest paid entry point is the Pro plan at USD 20.00 per month. An annual commitment is advertised at 20 percent off, although the corresponding amounts are not published on the site.
- USD 0 - public repositories
- 100 tests per month
- pull request comments
- community support
- up to 3 parallel browsers and 3 test suites
- USD 20 per month - private repositories
- 1
- 000 tests per month
- up to 5 parallel browsers
- 10 test suites
- priority and email support
- advanced analytics
- USD 40 per month - everything in Pro plus 5
- 000 tests per month
- optional add-on usage
- up to 10 parallel browsers
- unlimited test suites
- team management and priority support
- custom pricing - unlimited tests
- more than 20 parallel tests per user
- unlimited test suites
- GitHub Actions CI/CD
- SSO/SAML
- dedicated support and custom integrations
- advertised at 20 percent off the monthly rate
- amounts not published
Data, GDPR & hosting
A consolidated view of how DebuggAI handles your data.
GDPR overview
The GDPR is never mentioned anywhere on the DebuggAI site: the regulation is not named, neither to claim compliance nor to deny it. No Article 27 EU representative is designated and no data protection officer is appointed; privacy@debugg.ai is the only address published for privacy matters. The privacy policy, dated 4 April 2024, does grant a list of rights depending on your location - access, correction, deletion, restriction of processing, portability and objection - but it cites no legal basis, describes no international transfer mechanism and offers no data processing agreement. The terms of service are governed by United States law, and the minimum age is set at 13, the American threshold rather than the European one. European buyers should expect to obtain contractual guarantees directly, because none are published.
Who owns the data?
Under the terms of service you keep every right you already hold in the content you submit, and you remain responsible for protecting those rights. In exchange you grant DebuggAI a licence to use, modify, publicly perform, publicly display, reproduce and distribute that content on and through the service. The platform itself, its original content and its features remain the exclusive property of DebuggAI and its licensors, and its trademarks may not be reused without prior written consent. The company states that it never stores source code and that applications run in isolated, temporary environments wiped after each run. Stored test credentials are held write-only and never returned. Ownership of the generated tests is not addressed anywhere.
Reuse rights
Nothing in the terms requires you to ask permission before reusing what the service produces for you: test results, recordings and generated test code are yours to keep and use, and you retain the rights you hold in the content you submit. The service itself is another matter, as its content, features and trade dress stay the exclusive property of DebuggAI. On the vendor side, the privacy policy lists seven purposes for the data it collects: running and maintaining the service, improving and personalising it, analysing usage, developing new products and features, sending updates, security alerts and support messages, sending marketing communications with consent, and detecting fraud. Data may be shared with third-party service providers, none of whom are named, transferred in a merger or acquisition, or disclosed to public authorities where the law requires it. The documents say nothing at all about whether customer data is used to train AI models.
Data retention & training
Hosting summary
DebuggAI publishes nothing about where customer data is hosted. Neither the privacy policy, the terms of service nor the cookie policy names a country, a region or a cloud provider, and the site has no trust or security page. What the documents do say is operational rather than geographic: applications run in isolated, temporary environments that are wiped after every run, connections are encrypted, and source code is not stored. Test credentials are held server-side, write-only. Technical observation places the company in the United States, since the domain resolves to a front-end address geolocated there and brand images are served from an S3 bucket in the us-east-2 region, but none of this is presented by the vendor as a commitment and it says nothing about where test runs or execution history actually live. The terms of service are governed by United States law. A buyer with a data residency requirement will have to obtain the answer directly from the company, because it cannot be established from the published material.
Things to keep in mind
Risks and trade-offs to weigh before adopting DebuggAI.
- DebuggAI receives a copy of your application and runs it, so a security review is essential before pointing it at a private repository
- Test credentials are stored on the vendor's servers; even write-only storage concentrates access to real accounts in one place
- No hosting country, subprocessor list or data processing agreement is published, so a European buyer cannot assess data transfers from the public documents alone
- Legal documents dated 4 April 2024 predate the March 2025 domain registration and have never been revised, so they may not describe the service as it actually works
- Trusting an automated pass too far is the classic failure mode: the product itself argues that a green pipeline can lie, and its own green results deserve the same scepticism
- A team that stops writing tests altogether can lose the shared understanding of its own critical flows that writing them used to produce
- The company is very young and publishes neither a postal address nor a full legal name, which is a continuity risk for a tool sitting inside a release process
Setup & Integrations
Technical difficulty
Low on the main path. Installing the GitHub app and selecting repositories is announced at about two minutes, with no configuration file, no infrastructure and no code change, while the editor route is a one-click install in VS Code or Cursor. Driving the tool from an AI assistant takes one command and a single environment variable. Only two routes ask for real technical work: adding a workflow file for the CI pipeline, and the AI Test Suites path, which needs a lightweight SDK installed and the application run with it attached.
Deployment
Integrations
Supported languages
Behind DebuggAI
Resources
All the official URLs gathered for verification and reference.
Alternatives
Tools that compete with or complement DebuggAI.
Frequently asked questions
How does DebuggAI decide what to test?
Do I need an engineer to set it up?
Where do the test results appear?
Can it test a version running on my own machine?
Which stacks and frameworks are supported?
Is there a free plan, and what does it cost afterwards?
What happens to my source code and my test credentials?
Is DebuggAI GDPR compliant?
Is there a mobile app?
Should you pick DebuggAI?
DebuggAI addresses one problem and addresses it squarely: keeping end-to-end browser coverage alive on a codebase that changes several times a day. Connect a repository once and every pull request gets a targeted test plan, run in a managed browser and answered with a pass or fail comment carrying screenshots and video. Nothing has to be written and nothing has to be maintained, which removes the running cost that kills most end-to-end suites.
Two engineering choices genuinely stand out. The MCP server opens a secure tunnel to a locally running application on every call without ever handing the tunnel URL back to the calling agent, and it stores credentials write-only so an AI agent can log in by role without seeing a password. Both matter if you intend to let coding agents verify their own work, and both are rare among browser MCP servers. The commercial entry is easy too: a permanent free plan for public repositories, USD 20 per month for private ones, two minutes of setup and no credit card.
The reservations lie elsewhere, and they are documentary rather than technical. The GDPR is never named on the site. No data processing agreement, no subprocessor list, no hosting country, no certification and no postal address are published, and the legal documents carry a date, 4 April 2024, that predates the registration of the domain itself. Several headline figures, such as 100 percent test coverage or up to 80 percent less time spent on testing, carry no source.
For a small team shipping a public product, the trade-off looks attractive today. For a regulated buyer, or for anyone whose procurement asks where the data lives and who processes it, those answers will have to be obtained by contract, because they are not on the website.
- Choosing a selection results in a full page refresh.
- Opens in a new window.