← Back to docs

How Dawvia fits together: the Cursor extension, backend daemon, unified Portal and developer Console, plus the isolation invariants that keep marketing, app and admin surfaces apart.

Architecture overview

Dawvia is built from a few clearly separated pieces. Each one owns a single job and talks to the others across stable, versioned boundaries, so you can deploy, scale and reason about them independently.

Core components

  • Cursor extension — the in-IDE surface. It drives account switching, launches

tasks and worktrees, and connects your editor to the account pool. Start here with the getting started guide.

  • Backend daemon — a single Go process that exposes the /api/* surface, brokers

the account pool and applies quota balancing. It is a pure backend and never serves the website itself.

  • Unified Portal — the public site on your own domain. One deployment stitches

marketing, authentication, the personal area, enterprise management and platform administration together behind path prefixes.

  • Developer Console — the hash-routed operator surface served under a /console

prefix, shipped as a build that is physically separate from the Portal.

  • Mobile app — iOS and Android clients that reuse the same identity and APIs for

tasks, connections and notifications on the go.

Isolation invariants

A handful of invariants are enforced in code and at build time, not left to convention:

  • The Portal never registers a route under /console; the two are separate artifacts

that a reverse proxy joins at the edge.

  • The Portal depends only on the identity session, never on Console-internal tokens.
  • Personal, enterprise and platform areas require a valid identity session; anonymous

visits are redirected to sign in.

  • Marketing and docs are indexable, while application and admin surfaces are noindex

so sensitive pages never reach search engines. The full boundary model lives in security & compliance.

Request path

Browser -> Reverse proxy -> Portal   (static: marketing, auth, /app, /org, /platform)
                         -> Console  (operator SPA under /console)
                         -> Backend daemon (/api/*)

The reverse proxy is the only component that sees every prefix. Everything behind it can be built, released and rolled back on its own schedule.

Deployment topology

  • Local, one command — the install script builds the site, daemon and extension,

then serves everything behind a local reverse proxy so the homepage is reachable at once.

  • Standalone site — the Portal generates to fully static files and can be hosted on

any static server or CDN, independently of the backend.

  • Server — a deploy script builds the static site plus the daemon and publishes

them together, with a web-only mode for zero-downtime content updates.

Read the deployment guide for the exact commands, and the remote console doc to observe a running stack.

Next steps