Skyvern, self-hostable: three containers, five ports, AGPL-3.0, and one boundary self-hosting does not move.

Yes. The full agent runtime is open source under AGPL-3.0 at github.com/Skyvern-AI/skyvern. You can self-host either through pip (pip install skyvern, then skyvern quickstart) or through Docker Compose (git clone the repo, configure .env, run docker compose up -d). AGPL-3.0 lets you install, modify, and run it on your own hardware. The catch is the network-use clause: if you offer a modified Skyvern as a hosted service to other organizations, your modifications also have to be published under AGPL-3.0. For internal-only enterprise use, that clause does not bind you.

Three containers. (1) postgres:14-alpine, the bundled Postgres, with the credentials skyvern/skyvern/skyvern by default and persistent volume at /var/lib/postgresql/data/pgdata. (2) public.ecr.aws/skyvern/skyvern:latest, which is the API server plus a Playwright-driven Chromium tab in the same container, exposing 8000 (REST API), 6080 (noVNC WebSocket, watch the Actor live), and 9222 (CDP forwarding). (3) public.ecr.aws/skyvern/skyvern-ui:latest, the workflow builder web app, exposing 8080 (UI) and 9090 (artifact API). Two more services, Vaultwarden and a Bitwarden CLI REST server, ship commented out in the compose file for credential storage; uncomment them if you want vault integration on box.

The official documentation does not publish a hard minimum. In practice, every Actor step shoots a screenshot plus rendered DOM at a vision-capable LLM, so the heavy CPU and RAM costs sit at the inference provider, not your host. You need enough headroom for one headful Chromium per concurrent workflow plus a small Postgres, which lands at roughly 4 vCPU and 8 GB RAM as a comfortable floor for a single-user dev box. Concurrency scales linearly with Chromium instances. If you point Skyvern at a local Ollama model rather than a hosted API, your hardware floor jumps because inference now runs on your box too.

Four things, each named explicitly in the comparison above. (1) The anti-bot fabric: the layer that makes the headful Chromium session look like a real human session to fingerprinting checks. Not in the public repo, not in the public ECR image. (2) The residential proxy network with country, state, city, and ISP targeting. Self-hosted runs from your egress IP. (3) Integrated CAPTCHA solving across image, audio, hCaptcha, reCAPTCHA, and Cloudflare Turnstile. Self-hosted hits a CAPTCHA and stops. (4) The credit-billed concurrency, plan-bounded run history, and managed audit log retention. Self-hosted, you keep whatever your host and Postgres retention allow. The agent loop itself, including all three agents and the full LLM provider list, is identical.

Yes, the runtime supports Ollama and any OpenAI-compatible local endpoint (the Skyvern repo ships env.ollama.example as a starting point). You set ENABLE_OLLAMA=true in .env, point it at the Ollama host, and the Planner-Actor-Validator loop runs through the local model. Two practical caveats. First, the vision pass on every step is the throughput bottleneck; small local vision models take seconds per step where a hosted Sonnet-class model takes a fraction of a second, and that compounds across long workflows. Second, hardened sites that lean heavily on anti-bot tooling will still trip on the missing cloud-only fabric, regardless of which model you swapped in.

At minimum: an LLM provider toggle and the matching API key (ENABLE_OPENAI=true plus OPENAI_API_KEY, or the equivalent for Anthropic, Bedrock, Gemini, Azure OpenAI, OpenRouter, Groq, or Ollama). DATABASE_STRING is pre-filled to point at the bundled postgres service. BROWSER_TYPE=chromium-headful is the default and rarely needs changing. ENABLE_CODE_BLOCK=true if you want workflows to run custom code blocks. If you wire in Bitwarden vault integration, the matching BWS_ACCESS_TOKEN and vault host. The repo ships .env.example, env.litellm.example, and env.ollama.example as three working starting points; copy whichever matches your provider, then layer your keys on top.

On Docker, docker compose pull then docker compose up -d. The compose file pins both skyvern and skyvern-ui to the :latest tag, so a pull always grabs the most recent public ECR image. The latest tag at the time of writing is v1.0.34 (released 7 May 2026). On pip, pip install --upgrade skyvern. Migrations run on container start; the bundled Postgres volume is preserved across restarts. If you have pinned a specific version in your fork, pin the tag explicitly in docker-compose.yml (for example public.ecr.aws/skyvern/skyvern:v1.0.34) and bump deliberately rather than tracking latest in production.

Inside the postgres container by default; the compose file mounts ./postgres-data on the host as the persistent volume for postgres data, which means your workflow definitions and run records survive container rebuilds. Skyvern artifacts (screenshots, DOM snapshots, downloaded files) are exposed via the artifact API on port 9090 and stored under the skyvern container's volume. If you want to back them up out of process, mount that directory to a host path or to S3 via a sidecar. The pip install path puts SQLite at ~/.skyvern/data.db (as of v1.0.31+) instead of Postgres, which is fine for a single user but not for shared deployments.

No, and this is the boundary self-hosting does not move. Self-hosted Skyvern is still Playwright driving a Chromium tab. The Actor scores elements rendered inside that tab; the Validator reads a screenshot of that tab. A SAP GUI window is a Win32 process that publishes its UI through Microsoft UI Automation, not through the Chromium DOM. An Oracle Forms session is the same. A Jack Henry or Fiserv green-screen terminal is the same. An Epic Hyperspace patient chart inside Citrix renders pixels the agent can see and an accessibility tree the agent cannot read from inside a browser. Self-hosting moves the data plane onto your hardware; it does not change the surface the agent loop reads. For workflows that leave the browser tab, the natural unit of work is wall-clock time on Windows accessibility APIs, not browser-execution credits.

Three honest cases. (1) Data residency: your workflow operates on data that cannot leave your VPC, so the screenshots and DOM snapshots cannot reach a third-party host. (2) Cost predictability at high volume: you have a workflow that runs millions of steps a month and the credit math for the cloud tier is worse than your own infra plus inference bill. (3) Custom fork: you need to modify the agent loop itself, ship a Validator behavior the open core does not have, or integrate a private model. Outside those three, the cloud product's bundled anti-bot, proxies, and CAPTCHA solving are usually worth more than the infra savings, especially for any workflow that touches a hardened portal.