SK

Skyvern

Automate browser workflows with LLMs and computer vision

Automation & Workflows ★ 23.1k stars Medium setup AGPL-3.0

Skyvern automates browser-based workflows by combining large language models with computer vision, allowing it to operate on websites it has never seen before. It runs as a self-hosted service with an API.

Key features

  • LLM-driven browser automation
  • Works on unseen sites
  • Vision-based interaction
  • Workflow API

Pros & cons

Strengths

  • Handles unseen websites
  • Vision-based automation
  • API-first design

Trade-offs

  • LLM costs add up
  • Postgres required

Skyvern replaces

Last reviewed Aug 26, 2026 · 774 words

Budget for the LLM bill before the hardware. Skyvern works by screenshotting a live browser, asking a vision-capable model what to click next, and repeating until the task is done, which means a 20-step form fill is 20-plus vision calls with full-page images attached. On a frontier hosted model that runs anywhere from a few cents to a couple of dollars per run in my experience (an estimate; it depends on page size and how many retries the site provokes). The 4 GB RAM floor and the Postgres requirement are trivial next to that. Get the cost model straight and Skyvern is the most capable self-hosted browser agent I have run; ignore it and you will turn it off within a week.

What it does that Playwright scripts cannot

A scripted browser automation breaks the day a site renames a CSS class. Skyvern never sees the selectors; it reasons about the rendered page the way you would, so one task definition works on a site it has never visited and survives redesigns. The typical jobs are the ones people actually pay for: submitting the same application on 40 supplier portals, pulling invoices from a vendor dashboard with no API, filling government forms, and price checks on sites that block plain scrapers. If the target has an API, do not use Skyvern. If the target is one fixed site that never changes, a Playwright script running in Browserless is cheaper by a factor of 100 per run.

The self-host stack is Docker Compose plus a model key

git clone https://github.com/Skyvern-AI/skyvern
cd skyvern
docker compose up -d

Compose brings up Postgres, the API on port 8000 and the UI on port 8080. Before the first up, edit the env file to enable a provider (ENABLE_OPENAI=true with OPENAI_API_KEY, or the equivalent block for Anthropic, Azure, Gemini, Bedrock, OpenRouter or Ollama) and set LLM_KEY to name the active model. Chromium runs inside the container through Playwright, so the host needs no display and no browser installed.

Local models work, but pick one that can actually see

Skyvern can point at Ollama, and a fully local run costs nothing per step. The catch is that the model must read screenshots accurately and return structured JSON reliably, every step. The small vision models that fit in 8 GB of VRAM miss buttons and invent field names often enough that the retry loop costs more wall-clock than the hosted call would have cost in cents. If you go local, plan on a 24 GB card and a current mid-sized vision model, and read the hardware guide for local LLMs first. My working rule: prove the task against a hosted model so you know it is achievable, then try to move it local.

Tasks, workflows and the API

A task is one natural-language goal plus a URL and optional structured data to enter. A workflow chains tasks with parameters, loops and extraction steps into something reusable, and every workflow gets an API endpoint. That is the hook: an n8n flow calls Skyvern for the single step that needs a real browser and handles everything else with ordinary nodes. That split is the right architecture, n8n for the 90 percent of automation that is HTTP and JSON, Skyvern for the pages only a human-like agent can operate. The automation category covers the tools on the n8n side.

Guardrails worth setting on day one

Give the agent its own accounts on any site it logs into, never yours. Set a maximum step count per task so a confused run cannot burn an hour of vision calls. Put a hard spend limit on the provider key at the provider. And take the AGPL-3.0 licence for what it is: no problem for internal use, a conversation with counsel if you plan to sell access. The LLM cost engineering post has the accounting approach that stops this class of tool surprising you at month end.

What I'd do

Run Skyvern on the existing Docker host with the bundled Postgres, a hosted model with a hard monthly cap, and a step limit on every task. Reserve it for the 3 or 4 recurring jobs where a site has no API and changes often enough to break scripts. Everything else stays in n8n. If the monthly invoice from those jobs passes what a 24 GB GPU costs in about 6 months, that is the moment to move the vision model local, and not before.

Compare Skyvern

14 head-to-head comparisons.

Similar automation & workflows apps