Skip to main content

Dev and server modes

rebuno dev runs entirely in memory with auth disabled. It is for local development only, and nothing persists across restarts. rebuno server is the production kernel. It requires Postgres and a bearer token and refuses to start without them:
The schema is applied from embedded migrations on boot. The HTTP API is stateless, so you scale by running more replicas behind a load balancer. Postgres is the only coordination point, and singleton background work (approval expiry, execution deadlines, cleanup) is leader-elected through a Postgres advisory lock.

Authentication

All client and admin routes require the bearer token:
Both SDK clients read the token from REBUNO_API_KEY if you do not pass it explicitly. Agent routes do not use the bearer token at all. They authenticate with HMAC over the agent’s registered secret. See Authentication.

Provisioning agents

Register agents and their policies declaratively with --config, a manifest both dev and server load on boot and upsert. See examples/rebuno.dev.yaml:
policy_file paths resolve relative to the manifest. A malformed bundle fails the boot, so a broken policy never falls back to permissive. You can also register agents and load policy at runtime over the admin API.

Configuration

Server flags and their environment-variable equivalents: Additional environment-only settings:

Load balancer

Set the balancer’s read timeout below the client’s, so it fails over to another replica before the client gives up. Both SDK clients default to 35 seconds. Point pool health checks at /v0/ready, which returns 503 when a dependency is down; /v0/health answers ok regardless.
Execution streams (GET /v0/executions/{id}/stream) are server-sent events. The kernel sets X-Accel-Buffering: no; a balancer that ignores it needs response buffering disabled for that path.

Docker

The image is built from deploy/Dockerfile and published to ghcr.io/rebuno/rebuno on tagged releases. Its entrypoint is rebuno server, so pass configuration as flags or REBUNO_* environment variables:

Observability

  • Tracing (OpenTelemetry): every API request and dispatch attempt, correlated by execution_id and step_id. Enable with --otel-endpoint.
  • Metrics (Prometheus): scrape /metrics for execution counts by status, dispatch attempts, queue depth, approval wait times, replay-hit rate, and policy latency.
  • Logging: structured, with execution_id and step_id correlation.