BrowserPod headers activeServer-only LLM keysFallback preserved

The current build supports Gemini, Groq, Auto, and deterministic fallback modes. LLM output is treated as untrusted until BrowserPod writes files, runs the allowed command, and returns proof.

Execution settings

NEXT_PUBLIC_BROWSERPOD_API_KEY in .env.local for client-side BrowserPod boot.

Local env

GEMINI_API_KEY and GEMINI_MODEL are read only by server routes.

Server-side

GROQ_API_KEY and GROQ_MODEL are read only by server routes.

Server-side

Runs the first generated variant in BrowserPod and keeps the others generated but queued.

Default

Attempts one BrowserPod run per selected variant and reports each result independently.

Optional

Required for SharedArrayBuffer and BrowserPod cross-origin isolation.

Configured

cross-origin-isolated=(self) must remain applied to app routes.

Set

ForkLab chooses commands. LLM output cannot request shell execution.

Locked

Security guarantees

Generated code is written only to approved BrowserPod paths
LLM keys are never exposed through NEXT_PUBLIC variables
BrowserPod runtime output is shown directly in terminal panels
No host filesystem execution for generated projects
Fallback patches and variants are marked honestly
Portal links are captured only when BrowserPod reports them
Current Scope

Routes used for the final workflow

Arena - GitHub-style sandbox issuesLive
Live - prompt-driven variant generation and BrowserPod previewLive
Workbench - enterprise agent workflow with proofLive
Smoke - BrowserPod runtime and portal verificationLive
Settings - deployment readiness and environment checksLive
How It Works - product workflow overview and demo guideLive

Deployment checklist

Vercel env vars configured
BrowserPod key allows deployed origin
Gemini key server-side only
.env.local not committed
npm run build passes
crossOriginIsolated headers set correctly