The Problem

Browser automation has traditionally required writing custom scripts for each website, relying on brittle DOM parsing and XPath selectors that break with layout changes. Teams maintaining these scripts face constant maintenance overhead as websites evolve, and non-technical users cannot contribute to automation efforts.

What This Does

skyvern is a portfolio of 9 projects centered on AI-powered browser automation. The core skyvern project (887 files, 760 code files) provides the Playwright-compatible SDK that adds AI functionality on top of Playwright, while skyvern-frontend (959 files) offers a no-code workflow builder. The system uses Vision LLMs to comprehend websites and plan actions, enabling workflows that work across sites without site-specific code. Key entry point: main in skyvern/__main__.py:1 reaches 11 functions. The system touches 2 database functions, 12 file operations, 6 cryptographic operations, 2 network calls, and 4 external commands. Representative call edges include main -> start_forge_app and main -> configure_cli_bootstrap_logging, with parse_totp_secret called from 9 places and normalize_for_compare from 6 places. The codebase defines 905 functions and 411 classes across the projects.

How It Is Wired

Execution starts at skyvern/__main__.py:1 with the main function, which orchestrates the forge application startup. From there, control flows through start_forge_app and configure_cli_bootstrap_logging. The SDK modules handle specific concerns: skyvern/forge/sdk/schemas/google_sheets.py defines 11 Google Sheets schema types, while skyvern/forge/sdk/cache/base.py manages async context entry/exit for caching. skyvern/forge/sdk/event/base.py provides 8 event-handling functions including click and type_text. The system makes outbound network calls via skyvern/forge/sdk/api/llm/ui_tars_response.py. Database interactions occur through skyvern/forge/sdk/db/protocols.py with 5 repository functions. The call graph has 219 resolved edges, with encrypt and decrypt each called from 5 places, and set from 5 places. A hub exists in the SDK initialization flow through skyvern/forge/__init__.py, which 3 files call into and defines set_app and set_force_app_instance - changing this file affects multiple downstream modules.

How To Use It

Setup:

# Install dependencies
cd skyvern
pip install -e .

# Or via Docker
docker build -t skyvern .

Configuration: Required environment variables are defined in .env.example at the root. The Dockerfile uses python:3.11-slim-bookworm as base image.

Running it: Entry point is python -m skyvern or skyvern CLI command from skyvern/__main__.py. For the frontend UI, navigate to skyvern-frontend/ and serve the React application.

Real-World Use

A marketing team needs to extract pricing data from 50 competitor websites monthly. Instead of writing 50 custom scripts, they define one workflow in the skyvern frontend: "navigate to pricing page, identify price element, extract value, save to CSV." The Vision LLM understands the website layout visually, so the same workflow applies across all sites regardless of CSS class changes. The workflow runs via the SDK: skyvern.browser.navigate(url); skyvern.ai.extract(selector="price"); skyvern.browser.save("pricing.csv").

Code Health & Issues

  • [MEDIUM] Declare least-privilege permissions for GITHUB_TOKEN - .github/workflows/build-docker-image.yml - 1 workflow declares no permissions, 1 references secrets. With no declaration the token inherits the repository default, so any injected step can push commits or mint releases from inside your own CI.
  • [MEDIUM] Enable Dependabot or Renovate - 7 manifest(s), no update bot configured. Without a bot a published advisory sits unpatched until someone audits by hand.
  • [MEDIUM] Pin the container base image by digest - Dockerfile - python:3.11, python:3.11-slim-bookworm. An untagged or mutable base means today's build and last month's contain different libc and a different CVE set, with no record of which shipped.
  • [MEDIUM] Gate pull requests on a dependency vulnerability scan - .github/workflows - no dependency scan in CI. This is the one gate that would catch a known-vulnerable package before it reaches a build.
  • [MEDIUM] Move large binaries to Git LFS or out of the repository - docs/images/skyvern_demo_video_v2.1.mp4 (89.3MB), zap1.gif (25.1MB) - 12 blobs over 5MB. Every clone and CI checkout pays for data nobody diffs.
  • [MEDIUM] Add a non-root USER to the image - Dockerfile - CMD or ENTRYPOINT with no USER directive. A process running as root in the container is root against every mounted volume.
  • [LOW] Set timeout-minutes on the workflow jobs - .github/workflows/auto-release.yml - 4 workflow(s) declare no job timeout. A wedged step runs to the six-hour platform default.

The Bottom Line

The repository delivers a functional AI-browser automation system with a usable no-code frontend and robust SDK. The LLM-vision approach genuinely reduces maintenance compared to XPath-based tools. However, the 6 medium-severity hygiene findings - particularly the mutable Docker base image, missing dependency scanning, and committed secrets in CI configs - represent real risks for production adoption. Teams comfortable with self-hosted AI infrastructure and willing to address the security configuration will find value here; others should evaluate managed alternatives until the CI/CD hygiene is resolved.