Platform services

Every Zectre binary in the workspace — roles, default ports, and how they talk to each other.

The Zectre platform repo is a Cargo workspace of crates under crates/. Several compile to long-running daemons; others are libraries used by those daemons (zectre-common, zectre-container).

Runnable services (binaries)

ServiceRole
zectre-apiPublic REST API for apps, deployments, tasks, nodes, builds, artifacts, auth, metrics, webhooks, etc.
zectre-schedulerHTTP control plane for agents: node register/heartbeat, task assignment, deploy scheduling, cluster status. The API calls into it for orchestration.
zectre-agentRuns on each worker: executes tasks (Tish binary or Docker), reports to the scheduler over HTTP, exposes an HTTP actions server for pushed work, uploads logs to the API.
zectre-proxyUser-facing HTTP/HTTPS ingress: resolves Host → deployment/task using Postgres, forwards to task backends, cold-start wake calls to the API.
zectre-registryHTTP artifact store: upload/download by artifact id; content-addressed files on disk. Agents pull from here using URLs the scheduler/API provide.
zectre-buildHTTP build worker: accepts tarball/GitHub-sourced builds, runs the Tish compiler, registers artifacts.
zectre-catalogOptional HTTP service: GitHub OAuth, JWT/JWKS, orgs, cluster targets (api_base_url per context) for dashboard/CLI. Separate Postgres.

Default ports (from config/default.toml)

Exact values are configuration; local dev commonly uses the 47xxx range:

ServiceConfig sectionDefault portNotes
API[api]47080public_url is what agents and tools use in URLs.
Scheduler[scheduler]47091agent.scheduler_address points here.
Agent actions HTTP[agent]47092Scheduler pushes task actions to this port.
Proxy HTTP[proxy]47000Optional admin_port 47001.
Proxy HTTPS[proxy.tls]8443TLS listener when enabled.
Registry[registry]47082public_url may be set for remote agents.
Build[build]47083API forwards or references builds here.
Catalogenv / CLIoften 47100Not in the same TOML; typical dev choice.

Data and control flow (short)

  1. Operators hit zectre-api (CLI, dashboard, automation).
  2. Deployments create tasks in the DB; zectre-scheduler assigns them to nodes and POSTs actions to zectre-agent.
  3. Agents download artifacts from zectre-registry (or run Docker images), bind ports, and report host ports back so zectre-proxy can route.
  4. zectre-proxy reads routing tables (deployments.preview_url, routes, etc.) and connects clients to {node.address}:{task.port}.
  5. zectre-build produces binaries that end up referenced as artifacts for native workloads.

Shared libraries (not daemons)

CrateRole
zectre-commonConfig loading, DB pool, shared types, routing helpers.
zectre-containerDocker/runtime integration for the agent.

Further reading

  • Zectre API — REST routes on zectre-api plus HTTP surfaces on scheduler, registry, build, and catalog.
  • Architecture tour — diagram and mental model.
  • Operator docs in the repo: README.md, docs/LOCAL_DEVELOPMENT.md, docs/AUTH_CATALOG.md.