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

Client and admin routes accept scoped API keys, OIDC tokens, or the full-access bootstrap 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.

OIDC

Set REBUNO_OIDC_ISSUER and REBUNO_OIDC_AUDIENCE to accept JWTs from your identity provider. The kernel discovers the issuer’s signing keys on boot and rejects tokens with a different issuer or audience, so give each deployment its own audience. The caller is identified as user:<claim> from REBUNO_OIDC_USER_CLAIM, and its scopes are the union of those mapped to its groups:
"*" grants every scope. A user in no mapped group authenticates but is refused every route with 403 forbidden.

Access

--access / REBUNO_ACCESS_CONFIG names a file granting roles on each agent. Keys are agent IDs, with "*" applying to every agent; each role lists principals as user:<claim>, service:<api key id>, or group:<oidc group>:
A request needs both the route’s scope and a role on the agent. Listings return only agents the caller can read and their executions and approvals. With a file configured, API keys and OIDC users without a role on an agent are refused with 403 forbidden; without one, scopes alone decide. The bootstrap token holds every role, and agents keep access to their own executions. The kernel logs a warning on boot for agent IDs that are not registered.

Security log

The security log records who administered Rebuno and who was refused access to it. --security-log / REBUNO_SECURITY_LOG writes one JSON line per entry to stdout, stderr, or a file, which it appends to. Unset, the security log is off. Each entry carries time, the action as msg, and the acting principal (admin, service:<api key id>, user:<claim>, agent:<id>, or anonymous):
Entries are written after the action succeeds. Each replica writes its own. Write to a file on a persistent volume, or collect stdout with a log shipper: entries written to a container’s stdout are lost when the container is replaced.

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. An entry without a policy keeps the agent’s current one. 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.