Skip to content

Repository navigation

deployment.md

Latest commit

 

History

History
100 lines (75 loc) · 7.71 KB

deployment.md

File metadata and controls

100 lines (75 loc) · 7.71 KB
Raw
title About deployment options
description Compare the ways you can host the Central Agentic Ops dashboard, and choose the option that fits your data, audience, and infrastructure.

Warning

Experimental: All deployment options are experimental. Interfaces, configuration names, infrastructure templates, and procedures can change between releases without a migration path. No option is certified for production use. Before you expose a deployment to real users or data, complete your own security, compliance, privacy, network, monitoring, incident-response, and rollback reviews.

The control plane and dashboard are deployed separately. The control plane runs in GitHub Actions; this guide compares where to serve the dashboard and run its queries.

Choosing a deployment option never changes campaign policy, rollout mode, credentials, or target authority. Those settings stay in the reviewed .github/workflows/cao.json file in your control repository. For more information, see Control policy and Roll out a campaign.

Comparing the options

Dashboard hosting and collection credentials are separate choices. Pages can use the built-in workflow token for bounded monitoring, or Apps/PATs when required. Server-backed deployments use PostgreSQL for dashboard entities, queries, and operational state by default. Azure still pairs PostgreSQL with Azure Managed Redis for operational state; other hosts can explicitly select a compatible Redis provider such as Upstash.

Option Dashboard host Where queries run Who can sign in Infrastructure you operate
GitHub Actions only GitHub Pages In each viewer's browser Anyone who can read the Pages site No application server; collection credentials depend on the exact scope
Azure Azure Functions On the server, over PostgreSQL Members of allowed GitHub organizations or teams Function App, PostgreSQL, Key Vault, Azure Managed Redis, storage account, and Application Insights

Choosing an option

  1. Start with GitHub Actions only. It needs no infrastructure beyond your control repository and is what the supported CAO installer configures by default. If you don't have a control repository yet, follow Set Up CAO first.
  2. Choose collection credentials for the scope. Monitoring the control repository and confirmed public targets needs no App/PAT setup. Prefer private GitHub Apps for durable cross-repository access; use fine-grained PATs only when eligible and explicitly accepted. See Choosing a credential profile.
  3. Move to a server-backed option only when you need to. Choose Azure when your data is too large to query in a browser, when you need per-user sign-in instead of Pages visibility, or when you need webhook-driven refresh.

Azure runs the host-neutral Go service from the server/ directory, with authentication, authorization, cross-site request forgery (CSRF), webhook, rate-limit, and logging protections. You can also deploy that service on your own container platform; you are responsible for secret management, ingress, and delivery.

Server-backed means the Go server serves the dashboard itself. Built HTML and assets, GitHub sign-in, query APIs, and revision events use the same hosted origin. Forward the entire application to the Go handler, not just API paths. Do not publish a separate Pages or static-hosted frontend for hosted mode. The browser uses server-side PostgreSQL queries; a hosted failure does not switch to browser storage or the Pages deployment.

Use the one-minute managed Redis guide to connect AWS ElastiCache, Redis Cloud, GCP Memorystore, Railway, Render, or DigitalOcean. The same provider-neutral cao.json host contract also defines the local Redis, Azure, and Upstash examples.

Using Upstash Redis

Upstash Redis is a managed Redis option for the host-neutral Go server. Upstash doesn't host the CAO application. Run the container on your application platform, provide its verified artifact there, and configure the server to use the Upstash TLS Redis endpoint.

Note

Your credential profile still matters for server-backed deployments. The CAO Activity workflow collects their evidence in GitHub Actions, using the profile that you configure. Dashboard users sign in separately, through a GitHub OAuth app. The optional Azure collection profile requires a GitHub App and doesn't support PATs.

About the shared data flow

Every option uses the canonical evidence model, not a separate dashboard data format. Data ingestion owns the collection, verified payload, retention, and backend-processing details; Data model owns entities and identities. The optional Azure collection profile uses server-side workers driven by GitHub App webhooks instead of relying only on scheduled Activity snapshots.

What every option guarantees

  • Evidence is not authority. Viewing a result grants no execution or write permission. Pages is read-only; optional canvas commands and hosted CLI actions have separate authorization and approval requirements. See Know the boundary.
  • Rebuildable dashboard data. Browser IndexedDB and canonical PostgreSQL hold derived evidence projections. Protected operational state such as audit history, queues, and revocation records is separate and must not be treated as a disposable cache. See the operational-storage contract.
  • Verified payloads. Each payload file is checked against payload-hashes.json before it is parsed. A missing manifest, a hash mismatch, an unsafe path, or a malformed record stops ingestion.
  • No exposed secrets. Secrets never appear in the dashboard site, API responses, URLs, or logs.

What no option guarantees

  • Live data. The dashboard is not a live feed. Its data is only as fresh as the last Activity run and the last dashboard rebuild or ingestion.
  • Availability. CAO adds no availability service-level agreement (SLA), backup service, or disaster-recovery objective beyond what the underlying platform provides.
  • Compliance records. The dashboard is not a compliance record. For compliance evidence, use GitHub Actions run history, your checked-in policy, your infrastructure definitions, and platform audit logs.
  • Automatic workflow control. Evidence and recommendations do not stop or govern workflows. To stop campaigns, follow Emergency stop.

Next steps

Further reading