Architecture
See how the control plane, queued operations, sandboxes, custom domains, and runtime surfaces fit together.
Current product behavior
Product documentationThis repository is the control plane, not the AI CMS itself. It handles authentication, user management, sandbox provisioning, billing, domains, dashboard views, admin tooling, and the public website.
The backend is organized as a modular monolith with feature-first boundaries: `auth`, `sandboxes`, `domains`, `billing`, `provisioning`, `dashboard`, `website`, and `admin`.
Long-running infrastructure work is never executed directly in controllers. Actions such as sandbox lifecycle changes and custom-domain attachment are stored first and then executed by workers.
This queue-first design is why many user actions display loader states and temporarily hide conflicting controls.
Each sandbox gets its own filesystem area and exposes a public runtime plus an admin surface. The public site and `/upmin/` admin are separate concerns on the same sandbox origin.
Custom domains route to a shared edge and are internally authorized and mapped to the target sandbox.
The architecture explains why actions are asynchronous, why domain activation depends on DNS and queue state, and why limits are enforced centrally rather than per page.
It also explains why Nostate can provision isolated sandboxes quickly while keeping the control plane distinct from the content application running inside each sandbox.