Deploy Skyvern Browser Agent + Auth Gateway

Deploy and Host Skyvern on Railway

Skyvern automates browser based workflows with AI. Instead of brittle selector scripts, it drives a real Chromium with vision language models, reads the page the way a person would, and completes multi step tasks on sites that have no API. Give it a goal and a URL, and it fills forms, logs in, navigates, downloads files and extracts structured data, with a live view of the browser while it works.

About Hosting Skyvern

Hosting Skyvern means running three containers together: the Skyvern API server, which also carries the embedded Chromium on a virtual display, the prebuilt React dashboard, and PostgreSQL for tasks, workflows, runs and credentials. This template uses the official images pinned to the current release (public.ecr.aws/skyvern/skyvern:v1.0.53 and public.ecr.aws/skyvern/skyvern-ui:v1.0.53), attaches a volume to the Skyvern service at /data for artifacts, recordings, downloads, browser sessions and the encrypted credential vault, generates the JWT signing key and the database password, runs the Alembic migrations on boot, and wires the dashboard to the API over the generated Railway domain. No separate browser service is needed: Chromium runs inside the Skyvern container, exactly as the upstream compose file runs it.

Common Use Cases

• Form filling and data entry at scale: government portals, insurance quoting, supplier portals and other sites that never shipped an API
• Logged in workflows: sign in, navigate, download invoices or statements, with credentials kept in the built in encrypted vault and 2FA support
• Web data extraction: pull structured data out of pages that change layout often, without rewriting selectors
• Agentic QA and monitoring: run the same browser workflow on a schedule and get a recording, artifacts and a webhook callback for each run

Dependencies for Skyvern Hosting

• PostgreSQL: included in this template with a persistent volume
• An LLM provider API key: required. OpenAI is wired up by default; Anthropic, Gemini, Azure OpenAI, AWS Bedrock, OpenRouter, Groq and Ollama are all supported by changing two variables
• Object storage: optional, only if you want stored screenshots and recordings to render in the dashboard

Deployment Dependencies

• Skyvern self hosted Docker guide
• LLM configuration reference
• Artifact storage guide
• Skyvern GitHub repository

Implementation Details

The Skyvern service listens on PORT=8000, Railway probes /api/v1/heartbeat, and everything persistent lives under the single /data volume. The dashboard service serves the prebuilt bundle on port 8080 and injects the API addresses into it at container start. Key variables:

# Skyvern
DATABASE_STRING=postgresql+psycopg://${{Postgres.PGUSER}}:${{Postgres.POSTGRES_PASSWORD}}@${{Postgres.RAILWAY_PRIVATE_DOMAIN}}:5432/${{Postgres.PGDATABASE}}
SECRET_KEY=${{secret(48)}}
SKYVERN_CREDENTIALS_FILE=/data/.skyvern/credentials.toml
BROWSER_TYPE=chromium-headful
BROWSER_STREAMING_MODE=cdp
ENABLE_OPENAI=true
OPENAI_API_KEY=
LLM_KEY=OPENAI_GPT5_5

# Skyvern UI
SKYVERN_API_KEY=
SKYVERN_API_BASE_URL=https://${{Skyvern.RAILWAY_PUBLIC_DOMAIN}}/api/v1
VITE_API_BASE_URL=https://${{Skyvern.RAILWAY_PUBLIC_DOMAIN}}/api/v1
VITE_WSS_BASE_URL=wss://${{Skyvern.RAILWAY_PUBLIC_DOMAIN}}/api/v1

First steps after deploy:

1. Provide your OPENAI_API_KEY when Railway asks for it, then wait for the Skyvern service to go healthy. The first boot pulls a large image and runs database migrations.
2. Open the Skyvern service deploy logs and find the block headed ===== Skyvern API key. Copy the value inside cred="...". Skyvern generates this organization key on first boot and stores it on the volume, so it stays the same across redeploys.
3. Set SKYVERN_API_KEY on the Skyvern UI service to that value. The dashboard redeploys and is then ready to use.
4. Optional: set SKYVERN_PRINT_API_KEY=false on the Skyvern service so the key stops appearing in deploy logs.

One thing to know before you share the dashboard URL: the Skyvern open source UI has no user login, which upstream states plainly in its own Kubernetes notes. This template ships SKYVERN_API_KEY blank so a fresh deployment is inert until you set it, and the API itself rejects every request without a valid key. Once the dashboard is wired up, treat its URL as a credential, or remove its public domain and reach it through a tunnel or an authenticating proxy.

Two Railway specific notes. The Skyvern API binds IPv4 only, so the dashboard talks to it over the public HTTPS domain rather than private networking; that is already configured. And because Railway gives each service its own volume, the dashboard's file backed artifact viewer cannot see screenshots stored on the Skyvern volume. Live browser view and all run data work normally; set SKYVERN_STORAGE_TYPE=s3 (or gcs / azureblob) if you also want stored screenshots and recordings to render.

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 get the full three service stack from the official compose file with generated secrets, a persistent volume, health checks, managed SSL and a private database network, without building a browser capable container image yourself.