Open Sites

The open-source alternative to ChatGPT Sites: vibe-code internal apps, deploy them on your infrastructure, behind your identity provider.

Codex Sites proved the industry needs this: employees describe an internal tool, an agent builds it, and it's instantly hosted behind workspace login. But Sites locks all three layers — you build in ChatGPT, authenticate with ChatGPT workspace identity, and host on OpenAI-operated infrastructure.

Open Sites keeps the part that makes Sites brilliant — the constrained, sandboxed app contract — and opens everything else:

Layer	ChatGPT Sites	Open Sites
Coding agent	Codex only	Any — Claude Code, Codex, Cursor… (opensites deploy)
Identity / RBAC	ChatGPT workspace	Your IdP — Google Workspace, Entra ID, Okta… (any OIDC)
Hosting	OpenAI-operated	Your infra — a single Node process + workerd
App contract	Workers-compatible ES modules	The same contract — Sites apps run here unchanged
License	Proprietary	Apache-2.0

How it works

vibe-coded app  ──opensites deploy──▶  ┌────────────── Gateway ──────────────┐
(any coding agent)                     │ • OIDC login (Google Workspace, …)  │
                                       │ • per-app access policy             │
                  employee ──────────▶ │ • identity injected into requests   │
                                       └──────────────┬──────────────────────┘
                                                      ▼
                                       workerd — each app in a V8 isolate
                                       (no filesystem, no process, no peeking)

• Gateway (src/gateway.js) — identity-aware reverse proxy. Handles SSO, enforces per-app policies (private / workspace-wide / specific people), and injects the signed-in user as x-opensites-user-* headers so every app gets authentication for free.
• Runtime (src/runtime.js) — runs apps with workerd, Cloudflare's open-source Workers runtime: each app is sealed in a V8 isolate. A plain-Node engine is available as a fallback (OPENSITES_RUNTIME=node); the app contract is identical either way.
• CLI (cli/opensites.js) — opensites deploy <dir> bundles the app with esbuild and pushes it. Works from any terminal, which means any coding agent.

An app is just an ES module exporting fetch(request, env) plus an opensites.json manifest. See demo-app/.

Quickstart — deploy to an existing instance

Nothing to clone; you just need Node:

npx opensites init my-app --owner you@company.com
npx opensites deploy my-app --gateway https://<your-instance> --token <deploy-token>

Open the printed URL — you'll be asked to sign in with your company IdP.

Quickstart — run your own instance

git clone <repo> && cd opensites && npm install
npm start                                # gateway on http://localhost:8788 (mock IdP)
node cli/opensites.js deploy ./demo-app  # deploy the sample app

Open http://localhost:8788 — sign in, open the app, change who can access it. docker-compose up runs the same thing with a seeded Keycloak as the IdP.

Real Google Workspace SSO

Create an OAuth client (Web application, redirect URI http://localhost:8788/auth/callback), then:

GOOGLE_CLIENT_ID=… GOOGLE_CLIENT_SECRET=… npm start

POC scope vs. roadmap

This is a hackathon proof of concept. Real, working: the full loop (deploy → SSO → RBAC → sandboxed execution), Google OIDC, workerd isolation, live policy editing.

Deliberately deferred:

• Durable data — D1-equivalent SQLite and R2-equivalent S3/MinIO bindings per app
• More IdPs — Entra ID, Okta, generic OIDC discovery; group-based policies via the IdP's directory API
• Versioning — save-vs-deploy split, rollbacks, preview URLs (Sites' git-commit model)
• ID token verification, secrets manager, audit log, per-app subdomains
• Agent skill — a packaged skill teaching coding agents the contract end-to-end

Business model (Odoo-style)

Community edition: this repo, self-hosted, Apache-2.0, forever. Enterprise edition: managed hosting, SCIM provisioning, audit/compliance, app catalog, SLAs.