platform>docssolutionspricingcontact

Architecture tour

How clients, control plane, workers, and proxy line up — oriented for builders evaluating Zectre.

System sketch

                         ┌── control plane ─────────────────────────────┐
  zectre CLI /           │  zectre-api (REST)    zectre-scheduler      │
  dashboard  ──HTTP──▶   │  zectre-registry      zectre-build (opt.)   │
                         └───┬────────────────────────────────────────┘
                             │
  Per worker:                │
  zectre-agent ◀══HTTP══▶ zectre-scheduler   register, heartbeat,
                             │                 task actions (scheduler
                             │                 pushes to agent HTTP API)
                             │
  zectre-agent ──HTTP──▶ zectre-api          e.g. task log upload
 
  End users / apps ──▶ zectre-proxy ──▶ task backends (host:port from DB)

How traffic actually flows

  • Human clients (CLI, dashboard) talk to zectre-api over HTTP (REST/JSON) for projects, deployments, env, auth, etc.
  • Agents do not pair only with the API: they register and heartbeat against zectre-scheduler over HTTP, and the scheduler pushes work to an HTTP server on the agent (task start/stop and related actions).
  • The agent also calls the API for some operational paths (for example shipping logs to /api/v1/tasks/...).
  • zectre-proxy terminates user traffic, looks up routing metadata in Postgres (preview URLs, routes, app subdomains), and forwards to the live task address.

Responsibility cheat sheet

ComponentYou should think…
API“REST surface for operators and automation; owns much of the persisted platform model.”
Scheduler“Allocates work to nodes; drives agents over HTTP (register/heartbeat + pushed actions).”
Registry“Artifact storage referenced by deployments.”
Agent“Supervisor on a node: runs processes, reports state, obeys the scheduler.”
Proxy“HTTP ingress: resolves host → deployment/task from DB, then connects to {node.address}:{port}.”
Catalog (optional)“OAuth + JWT issuer the API trusts via JWKS.”

Why this shape

  • Separation of plan and run — API and scheduler decide what should run and where; agents enforce that it runs on their machine.
  • Artifact-centric deploys — Reproducible rollbacks and promotions when builds feed the registry.
  • Dynamic proxy — Tasks move between nodes; the proxy re-reads routing state instead of assuming fixed DNS only.

Next steps