Skip to content
apomesh

apomesh-orchestrator-bin

apomesh-orchestrator-bin is the assembly point: the daemon binary where everything the platform wires together happens. The apomesh-orchestrator library is wire-clean — it depends on no concrete strategy or vertical — and this binary is the one place that bridges them, constructing the SessionStrategyRegistry with both GenericStrategy (the goal-agnostic default) and DeepResearchStrategy (from the deep-research vertical) at boot. It is deliberately thin: assembly, not logic. Every behaviour it serves is delegated to the substrate and the orchestrator library; the binary chooses backends, injects dependencies, and starts the listeners. Touch it when you change how the daemon boots — a new store, a new registry, a new shipped seed, or the listener wiring.

Position in the workspace

Section titled “Position in the workspace”
  • Layer: orchestrator (the wiring seam where layers meet). See Control & execution planes.
  • Depends on: apomesh-orchestrator (the daemon library it assembles), apomesh-substrate (with the mcp feature — the primitives it constructs), apomesh-protocol (the gRPC service it serves), and apomesh-rest-api (the REST listener). Plus apomesh-config, apomesh-auth-providers, the Postgres and Redis state-store adapters, and apomesh-vertical-deep-research (the assembly point is where a vertical registers). apomesh-smartchat and apomesh-vertical-coding-assistant are feature-gated (smartchat is default-on; coding-assistant is opt-in).
  • Consumed by: nothing — it is a leaf binary, the workspace’s assembly point.

What it owns

Section titled “What it owns”

The boot sequence, as one straight-line narrative in main:

  1. Config — load the daemon TOML from APOMESH_CONFIG, else Config::default; validation runs at load, so a malformed config fails the daemon at boot rather than at first use. Per-tenant entries install into a TenantRegistry.
  2. Stores — select the StateStore backend from [statestore] (InMemory / Sqlite for single-binary dev, Postgres / Hybrid for durable deployments). The Postgres pool, captured once, is shared by every durable store below. A resolved embedding provider provisions the semantic-memory vector column to its own dimension.
  3. Registries — build the one per-tenant CredentialStore (sealed at rest on Postgres/Hybrid via a single shared SecretSealer), the LLM config / provider-profile stores, the store-backed provider router, the agent catalog, the runtime-token store, and the published-agent, strategy-config, and published-skill registries — each Postgres-backed when the state store is durable, in-memory otherwise.
  4. Seeds — seed the substrate-shipped strategy configs, published skills, and published Deep Research agent shapes into the dev tenant, and re-apply the shipped agent-catalog manifests. The shipped-seed posture is idempotent: a re-seed on restart against a durable registry hits VersionExists (the “already present” signal, skipped, not fatal); the catalog uses ON CONFLICT DO UPDATE; every other failure aborts boot.
  5. Daemon — assemble the OrchestratorDaemon via its builder, threading in the registry of coordinators (GenericStrategy, EvaluatorOptimizer, the parallel-sample and debate skeletons, DeepResearchStrategy), auth backends, every store, the provider router, the MCP primitives, and the extension-handler registry.
  6. Rehydrate — rehydrate_sessions scans the event log for sessions left non-terminal by a previous process and resumes each from its last checkpoint, before the daemon accepts traffic (best-effort; never blocks boot).
  7. Serve — start the gRPC listener (ApomeshDaemonServer, with the shared TLS material, concurrency limits, and the optional SmartChat sibling service) and the REST listener together under tokio::try_join!, which fails fast — the daemon never serves only one wire.

Public surface

Section titled “Public surface”

A binary has no library surface; its contract is the invocation and the config it reads.

  • Binary: apomesh-orchestrator (the [[bin]] name), from src/main.rs.
  • Flags / env (via clap): --listen / APOMESH_ORCHESTRATOR_LISTEN (gRPC, default 127.0.0.1:50051), --rest-listen / APOMESH_REST_LISTEN (REST + OpenAPI, default 127.0.0.1:50052), and --config / APOMESH_CONFIG (the daemon TOML).
  • Boot env surface — provider config (APOMESH_PROVIDER_CONFIG / APOMESH_PROVIDER_CONFIG_DIR), the secure-by-default secret-forwarding policy (APOMESH_SECRET_FORWARDING_HOP), and the workspace/sandbox knobs (APOMESH_WORKSPACE_ROOT, APOMESH_SHELL_SANDBOX). For the full, authoritative surface see the local stack and deploy/local/README.md.

Usage

Section titled “Usage”

The daemon runs as the orchestrator service in the local stack — the supported way to run it for evaluation:

Terminal window
cd deploy/local
docker compose up -d          # orchestrator on 50051 (gRPC) + 50052 (REST)

To run it directly against a local config during development:

Terminal window
# Default build (includes the smartchat feature).
APOMESH_CONFIG=deploy/local/config.dev.toml \
  cargo run -p apomesh-orchestrator-bin


# Substrate-only build, or with the coding-assistant vertical wired in.
cargo run -p apomesh-orchestrator-bin --no-default-features
cargo run -p apomesh-orchestrator-bin --features coding-assistant
Section titled “Related”