Skip to content
Forge Code

Architecture

Forge Code (terminal)
  ├─ model providers ─────────────► Anthropic, OpenAI, Google, xAI, Z.ai, Kimi, DeepSeek, OpenRouter
  ├─ AWS / Google Cloud SDKs ─────► Claude on Amazon Bedrock, Claude on Vertex AI
  ├─ Forge Cloud API (HTTPS) ─────► server/ (Node, Hono)
  │     ├─ Neon Postgres ........... users, tokens, usage, plans, sessions, schedules, shares, audit
  │     ├─ Neon Auth ............... accounts (managed Better Auth); the API verifies its JWTs
  │     ├─ Redis ................... rate limits, monthly counters, device codes, session event streams
  │     ├─ BullMQ (on Redis) ....... cloud-sessions and schedules queues, run by worker.js
  │     ├─ E2B ..................... one sandbox per cloud session
  │     ├─ Cloudflare R2 (S3 API) .. shares, teleports, session diffs
  │     ├─ Deepgram ................ speech-to-text for /voice
  │     └─ upstream model APIs ..... the AI proxy holds the keys and records usage
  └─ Relay (WebSocket) ───────────► relay/ (Cloudflare Worker + Durable Objects), one object per room


Cloudflare Pages
  ├─ site/ ...... this website: landing page, docs, marketplace (Astro + Starlight, static)
  └─ console/ ... the web app: account, cloud sessions, schedules, shares, Remote Control, admin (React + Vite)

Why each piece

Section titled “Why each piece”
  • Neon for Postgres with branching: each preview branch gets its own database and its own Neon Auth users.
  • Redis for counters and queues that must be fast, and BullMQ for retries, job schedulers and visibility.
  • E2B because cloud sessions run untrusted code and need a fresh, isolated machine each time.
  • Durable Objects because a Remote Control room needs one place where the terminal and its viewers meet, with WebSocket hibernation so idle rooms cost nothing.
  • R2 for transcripts and diffs, with no egress fees on share links.