Deploy Skyvern

Deploy and Host Skyvern on Railway

Skyvern is an open-source AI agent that operates a real browser for you. Give it a plain-English goal and it navigates sites, fills forms, downloads files and extracts data, using an LLM plus computer vision instead of brittle XPath selectors that break whenever a page changes.

About Hosting Skyvern

This template runs the four pieces Skyvern needs: a Postgres database, the API (which drives a headless Chromium under Xvfb), the React dashboard, and a small Caddy proxy that is the only service with a public domain. That single public origin is required rather than cosmetic: the dashboard mints its browser session through a same-origin request, so splitting the UI and API across two Railway domains breaks sign-in.

First boot is slow. The API image ships Playwright, Chromium and a full Tesseract language set, and it also runs database migrations and creates its organization before answering health checks, so allow several minutes. The dashboard waits for the API to mint its organization key and logs that it is waiting until it succeeds.

Common Use Cases

• Automating logins, form submissions and multi-step checkout flows across sites that offer no API
• Scraping structured data from pages whose markup changes often enough to break selector-based scrapers
• Running scheduled workflows that download invoices, statements or reports from vendor portals

Dependencies for Skyvern Hosting

• An LLM API key (required). Skyvern cannot run a task without one. The template is wired for OpenAI by default, so set OPENAI_API_KEY on the skyvern service. Anthropic, Gemini, Azure, Bedrock, OpenRouter, Groq and Ollama are supported by changing LLM_KEY and the matching ENABLE_* variable.
• A volume, provisioned automatically at /data on the skyvern service, holding artifacts, screenshots, recordings, browser sessions and the generated organization key.
• Memory. A headful Chromium is heavy. Expect to size the skyvern service well above a starter allocation for anything beyond light use.

Deployment Dependencies

• Skyvern on GitHub (AGPL-3.0)
• Skyvern documentation
• public.ecr.aws/skyvern/skyvern and public.ecr.aws/skyvern/skyvern-ui
• Supported LLM providers

Implementation Details

One public origin. Only the proxy service gets a domain. It routes by path, mirroring upstream's own Kubernetes ingress:

The /v1 route is not redundant. The dashboard strips a leading /api from its websocket and Runs API base URLs, so wss://host/api/v1 is actually dialled as wss://host/v1 and still has to reach the API.

Two handoffs that compose does with shared volumes. Upstream's docker-compose.yml bind-mounts the same host directories into both containers, which Railway cannot do because a volume attaches to exactly one service. Both moved onto the private network instead, served by a small Node script (Node is already present in the API image) started before the real entrypoint:

• Port 9090 replaces upstream's artifactServer.js so screenshots and recordings render in the dashboard. Unlike upstream's version, it resolves the caller-supplied ?path= against an allowlist of /data/artifacts, /data/videos and /data/har. This port is reachable through the public proxy, and an unguarded file server there would expose the organization API key sitting in /data/.skyvern/credentials.toml.
• Port 9091 hands the generated organization key to the dashboard, which polls for it at startup. It is never routed by the proxy, so it stays private to the project.

Ports are pinned. Railway probes health checks on the canonical PORT, while the API binds settings.PORT and the dashboard's localServer.js hardcodes 8080. Both services therefore set PORT explicitly so the probe and the process agree.

Credentials survive redeploys. SKYVERN_CREDENTIALS_FILE is moved onto the volume at /data/.skyvern/credentials.toml. At its default path the file would be lost on every redeploy, and the API would create a fresh organization each time while the dashboard kept using a stale key.

Why Deploy Skyvern on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying Skyvern on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.