Architecture

d6e’s boundaries are simple: workspace data and AI execution live on the instance, accounts and OAuth registration live on the central site, and UI / your own backends live on your side.

Trust boundaries

flowchart TB
  subgraph you["You own"]
    client["Custom FE / scripts / local AI agents"]
    creds["Cookies · API keys · user tokens<br/>No client secret"]
  end

  subgraph inst["Instance (your infrastructure)"]
    proxy["Reverse proxy (one origin)"]
    rust["/api/v1/* → Rust API"]
    consoleApi["/api/* → Console API"]
    mcp["/mcp → MCP ~96 tools"]
    ui["/* → Console UI"]
    data["PostgreSQL · files · secrets<br/>Policy · audit · membership"]
    proxy --> rust
    proxy --> consoleApi
    proxy --> mcp
    proxy --> ui
    rust --> data
  end

  subgraph central["Central site www.d6e.ai"]
    auth["Accounts · login · OAuth / redirect URIs<br/>Never sees workspace contents"]
  end

  you -->|"HTTPS"| inst
  inst -->|"Auth brokerage only"| central

Text version (ASCII)

┌─ You own ───────────────────────────────────────────────────┐
│  Custom FE / scripts / local AI agents                      │
│  · Session cookies (FE)                                     │
│  · API keys (d6e_…) or user tokens                          │
│  · No client secret (OAuth is brokered by the instance)     │
└───────────────────────────────┬─────────────────────────────┘
                                │ HTTPS
┌─ Instance (your infrastructure)┴────────────────────────────┐
│  Reverse proxy (one origin)                                 │
│   ├─ /api/v1/*     → Rust API (SQL / STF / files / SaaS…)   │
│   ├─ /api/*        → Console-side API (chat, …)             │
│   ├─ /mcp (:8081)  → MCP server (~96 d6e_* tools)           │
│   └─ /*            → Console UI                             │
│  PostgreSQL (user_data) / file storage / encrypted secrets  │
│  Policy enforcement · audit logs · membership               │
└─────────────────────────────────────────────────────────────┘
                                │ Auth brokerage only
┌─ Central site www.d6e.ai ───────────────────────────────────┐
│  Accounts · login · OAuth clients / redirect URIs           │
│  Never sees workspace contents                              │
└─────────────────────────────────────────────────────────────┘

Two API surfaces on one origin

A single D6E_BASE_URL origin exposes two API surfaces, path-routed:

Path	Implementation	Main uses
`/api/v1/*`	Rust (Axum)	SQL, files, STFs, workflows, policies, SaaS proxy, embeddings
`/api/*` (non-v1)	Console (SvelteKit)	Chat sessions, `execute-by-intent`, UI-oriented routes

From the outside it is one host. Custom frontends and local AI agents both point at that host.

Authentication skeleton

Redirect the browser to https://www.d6e.ai/auth/login (with redirect_uri)
POST the authorization code to the instance POST /api/v1/auth/token
The instance brokers the exchange with the central site and returns tokens scoped to the instance audience
Call /api/v1/* with Authorization: Bearer … (and X-Workspace-ID when required)

Frontends never hold a client secret. Register production callback URLs in d6e-auth (franchise portal or workspace settings). Loopback/localhost URLs need no registration.

For local development, the fastest path is an API key (d6e_…) issued from the console.

Plugins vs custom frontends

	Plugin	Custom frontend
What it is	A `template.yaml` package of workspace contents (prompts, STFs, workflows, files)	An independent web app that uses a workspace
Where it lives	Inside the instance	Outside the instance
UI	Via console / chat	It is the UI

They extend opposite sides of the same API boundary and combine naturally. See Custom frontend and Plugin development.

Architecture

Trust boundaries

Two API surfaces on one origin

Authentication skeleton

Plugins vs custom frontends

Source material