Skip to main content
This page covers day-two operations for the central platform and connected Kubernetes clusters or VMs.

Upgrade flow

For production-style environments:
  1. Review release notes and changed configuration keys.
  2. Confirm Postgres and Redis availability and capacity.
  3. Run service init jobs before starting updated services.
  4. Roll the management console, control plane, execution engine, and LLM gateway.
  5. Verify OIDC sign-in, workspace listing, agent connectivity, and a read-only run.
  6. Roll target agents separately when chart, package, or agent behavior changes.
Pin image tags during upgrades so deployments are reproducible. Control-plane rollouts keep the service available through multiple replicas. Connected agents reconnect to an available pod during the rollout, but commands that are already running can fail or time out and may need to be retried.

Durable state

Inspect durable state: Redis is used for coordination, rate limits, control-plane agent ownership, cross-pod command routing, and run event fanout. Postgres claims and leases are authoritative for automation scheduling and dispatch.

Health checks

Verify the platform from the outside in:
  • management console loads over TLS,
  • GET /api/v1/me works after sign-in,
  • OIDC callback returns to the management console,
  • a workspace can be created and listed,
  • target agents can connect over WebSocket,
  • a run streams events through GET /api/v1/runs/{runId}/stream,
  • the LLM gateway is ready with a fresh JWKS cache,
  • remote MCP server discovery and connection tests pass for configured servers,
  • webhooks record delivery attempts for subscribed events.
  • workspace automation diagnostics report no dispatch older than 30 seconds, scheduler lag over 60 seconds, stale approvals, or unexpected needs_review runs.
For production, keep component API docs disabled unless you intentionally expose them on a protected network.

Logs to inspect

Rate limits and budgets

Use both platform and gateway limits:
  • run max runtime,
  • max steps,
  • max tool calls,
  • duplicate tool-call cap,
  • max output tokens,
  • per-window LLM request limits,
  • per-window tool-call limits.
Keep read-write runs limited to roles and Kubernetes clusters where remediation is expected. VM troubleshooting runs are read-only.

Secret rotation

Rotate secrets with service-specific rollout plans: Do not reuse internal service tokens across environments.

Public route drift

Keep these routes consistent across deployment, OIDC provider settings, docs, and management console runtime config:
  • https://console.example.com/
  • https://api.example.com/api/v1
  • https://docs.acornops.dev/
  • wss://api.example.com/api/v1/agent/connect
Replace example.com with domains you control. The public demo uses https://console.demo.acornops.dev/ and https://api.demo.acornops.dev. Default OIDC settings use the console-host callback, such as https://console.example.com/api/v1/auth/oidc/callback, so browser session cookies are set on the console origin. If you override the redirect URI, update the provider allow-list and deployment config together. Root acornops.dev is reserved outside the platform API surface. Public documentation is served directly from docs.acornops.dev.