School-GIT platform architecture
How the Express edge server, Next.js application server, Docker host, URL-backed stores, Web Bro application system and versioned OS shell fit together.
System flow
Browser requests School-GIT
Express accepts public traffic on :3000
Express-owned APIs execute directly
Next-owned routes proxy to Next.js on :3001
Next routes use URL-backed stores and Docker services
Desktop bootstraps the active immutable OS release
Source map
- server.js
- app/api/cdn/*
- components/cdn/*
- lib/cdn/apps/*
- lib/cdn/os/*
- lib/cdn/url-db/*
Architecture diagram
mermaidflowchart LR
Browser[Browser] --> Edge[Express :3000]
Edge -->|Express-owned APIs| ExpressAPI[Execute / files / logs / profile]
Edge -->|Next-owned routes| Next[Next.js :3001]
Next --> Apps[Web Bro APIs]
Next --> OS[OS release APIs]
Next --> URLDB[URL binary + metadata stores]
Apps --> Docker[Docker host]
OS --> OPFS[Browser OPFS version slots]
OPFS --> Desktop[School-GIT OS runtime]Two server layers, one public origin
Public traffic lands on the Express server. Express remains the edge/router and continues to own the APIs that are intentionally implemented in server.js, while Next.js owns the modern app-store, OS and UI routes.
The important rule is ownership: a route should have one authoritative implementation. Next-owned routes must not be rewritten back into Express from inside Next.js, because that creates a proxy loop.
- Legacy Express port 3000 was retired; RC and Next.js use the native RC launcher on port 3001.
- Next.js application port: 3001.
- Express-owned examples: execute, files, logs, container-status and profile.
- Next-owned examples: /api/cdn/apps/* and /api/cdn/os/*.
Storage and runtime layers
Small authenticated metadata and references are handled through the URL-backed record system. Large media, app files and OS release files use the URL binary store so the platform does not repeatedly push giant base64 payloads through ordinary JSON records.
Docker remains the isolated execution layer for project containers and Docker-backed Web Bro apps. Browser-side Web Bro runtime files are still verified against immutable package hashes before installation.
The desktop is now a release consumer
The desktop is no longer conceptually defined by whatever source file happened to hot-reload most recently. The stable bootstrap chooses an installed OS slot and loads its compiled runtime and CSS.
Development still uses Next.js HMR for fast iteration. Release behavior is separate: source edits become visible to installed users only after an OS release is built, published, installed and activated.