Skip to content

Architecture

Understand how Aster’s public docs differ from its browser app surface.

Two different web surfaces

Aster now has two distinct browser-facing packages:

  • products/web is the product UI that hosts the app experience in the browser.
  • products/docs is the public docs site.

That split matters because the requirements are different.

products/web needs runtime bootstrap, gateway proxying, and shared application state with @aster/app. The docs site needs stable content routing, search, reference rendering, and a predictable publish/build pipeline.

Why not restyle products/web?

Because the public docs problem is mostly information architecture, not just paint. The opencode approach works well because the docs package is its own Astro + Starlight surface with a narrow purpose.

Keeping the docs site separate gives us:

  • isolated build tooling
  • stable content paths
  • generated reference artifacts in the built output
  • no risk of coupling docs routing to product runtime state

What remains shared

The docs site still reuses Aster branding and still documents the same runtime. The split is about delivery and maintenance, not about creating a second product.