# Skyvern: LLM and Vision Driven Browser Automation That Skips XPath

> Skyvern is an AGPL-3.0 Python project that drives a real browser with vision language models instead of hand written selectors, and ships a Playwright-compatible SDK plus a no-code workflow builder. It fits well when target sites change often; it is overkill when selectors are stable.

**Skyvern-AI/skyvern** — Automate browser based workflows with AI. Automate Browser-based workflows using LLMs and Computer Vision Skyvern automates browser-based workflows using LLMs and computer vision.

- Repository: https://github.com/Skyvern-AI/skyvern
- Website: https://www.skyvern.com
- Stars: 23,067 · Forks: 2,176
- Language: Python
- License: AGPL-3.0
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/skyvern-ai-skyvern

## The brittle-selector problem Skyvern is aimed at

The README frames the target problem directly: traditional browser automation meant writing custom scripts per site, usually leaning on DOM parsing and XPath, and those scripts broke whenever the layout changed. Skyvern's answer is to stop encoding the interaction in code and let a vision model look at the rendered page and decide what to click.

That reframes who the tool is for. If you maintain a small number of internal forms with stable markup, the classic approach is cheaper and deterministic. Skyvern earns its place when the same workflow has to run across many third-party sites you do not control, or when a redesign would otherwise mean rewriting selectors. The README also claims a single workflow can be applied to a large number of websites, which is the same idea stated as a feature rather than a fix.

One caveat sits in the repository itself rather than the README: the pyproject.toml comment on the local extra says embedded local mode is a Forge-backed compatibility bridge and is not a minimal browser-only runtime until local stops importing Forge internals. So the lightweight-sounding install path is not as thin as it looks.

## How a swarm of agents reads a page and acts on it

Skyvern's README credits BabyAGI and AutoGPT as inspiration, then adds the piece those projects lacked: the ability to actually drive a browser through Playwright. The mechanism described is a swarm of agents that comprehends a website, then plans and executes actions against it.

The design consequence is that there are no pre-determined XPaths or selectors the system searches for while navigating. Instead, the model maps visual elements to actions. The README lists three advantages from that: operation on sites it has never seen, resistance to layout changes, and reuse of one workflow across many sites.

The engineering cost is visible in the repository layout. The Dockerfile installs Playwright browsers, tesseract-ocr with language packs, x11vnc, xauth and websockify, and docker-compose.yml exposes port 6080 for VNC WebSocket streaming. None of that is accidental: a system that reasons over rendered pixels needs a real browser, OCR, and a way to watch it. The .env.example also exposes BROWSER_STREAMING_MODE with values cdp and vnc, noting quickstart writes cdp for new local installs while app code falls back to vnc when unset. That fallback is worth knowing before you debug a blank stream.

## Installing Skyvern and running a first workflow

The README offers two local paths. The pip path needs Python 3.11, 3.12 or 3.13; on Windows it additionally asks for Rust and VS Code with C++ dev tools and the Windows SDK. Install the full package, which brings the server and the packaged UI:

```bash
pip install "skyvern[all]"
```

Then run the interactive setup. According to the README, quickstart and run server default to a SQLite database at ~/.skyvern/data.db, so no Postgres is required for the pip path:

```bash
skyvern quickstart
```

If you would rather use Postgres, the README documents passing a connection string, or omitting --no-postgres so quickstart starts its own Postgres container:

```bash
skyvern quickstart --database-string=postgresql+psycopg://user:pass@host:5432/dbname
```

The Docker Compose path is the other option, and it is the one to pick if you do not want Python or Node on the host. The README's steps are to clone the repository, copy the environment template, edit it to add your LLM API key, and start everything:

```bash
git clone https://github.com/skyvern-ai/skyvern.git && cd skyvern
cp .env.example .env  # if not already created
docker compose up -d
```

The compose file starts postgres:14-alpine and the public.ecr.aws/skyvern/skyvern:latest image, publishes port 8000 for the API and 6080 for VNC streaming, and mounts artifacts, videos, har, log, downloads, browser_sessions and credential_vault into /data. The README says to open http://localhost:8080 after compose starts; note that the published API port in docker-compose.yml is 8000, so the UI address and the API address are not the same thing. That mismatch is worth resolving in your own notes before you hand the URL to anyone else.

For the SDK path, the README documents a Python client and a TypeScript one, and adds four AI commands on the page object. Three appear in the README's command table:

```python
page.act(prompt)
page.extract(prompt, schema)
page.validate(prompt)
```

The README describes act as performing actions using natural language, extract as extracting structured data from the page with an optional JSON schema, and validate as validating page state and returning a bool. The TypeScript client installs separately with npm install @skyvern/client.

## Where Skyvern is the wrong tool

Two limits are documented, and both matter more than the feature list.

First, the install history. The README's troubleshooting section records that pip install skyvern==1.0.31 hit a sqlite3.OperationalError about the organizations table already existing, and separately a ResolutionImpossible conflict between litellm and fastmcp. The stated fixes are removing ~/.skyvern/data.db and upgrading, or installing through uv instead. That is a real failure mode for anyone pinning an old version, and it also tells you the dependency graph is dense enough to produce resolution conflicts.

