Architecture overview

Miqro is one FastAPI service that serves many faces. A single backend (deployed as the miqroweb service) answers for every Miqro domain, and decides what to serve from the request's Host header. On top of that runs a fleet of AI agents that actually do the work — building sites, running support, handling billing, and operating each customer's business.

This page is the whole system in one read. The deeper pages drill into each part.

The shape of it

                         ┌─────────────────────────────┐
   Public visitors  ───▶ │  Marketing + published sites │  miqrodesign.com
                         │  (public, no auth)           │  miqromanage.com
                         └─────────────────────────────┘  customer domains
                                        │
                         "Sign in" deep-links to the one login
                                        ▼
                         ┌─────────────────────────────┐
   Owners / operators ─▶ │  The app / dashboards        │  miqromanage.app
                         │  (authenticated, SSO)        │  design.miqromanage.app
                         └─────────────────────────────┘  <tenant>.miqromanage.app
                                        │
                              drives & is operated by
                                        ▼
                         ┌─────────────────────────────┐
                         │  The AI agent fleet          │  intake · build · run
                         │  + connectors                │  support · billing · ops
                         └─────────────────────────────┘

Three kinds of host

Everything the platform serves is one of exactly three roles (details):

Role	Hosts	Auth
Identity / login	one backbone host (`miqromanage.app` today)	the single SSO origin
App / dashboards	`miqromanage.app`, `design.miqromanage.app`, `<tenant>.miqromanage.app`	authenticated
Marketing + public sites	`miqromanage.com`, `miqrodesign.com`, customer domains	public, never authenticates

A website and a dashboard are two different products for two different audiences, and they are never the same host. The dashboard reports on and operates the website; it is never the website itself.

One service, host-aware routing

There is no separate deployment per domain. A single middleware reads the incoming Host header and routes accordingly — serving the marketing landing, the published customer site, the app shell, the support desk, or (now) these developer docs. New products and new customers are subdomains of the one backbone, so SSO, sessions, and identity come for free with no new deployment.

The agent fleet

The product is not a static app — it is a team of AI agents that operate each customer's business. Agents handle intake, site building, support, billing, analytics, and operations. They read context from a shared journey ledger and act through connectors (Stripe, Gmail, Slack, HubSpot, and ~20 more).

Any action an agent takes that touches the outside world or money runs through an action queue with an approval gate: high-risk actions wait for the owner's sign-off before they execute. See The agent fleet.

The customer lifecycle: intake → build → run

The platform moves a customer through three phases, and the boundary between them is payment:

Intake (free) — a conversational strategist captures the brief. Always on free-tier providers; never spends paid model budget before payment.
Build (post-payment) — the site builder produces the site from the structured brief, using a deterministic template engine plus AI for content and brand.
Run (subscription) — the agent fleet operates the live business: support, bookings, billing, analytics, and connector-driven actions.

The paid gate is enforced by the Stripe webhook — paid model execution is never exposed over unauthenticated HTTP.

Tech at a glance

Backend: Python + FastAPI, one service, Host-header routing.
Data + auth: Supabase (Postgres + JWT). Row-level security scopes tenant data; a JWT's tenant_id decides what a signed-in user sees.
Frontend: a Vite-built SPA for the app/dashboards; server-rendered HTML (markdown → HTML, no build step) for marketing, support, and these docs.
Infra: deployed on Railway; secrets and per-tenant connector credentials are managed as service variables.
Payments: Stripe (checkout + webhooks).