Browserbase’s Autobrowse is one of the sharpest ideas in browser automation right now. Hand an agent a real task, let it iterate until it converges, and graduate the winning path into a reusable skill. If you have read the Autobrowse post or browsed the Browse.sh catalog, you already know the appeal.
So why look for an alternative? Almost always for one reason: control. Teams that handle regulated data, or that would rather not route browsing through a third party, want the same record-once idea running entirely on their own infrastructure. This post lays out the honest options, including where each one is strong and where it falls short.
Short answer. The closest self-hosted, open-source match is Webcmd, which records a session and distills it into a deterministic script you run locally. Autobrowse is more mature and has a large public skill catalog. Pick based on whether you value a ready-made catalog or full local control.
What Autobrowse does well
Credit where it is due. Autobrowse is a strong system, and a fair comparison starts by saying so.
Its self-improving loop needs no human in the middle. The agent runs the task, reads its own trace, and refines its strategy across a few iterations until the result is reliable. The graduated skills feed Browse.sh, a public catalog of more than 100 browser skills you install with one command, backed by a 3.6k-star GitHub repo and partner skills from names like Ramp and Lovable.
It also has real production muscle on hard sites. Stealth browsing, CAPTCHA solving, and residential proxies handle the pages that block a plain Chromium session.
Why teams look for a self-hosted option
Here is the nuance that matters. The Autobrowse skill itself is open source and can drive a local browser. But the parts that carry it on protected sites, the stealth, the CAPTCHA solving, the proxies, run through Browserbase’s cloud. That is a fine trade for many teams and a dealbreaker for others.
You reach for a self-hosted alternative when:
- Browsing data cannot leave your environment, for privacy, compliance, or data-residency reasons.
- You want no cloud dependency or vendor lock-in in the run path.
- You would rather capture a real demonstration once than pay for several self-play iterations to converge.
- You want to own the auth and identity the automation runs under.
If none of those apply, Autobrowse and its catalog are a great default. If any of them do, read on.
The alternative: Webcmd
Webcmd is the closest self-hosted match to what Autobrowse does. It records a real browser session into a journal, distills that into a per-app capability graph, and materializes either a deterministic replay script or a standalone CLI that ships its own SKILL.md. All of it runs on your machine under the Apache-2.0 license.
Three differences stand out, and none of them make Webcmd strictly better, only different:
It captures a real session, including a human handoff for the tricky step, rather than converging through repeated self-play. That can be cheaper and more predictable when a person already knows the path, and slower to scale across many sites than a hands-off loop.
It keeps a reusable capability graph per app that deduplicates across sessions, instead of one skill file per task. The graph is the durable model; scripts and CLIs are materialized from it.
Auth stays local. Named profiles under .webcmd/profiles hold identity for one or more apps, and commands like webcmd auth doctor and webcmd auth login manage login flows you control. For blocked sites, Webcmd ships CloakBrowser by default and a Camofox fallback, all running in your own setup.
Be clear-eyed about the trade. Webcmd is early, at v0.1.2, with no large public catalog and no managed stealth service to lean on. You get local control and an inspectable model; you give up a mature ecosystem. If that trade fits, it is worth a look.
Adjacent open tools worth knowing
A self-hosted stack sometimes means stitching a few tools together. These solve part of the problem and run locally, though none graduates a durable, reusable skill on its own.
Vercel’s agent-browser is an open-source browser CLI for AI agents, with deterministic snapshot refs and persistent profiles. It is a clean way for a coding agent to drive a browser, but it does not build memory across runs.
browser-use is a popular open-source agent that drives a browser from a natural-language task. Strong general driver, but it re-explores each run unless you add your own memory layer.
Playwright codegen records a session and emits a script. Fully deterministic and local, with no model in the loop, so it breaks when the page changes and holds no capability model.
How the options compare
| Tool | Open source | Runs fully local | How it makes memory | Best for |
|---|---|---|---|---|
| Autobrowse / Browse.sh | Yes | Local mode; stealth needs cloud | Self-play, graduates a skill | A ready catalog, hands-off learning, hard sites |
| Webcmd | Yes (Apache-2.0) | Yes | Record a session, distill a capability graph | Self-hosting, local auth, deterministic replay |
| Vercel agent-browser | Yes | Yes | None across runs | A coding agent driving a browser |
| browser-use | Yes | Local, cloud optional | Re-explores unless extended | General agentic browsing |
| Playwright codegen | Yes | Yes | Static recorded script | Fixed, unchanging flows |
How to choose
Match the tool to what you are optimizing for, not to a feature count.
Want the least work and the widest head start? Autobrowse plus the Browse.sh catalog is hard to beat, and the cloud path handles protected sites for you. Need everything on your own infrastructure, with auth and data you control? Webcmd is the closest fit, with the honest caveat that it is young. Only need to drive a browser from a coding agent, with no memory? A local CLI like agent-browser or a Playwright recording is lighter than either.
The underlying idea is shared across all of them: a solved web task should become a durable artifact, not a fresh problem on every run. The only real question is where that artifact lives and who runs it.
FAQ
Is Autobrowse open source?
The Autobrowse skill is open source and can run against a local browser. Its stealth, CAPTCHA-solving, and proxy features run through Browserbase’s cloud, so the fully local path gives up those capabilities.
What is the best self-hosted alternative to Autobrowse?
Webcmd is the closest match for teams that want the record-once pattern running entirely on their own infrastructure. It is Apache-2.0 and keeps auth and browsing data local, though it is earlier-stage than Autobrowse.
Can I move skills between these tools?
Partly. Autobrowse and Webcmd both produce a SKILL.md-style artifact, so a generated skill is readable and portable in principle. The helper scripts and CLI calls a skill references are tool-specific, so expect some adaptation.
Do I still need proxies and CAPTCHA solving if I self-host?
On protected sites, yes. Self-hosting means you supply that layer yourself. Webcmd ships CloakBrowser and a Camofox fallback for blocked pages, but managed anti-bot infrastructure like Browserbase’s is more battle-tested.