Second, the cost model. Every action is decided by a vision model, and the README's own framing is that Skyvern replaces brittle automation rather than supplementing it. If you have five internal pages with stable markup, a Playwright script with explicit selectors is faster, free per run, and deterministic. Skyvern's resistance to layout change buys you nothing when the layout does not change, and you pay for it in tokens and per-step latency. The README does not document rollback or a dry-run mode, so the first run against a production site is the only test you get unless you build one yourself.

There is also a licence boundary. The repository is AGPL-3.0, which is a different obligation from a permissive licence, and the README does not discuss what that means for embedding Skyvern in a closed product. That is a question for your own counsel, not for the README.

## Skyvern compared with browser-use, Stagehand and plain Playwright

The three comparisons people search for differ in where the intelligence sits.

Playwright is the substrate. Skyvern's README calls itself a Playwright extension and states that it gives you the full power of Playwright plus AI capabilities. With plain Playwright you write selectors and control flow yourself; nothing is inferred. That is the right choice when determinism and cost per run matter more than adapting to unknown sites.

browser-use is the closest conceptual alternative: an agent that drives a browser from a task description. The difference in Skyvern's case is that the README positions the project as a Playwright-compatible SDK on top of an existing automation library, and pairs it with a no-code workflow builder and a managed cloud offering. So the unit of reuse is a saved workflow that non-engineers can run, not only a prompt handed to an agent in code. Whether that matters depends on whether you need an operator-facing UI or just a script.

Stagehand takes a third position, keeping Playwright in charge and adding natural-language actions where selectors are awkward. That is a hybrid: most of the script stays deterministic, and the model handles the parts that resist selectors. Skyvern's README describes the opposite emphasis, where the model is doing the comprehension and planning across the workflow rather than filling gaps in a written script.

The honest summary is that these are not interchangeable. Choose Skyvern when the workflow itself is the artifact you want to store, version and hand to other people. Choose a lighter AI layer when you want a script that mostly stays a script.

## Maintenance, releases and what the AGPL-3.0 licence implies

The last push to the default branch was on 2026-08-24, and the most recent release listed is v1.0.51 on the same date, following v1.0.50 and v1.0.49 earlier in August. The repository is not archived. The release cadence in the repository is frequent, and pyproject.toml declares version 1.0.52, one patch ahead of the newest published release, which is normal for a main branch between tags.

Upgrade cost is the part to plan for. The README's troubleshooting entries show that a single patch release can carry a database-schema fix and a dependency-resolution fix, and that the workaround for the schema bug is deleting the local SQLite file. If you run the pip path with SQLite, treat ~/.skyvern/data.db as disposable and keep the workflows you care about somewhere you can restore them from. The Docker path avoids that particular problem because compose uses the bundled Postgres service, but it moves the burden to the postgres-data volume instead.

The licence is AGPL-3.0, stated in the repository's LICENSE file and referenced from the README badge row. The practical implication, which you should confirm with your own legal review rather than take from an article, is that network use of modified code can trigger source-distribution obligations in a way permissive licences do not. If Skyvern sits behind an internal tool that users reach over a network, that is the scenario to examine first. The README does not address licensing beyond the badge.

## Conclusion

Adopt Skyvern when the sites you automate change layout often and you can accept LLM latency and cost per run. Skip it when a handful of stable selectors already work, or when AGPL-3.0 does not fit how you ship. Before committing, run skyvern quickstart, point it at one real workflow, and check the artifacts, HAR and video directories the compose file writes to, because that is the only audit trail you get when a run goes wrong.

## FAQ

### What is Skyvern?

Skyvern is a Python project that automates browser-based workflows using LLMs and computer vision, released under AGPL-3.0. The README describes it as a Playwright-compatible SDK that adds AI functionality on top of Playwright, plus a no-code workflow builder.

### How to install Skyvern?

The README gives two local paths. Run pip install "skyvern[all]" followed by skyvern quickstart, which defaults to SQLite at ~/.skyvern/data.db, or clone the repository, copy .env.example to .env, add an LLM API key, and run docker compose up -d.

### How to use Skyvern?

You can use the no-code workflow builder in the local UI, or the SDK, which the README describes as adding AI commands on the page object such as page.act with a natural-language prompt and page.extract with an optional JSON schema.

### Is Skyvern open source?

Yes. The repository is public, the primary language is Python, and the licence is AGPL-3.0, which the README references through its LICENSE badge. The README does not discuss the implications of that licence for embedding Skyvern in another product.

### How much does Skyvern cost?

The README does not list prices. It describes a self-hosted open source option and a managed Skyvern Cloud version at app.skyvern.com that bundles anti-bot detection, a proxy network and CAPTCHA solvers. Self-hosting still carries LLM API costs from whichever provider you enable in .env.

### Skyvern vs browser-use: what is the difference?

Both drive a browser from a model rather than from written selectors. Skyvern's README positions it as a Playwright-compatible SDK with a no-code workflow builder and a managed cloud option, so a saved workflow can be reused by non-engineers, whereas the agent-in-code approach keeps the task in the script.

## Sources

- [Official documentation](https://www.skyvern.com)
- [Official README](https://github.com/Skyvern-AI/skyvern#readme)
- [Project repository](https://github.com/Skyvern-AI/skyvern)
- [Release notes](https://github.com/Skyvern-AI/skyvern/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/skyvern-ai-skyvern