Cerra Sites: one platform, independent applications

01 / Architecture

The current system architecture

Follow the solid connections below. The website, identity authority, deployment gateway, application data and capture processes are different parts of the system. A shared domain suffix does not mean a shared database or a shared browser session.

02 / Deployment

Where each part is deployed

The public URL identifies an entry point. Runtime ownership and release boundaries explain what actually changes when an application is published.

03 / Accounts

One account authority, separate application permissions

The existing CERRA account is the identity source for both platforms. A successful sign-in proves who the visitor is; site ownership, editor membership and module permissions determine what that person can do.

How shared sign-in works

1. 01

   Start from Sites

   Sites creates a random state and S256 PKCE challenge, then redirects the browser to the main platform’s authorization endpoint.

2. 02

   Use the existing CERRA login

   The main platform checks the enabled account and live session, then returns a short-lived, single-use authorization code to the fixed Sites callback.

3. 03

   Exchange on the server

   Sites validates state and exchanges the code with its verifier over an authenticated backchannel. The browser receives a Sites-specific Secure, HttpOnly, host-only cookie.

4. 04

   Check authorization on each request

   The gateway revalidates the grant with the main service and applies the current site policy. Account disablement, session expiry and changed permissions take effect without sharing a parent-domain cookie.

Signing out of the Sites console revokes its grant; signing out of the main CERRA session invalidates grants tied to that session. If the identity service cannot validate a protected request, access fails closed. Independent releases therefore still have an explicit availability dependency on the shared account service.

04 / Data

Where the databases and files live

Account sharing is an API relationship, not a database merge. These stores have separate owners, backup needs and recovery procedures. Cloudflare’s edge network does not make every database globally replicated.

05 / Design choices

Why take this route?

Managed ChatGPT Sites made the original product quick to build and publish, including server APIs and durable storage. The pressure now comes from CERRA’s growing mix of applications: frequent customer changes, persistent capture jobs, native dependencies and independent data lifecycles. The limitations below describe this deployment and workload fit, not every application built with ChatGPT.

What this makes possible

Boundaries and tradeoffs

06 / Migration

The Live Capture migration roadmap

This is the proposed next-stage plan, not a claim that Live Capture has moved. Keep the original path available while extracting one boundary at a time. Each step has an observable completion condition before the next ownership switch.

1. FoundationImplemented

   Shared identity and an independent application path

   Use the existing Sites gateway, scoped credentials, separate releases and private container example as the starting point. SHA demonstrates the hosting path; it is not the Live Capture replacement.

   • Keep main CERRA as the account authority; distinguish console management from private viewing.
   • Preserve hostname routing, tenant checks and source/build audit. SHA text assistance is available; photo/video detection remains disabled.
2. 01Planned

   Define the Live Capture module contract

   Document capture sources, ingest payloads, observation IDs, image hashes, review revisions, model versions, health signals and ownership. Separate collection, delivery, inference, storage and UI responsibilities.

   • Versioned ingest/read/review API; stable site and account IDs; local observation/receipt time versus cloud ingestion time; the camera clock is not verified.
   • Inventory all writers, local spools, cloud tables/objects and external services before migration.
3. 02Planned

   Move the dashboard behind a scoped service adapter

   Build the Live Capture dashboard as its own site first. A server-side adapter can read the existing service with explicit authorization while the original store remains authoritative. Browser code receives neither the main database binding nor service secrets.

   • Compare existing and new dashboard results, image access, history and revoked-user behavior.
   • Keep the original entry available and link to the new module through the main marketplace.
4. 03Planned

   Extract ingest, review and data storage

   Provision a dedicated module database and private object store after sizing. Cloudflare D1 plus R2 is one candidate; high-volume ingestion may require another database. Preserve IDs and attributed review history rather than rebuilding them from screenshots or aggregates.

   • Copy in bounded, resumable batches; verify schema, typed values, row counts, image hashes, references and review revisions.
   • Use a fenced capture or a validated change journal and replay process. D1 and R2 do not form one shared transaction; two ordinary exports are not automatically one consistent snapshot.
   • Produce a private, access-controlled backup and successfully restore it into isolated target storage before changing the authoritative writer. Verify the restored records, objects and permissions without activating live integrations.
   • A stopped collector does not prove all admitted cloud requests have finished. Require a verified drain, a storage write fence, or a consistent snapshot covering every writer.
   • Run shadow reads before switching the single authoritative writer. Avoid uncontrolled dual writes; replay failures idempotently.
5. 04Planned

   Package collection and inference as managed jobs

   Keep collectors on the existing workstation initially. Then package supported acquisition/inference services for an appropriate Linux or GPU runtime. Extend the current reviewed-app provider with worker supervision and job contracts before onboarding continuous capture.

   • Preserve the durable spool, stable delivery IDs, original timestamps, bounded retries and explicit coverage gaps.
   • Plan historical import for long pauses: current delivery archives observations older than 23 hours locally, while ordinary ingest rejects observations older than one day. Those archives are not automatically replayed; never rewrite their times to bypass validation.
   • Verify cancellation, concurrency limits, restart recovery, model availability and advancing capture plus delivery health.
   • Use queues and scheduled workflows for bounded tasks; use supervised services for continuous capture. A request callback is not a permanent background process.
6. 05Planned

   Cut over, observe and reuse the module pattern

   Switch a small, agreed scope first, monitor completeness and lag, and retain the old path for the defined recovery period. Reuse the same contracts for other dashboards and collection modules only after Live Capture meets its checks.

   • Acceptance covers ingestion lag, missing/duplicate observations, image integrity, review history, revoked access and recovery after restart.
   • Routing rollback and data rollback have separate procedures; replay any post-cutover writes before reverting storage authority.
   • Define backups, restore exercises, retention and capacity budgets. Broader VM access, per-customer runtime allocation and automatic domains remain later platform work.