Free, open-source CLI that turns one plain-English sentence into a real browser test — no selectors, no code, no flaky locators. Runs on free local models (Ollama) or free OpenRouter models, so there are zero API keys and no credit card. Works with local Chrome, LambdaTest, BrowserStack, Browserbase or any CDP endpoint. `npm install -g browserbash-cli` and automate any site in seconds. Apache-2.0.
No reviews yetBe the first to leave a review for BrowserBash
Hunter
📌
Hey Product Hunt — Pramod here (I run The Testing Academy on YouTube).
Every test-automation tool I picked up meant brittle selectors, flaky locators, and a framework to babysit. I just wanted to *say* what to test and have it happen. So I built BrowserBash: you give it one plain-English objective and an AI agent drives a real browser to do it — no selectors, no code.
What I care about most: it's genuinely free and open source (Apache-2.0). It runs on free local models (Ollama) or free OpenRouter models — zero API keys, no credit card. `npm install -g browserbash-cli` and you're automating any site in seconds. It works with local Chrome, LambdaTest, BrowserStack, Browserbase, or any CDP endpoint. Bring your own Anthropic/OpenRouter key only if you want to.
A free account adds a dashboard with run history, video recordings and per-run replays — so you can see exactly what the agent did.
It's early and I'd genuinely love your honest feedback — what's the first flow you'd point it at, and what would make it a daily driver for you? Roast it if it deserves it. I'm here all day.
Report
@promode_ Looks great and something I'd like to use, but my machine isn't powerful enough to drive local models. Can I use an AI subscription instead?
Report
Hunter
@artk yes, you can use the openrouter, Groq.com APIs
Report
@promode_ Love the landing page design and the copy! Very clear and neat.
Stagehand (by Browserbase) is a TypeScript library you build with in code (act/extract/observe). BrowserBash is the batteries-included CLI layer on top:
• no code, a plain-English objective or a committable *_test.md file • --agent → NDJSON + exit codes 0/1/2/3 for CI • --record → video/screenshot/trace of every run • one --provider flag: local Chrome, CDP, Browserbase, LambdaTest, BrowserStack • Ollama-first, so it runs on free local models (no API keys) • a local + cloud dashboard
Library to wire into your own code → Stagehand. Ready-to-run CLI/test-runner → BrowserBash (which uses Stagehand under the hood). Huge respect to the Browserbase team 🙏
Report
Really interesting project! 🚀
The idea of describing a test instead of writing selectors is compelling, especially for quickly validating user flows.
I'm curious: if the UI changes significantly between releases, how does BrowserBash decide whether it's the same workflow with a different layout versus an actual regression that should fail the test?
Report
Hunter
@prashant_patil14 There is Plan to keep a diff mechanism also, Visual Checks also
Report
The hard part in plain-English browser tests is preserving intent after selectors change. A good test should explain the user-level invariant it protects, not just regenerate clicks.
@patrick_krekelberg spot-on, that's the whole thesis. A BrowserBash objective is the user-level invariant, not a click path: you write "log in and verify the order shows 'Thank you for your order!'", and the agent re-derives the clicks each run. No selector is encoded anywhere, so a selector change can't touch the intent.
The honest caveat is that it's only as good as the invariant you write. "Click checkout" will drift; "verify the order is confirmed" protects intent. The tool nudges you toward asserting outcomes , every run returns a verdict against what you described but writing the right invariant is still on the author. Committable *_test.md files help there: the intent is reviewable in a PR, like code.
Report
Love that it supports local models via Ollama right out of the box so we don't burn through API credits testing basic flows. Going to point this at my onboarding sequences today!
@marc_vuit@marc_vuit great question 🙏 The CLI and local runs stay free forever, that's the open-source core, and I want it to stay that way. Monetization is opt-in: a paid tier for keeping your cloud run history + recordings past the free 15-day window. Free runs auto-expire after 15 days; if you want them retained, you upgrade. Team/hosted features are on the roadmap too. The free tier isn't a trick to upsell later it's the actual product.
Report
Love that it's plain-English to real browser tests, not just recorded scripts you have to babysit. The CLI angle feels right too, keeps it close to where I'm already working instead of yet another dashboard.
@promode_ Looks great and something I'd like to use, but my machine isn't powerful enough to drive local models. Can I use an AI subscription instead?
@artk yes, you can use the openrouter, Groq.com APIs
@promode_ Love the landing page design and the copy! Very clear and neat.
@zerotox Thanks Kumar
Looks awesome, can't wait to try this out! How does this differ from stagehand?
@olli_paloviita @olli_paloviita honest answer: BrowserBash is built on Stagehand , it's the default engine 🙂
Stagehand (by Browserbase) is a TypeScript library you build with in code (act/extract/observe). BrowserBash is the batteries-included CLI layer on top:
• no code, a plain-English objective or a committable *_test.md file
• --agent → NDJSON + exit codes 0/1/2/3 for CI
• --record → video/screenshot/trace of every run
• one --provider flag: local Chrome, CDP, Browserbase, LambdaTest, BrowserStack
• Ollama-first, so it runs on free local models (no API keys)
• a local + cloud dashboard
Library to wire into your own code → Stagehand. Ready-to-run CLI/test-runner → BrowserBash (which uses Stagehand under the hood). Huge respect to the Browserbase team 🙏
Really interesting project! 🚀
The idea of describing a test instead of writing selectors is compelling, especially for quickly validating user flows.
I'm curious: if the UI changes significantly between releases, how does BrowserBash decide whether it's the same workflow with a different layout versus an actual regression that should fail the test?
@prashant_patil14 There is Plan to keep a diff mechanism also, Visual Checks also
The hard part in plain-English browser tests is preserving intent after selectors change. A good test should explain the user-level invariant it protects, not just regenerate clicks.
@krekeltronics
@patrick_krekelberg spot-on, that's the whole thesis. A BrowserBash objective is the user-level invariant, not a click path: you write "log in and verify the order shows 'Thank you for your order!'", and the agent re-derives the clicks each run. No selector is encoded anywhere, so a selector change can't touch the intent.
The honest caveat is that it's only as good as the invariant you write. "Click checkout" will drift; "verify the order is confirmed" protects intent. The tool nudges you toward asserting outcomes , every run returns a verdict against what you described but writing the right invariant is still on the author. Committable *_test.md files help there: the intent is reviewable in a PR, like code.
Love that it supports local models via Ollama right out of the box so we don't burn through API credits testing basic flows. Going to point this at my onboarding sequences today!
@varunvivek Thank Vivek, You can always use cheaper model like Deepseek V4 Flash, Qwen3.5 models to automate scenarios, cost is very low.
https://browserbash.com/math.html
great man, how would you montize it if it is free
@marc_vuit @marc_vuit great question 🙏 The CLI and local runs stay free forever, that's the open-source core, and I want it to stay that way. Monetization is opt-in: a paid tier for keeping your cloud run history + recordings past the free 15-day window. Free runs auto-expire after 15 days; if you want them retained, you upgrade. Team/hosted features are on the roadmap too. The free tier isn't a trick to upsell later it's the actual product.
Love that it's plain-English to real browser tests, not just recorded scripts you have to babysit. The CLI angle feels right too, keeps it close to where I'm already working instead of yet another dashboard.