Hot take: if the site you’re scraping has a stable API or predictable HTML, Skyvern is overkill. It’s slower than a pure scraper, it costs LLM tokens per step, and each task runs 30-120 seconds. Where it earns its keep is on the sites that break traditional scrapers weekly – job boards, government portals, vendor invoice dashboards, anything with conditional forms or CAPTCHAs. If that’s your problem, keep reading.
This is a deployment guide for Skyvern v1.0.47, the latest release as of July 16, 2026 (GitHub releases). We’ll get it running locally, then cover the four install errors that show up repeatedly in the issue tracker but almost never in tutorials.
What Skyvern actually is (in one paragraph)
Think of it as Playwright with a vision model riding shotgun. You write a goal in plain English; the AI reads the page visually, decides what to click, and handles extraction – no XPath required. The tradeoff is latency: per the official skill docs, browser automation takes 30-120 seconds per task depending on complexity. That’s not a bug – it’s the cost of the vision loop. Plan for it.
System requirements
The docs are strict about Python and loose about everything else. Here’s what actually matters:
| Requirement | Value |
|---|---|
| Python | 3.11, 3.12, or 3.13 (per official quickstart docs) |
| OS | Windows, WSL, macOS, Linux |
| RAM / Disk | Check the system requirements section of the README – Chromium adds significant overhead |
| Database | SQLite (default, pip path) or PostgreSQL (Docker / production path) |
| Docker | Optional for pip path; required for Docker Compose path |
| LLM API key | One of: OpenAI, Anthropic, Gemini, Bedrock, Azure OpenAI, or Ollama |
Python version is non-negotiable. If you’re on 3.10, install fails immediately – no workaround. The CLI supports all four OS targets, though the README historically notes Windows users tend to have the smoothest experience through Docker rather than a native pip install.
Install method 1: pip + skyvern quickstart (recommended)
Fastest path. SQLite by default, no Postgres to configure. Trade-off: SQLite doesn’t handle concurrent tasks well, so use this for development, not production.
# Create an isolated environment (do NOT skip this)
python3.12 -m venv skyvern-env
source skyvern-env/bin/activate # Windows: skyvern-envScriptsactivate
# Install the server extra (includes local dependencies)
pip install "skyvern[server]"
# Interactive wizard - sets up DB, LLM keys, Chromium, .env
skyvern quickstart
# Start the server
skyvern run server
The wizard handles database provisioning, LLM configuration, browser installation, and API credential generation. If you already have Postgres running elsewhere: skyvern init --no-postgres skips database setup entirely – confirmed in the official quickstart docs.
Once it finishes, the UI is at http://localhost:8080 and the API at http://localhost:8000.
Install method 2: Docker Compose (for production)
Three containers, per the docker-compose.yml at the repo root: PostgreSQL, the skyvern API server (with Chromium baked in), and the React frontend. No Python or Node required on the host.
git clone https://github.com/Skyvern-AI/skyvern.git
cd skyvern
cp .env.example .env
# Edit .env - add at minimum: LLM_KEY, plus one of ANTHROPIC_API_KEY / OPENAI_API_KEY
docker compose up -d
Images pull from public.ecr.aws/skyvern/skyvern:latest and public.ecr.aws/skyvern/skyvern-ui:latest. First pull is slow – Chromium is baked into the image.
The catch: If you run Portainer, n8n, or anything else on ports 8000/8080, you must remap BOTH the container ports AND the frontend’s
VITE_API_BASE_URL+VITE_WSS_BASE_URLenvironment variables. Remapping ports alone leaves the UI unable to reach the API – silently. The browser just shows a blank task list. This tripped up multiple users in issue #2311.
First-time configuration
One LLM provider is the minimum. The quickstart wizard creates a .env with placeholders; fill in one block and set LLM_KEY to tell Skyvern which model to route to. Supported providers (from the skill docs): OpenAI, Anthropic, AWS Bedrock, Azure OpenAI, Google Gemini, Ollama, and OpenAI-compatible endpoints. Example for Claude:
ENABLE_ANTHROPIC=true
ANTHROPIC_API_KEY=sk-ant-...
LLM_KEY=ANTHROPIC_CLAUDE_SONNET
Restart the server after editing. The UI task page stays broken until at least one provider is enabled – there’s no warning, it just doesn’t queue tasks.
Verify it works
Three checks, in order of speed:
- Version check:
skyvern --versionshould print1.0.47(or the latest version when you read this). - API health:
curl http://localhost:8000/api/v1/heartbeat– expect a 200 response. - Real task: Open the UI at
http://localhost:8080, create a task with URLhttps://news.ycombinator.comand prompt “Extract the title and points of the top 5 posts as JSON.” You should see a live browser stream and JSON output in 60-90 seconds.
If the version prints but the API 404s, the server didn’t start – check skyvern run server logs for LLM key errors.
The four errors you’ll actually hit
Every tutorial ends with “if you have problems, check the docs.” Here are the specific failures traced through GitHub issues.
1. sqlite3.OperationalError: table organizations already exists
The README troubleshooting section documents this exactly: it’s a known bug in pip install skyvern==1.0.31. The fix:
rm ~/.skyvern/data.db
pip install --upgrade skyvern # 1.0.32+ contains the fix
skyvern quickstart
Can’t upgrade yet? Switch to uv pip install skyvern – uv’s resolver sidesteps the conflict.
2. ResolutionImpossible on litellm / fastmcp
Same 1.0.31 dependency conflict. pip can’t resolve the version graph. Upgrade past 1.0.31 or switch to uv pip install skyvern.
3. ERROR: Skyvern Frontend directory not found
Reported in issue #2644 and issue #3241. Hits most often when installing into a Poetry-managed project. The API starts, Chromium installs, then the UI fails because the frontend bundle wasn’t extracted into the expected site-packages path. Two workarounds that people report working: reinstall into a plain venv (not Poetry), or fall back to Docker Compose which ships the UI as a separate container with no path ambiguity.
4. connection failed: fe_sendauth: no password supplied
From issue #2753. Quickstart ran once, created the Postgres role and database, then a second run tried to recreate them and failed halfway – role exists, password unset. Fix:
docker rm -f postgresql-container
docker volume prune
skyvern quickstart --postgres
A note on when this stack makes sense
Skyvern is not a scraper replacement. It’s a scraper for the sites where a scraper stops working. Pulling stable price data from a REST API? Use requests. Pulling that same data through a login flow with rotating field names and a CAPTCHA every fifth request? The tokens-per-step cost becomes reasonable when the alternative is a human clicking – or a fragile XPath farm that breaks every Tuesday when the site redeploys.
Upgrade and uninstall
Upgrading between 1.0.x patches is usually painless:
pip install --upgrade skyvern
skyvern run server # migrations run automatically on start
For Docker Compose: docker compose pull && docker compose up -d. Check the GitHub releases page before upgrading minor versions – behavior can change between patches, and the release notes are the only reliable source for what shifted.
To uninstall cleanly:
pip uninstall skyvern
rm -rf ~/.skyvern # SQLite DB, artifacts, .env
docker rm -f postgresql-container # if you used --postgres
playwright uninstall chromium # optional - frees disk space
Your next action: open http://localhost:8080, create a task against a site that’s been giving your existing scraper trouble, and set max_steps to 10. If it completes in under 10 steps, you have your baseline. If it doesn’t, you’ve learned something about your prompt in five minutes – cheaper than a week of selector maintenance.
FAQ
Do I need a paid Skyvern Cloud account to test this locally?
No. Self-hosted runs entirely on your machine using your own LLM API key. Cloud adds parallel execution, managed proxies, and CAPTCHA solving at scale – none of that is needed to evaluate whether Skyvern solves your specific problem.
Can I point Skyvern at an existing Chrome window instead of Chromium?
Yes, via the CDP-connect browser option in the quickstart wizard. You’ll need Chrome running with remote debugging enabled (--remote-debugging-port=9222). Useful when the target site requires a logged-in session tied to your real browser profile. One thing to watch: Skyvern will interact with whatever tab is active, so close everything else before running a task – otherwise it may click the wrong window mid-flow. Check the current docs for the exact wizard option name, as it may have changed since this was written.
Why does my task work in the UI but fail from the Python SDK?
Almost always: wrong API key. The self-hosted server generates its own key during skyvern quickstart and stores it in .env. That local key is what you pass to the SDK – not your Anthropic or OpenAI key. Open .env, find the Skyvern API key entry, copy it, done.