High-Level Architecture

At a high level, the platform is a native Rust host runtime that loads a selected customer app and the official modules that app depends on. The runtime is responsible for HTTP handling, service wiring, configuration, auth, caching, storage, rendering, background execution, and observability. The customer app contributes the deployable product shape: templates, theme assets, locale policy, chosen modules, capability bindings, and any customer-specific native or WASM extensions.

Every request begins by resolving which customer app and site configuration should handle it. Hostname, scheme, trusted proxy information, and request path determine the customer context. From there, middleware derives locale, region, currency, session, authenticated principal, and trace context before the request reaches an application handler. The system is designed so that handlers can assume this context has already been established instead of rediscovering it through ad hoc utility calls.

Core services sit underneath every execution path. The template engine renders pages and fragments using the customer app's theme and module-provided views. The authorization engine evaluates capabilities through the selected auth model and tuple data. The cache layer decides whether data or responses are public, locale-scoped, user-scoped, or uncacheable. The storage layer decides whether managed assets live in object storage, local-only sensitive storage, or private shared delivery modes. The SEO and i18n layers contribute canonical metadata, sitemap data, hreflang behavior, and locale formatting without each module reinventing them.

Official modules plug into this runtime through stable contracts. A CMS module can register routes, content services, admin resources, preview rules, and sitemap emitters. A commerce module can register catalog handlers, pricing services, checkout flows, and payment jobs. An events module can register resource types, timeslot logic, availability rendering, and booking workflows. These modules are native because they need full participation in transactions, rendering, auth checks, and background orchestration.

WASM sits at the edge of the architecture, not at the center. The runtime exposes explicit host APIs for approved extension points such as routes, widgets, jobs, metadata providers, webhook consumers, and pricing rules. A WASM extension may ask the host to check permissions, render a fragment, enqueue work, or request a storage action, but it does not receive raw access to auth tables, object-store credentials, or internal runtime state. This keeps customization possible without letting extensions become shadow copies of the platform.

The execution model is monolith first. The default architecture is one coherent runtime plus a set of backing services such as Postgres, Redis or Valkey, and S3-compatible storage. Jobs, events, and cache layers handle asynchronous or distributed concerns, but the platform does not assume a microservice fleet. That choice matches the problem shape: HTML-first customer applications with strong domain logic and a need for lower operational overhead than the current WordPress stack.