mipo
Architecture

How mipo is built

Traffic flows through Traefik to the manager and ingest nodes; the dispatcher orchestrates scans; one TimescaleDB cluster with three purpose-built schemas lives on an isolated network. The public website runs on separate infrastructure.

Topology

Edge, services, data — and a detached public site

Request path
Edge
Users / ScannersTraefik (TLS, routing, LB)
TLS terminates at Traefik; /scanner/* routes to ingest, everything else to manager.
Services
Manager (GUI + admin API)Ingest ×2 (scanner API)Dispatcher (orchestration)
Two APIs: session cookies for users, API keys for scanners.
Data
db (TimescaleDB cluster)config / results / jobs schemas
One TimescaleDB cluster with three schemas on an isolated internal network with no outbound internet; hypertables live only in the results schema.
Separate infrastructure
Public siteNot behind Traefik
mipo.network (Astro static)
The marketing/docs site deploys to separate infrastructure, NOT behind Traefik.

The public website (this site) is static HTML/CSS/JS deployed to its own host. It shares no runtime, no database, and no request path with the mipo application.

Services

What each container does

ServiceRole
managerGUI + admin API (session cookies). Single instance.
ingest ×2Scanner API (API keys): heartbeats, job dispatch, result collection.
dispatcherScan orchestration: resolves templates, batches jobs, reconciles stalls. Singleton.
traefikTLS termination, path routing, load balancing at the edge.
backupEncrypted database backup & restore; internal HTTP API.
dbOne TimescaleDB cluster (database mipo) with config / results / jobs schemas, on an isolated internal network. Hypertables live only in the results schema.
Deployment boundaries

Two Docker networks, isolated databases

external (mipo_external)

Bridge with outbound NAT. Traefik, manager, ingest, dispatcher, backup. Services that need internet or external-facing ports.

internal (mipo_internal)

Isolated, no outbound internet. The database cluster only — it cannot be reached from outside or reach out. Defense-in-depth.

Multi-network containers (manager, ingest, dispatcher, backup) bridge both: external for HTTP, internal for DB access.

Scanner lifecycle

Provision → heartbeat → dispatch → report → reconcile

  1. Provision — the manager generates a one-time install command; the scanner exchanges the token for a permanent API key.
  2. Heartbeat — every 60s the scanner reports liveness + system metrics to ingest; 2 minutes of silence marks it offline.
  3. Dispatch — the dispatcher fans fully-resolved jobs out to the right scanners (one job per scanner for groups).
  4. Report — scanners stream results back through ingest; scanners never write the database directly.
  5. Reconcile — a background reconciler flags stalled jobs and emits recovery events.

Read the architecture guide

A long-form reference covers the topology, request path, and trust boundaries in depth.

Architecture guide Security model