One Gita. Two ways to run it.

The web app talks to a Go API. A worker handles collection and background jobs, while a Go agent runs in each monitored Kubernetes cluster. The agent initiates a connection to the API and reconnects if that connection drops. The API does not need an inbound route to the agent or direct access to the cluster API.

PostgreSQL is connected to the API and worker within the installation; cluster agents do not connect to the database.

Both modes are intended to use the same application images and API contracts. The installation supplies the API address, database credentials, access settings and storage configuration.

The gita chart installs the platform. By default it reads the installation cluster and runs a PostgreSQL instance for evaluation; production installations should use an existing PostgreSQL service instead. The same chart, with the agent enabled and the platform disabled, connects additional clusters without installing another platform.

# Platform chart in a self-hosted cluster
web:
  enabled: true
localApi:
  enabled: true
  includeInstallationCluster: true   # monitor this cluster
worker:
  enabled: true
incidents:
  enabled: true
  embeddedPostgres:
    enabled: false                   # use an existing database
  databaseUrlSecretName: gita-database

# Same chart in each additional cluster
# web.enabled=false, localApi.enabled=false, worker.enabled=false
agent:
  enabled: true
  serverUrl: https://gita.example.com
  clusterId: production
  credentialsSecretName: gita-agent-token

A Secret holds the database connection (key url). The Connect a cluster guide registers each cluster at the platform, which issues its agent token and keeps only a hash of it.

1. 1

   Check the environment

   Confirm Kubernetes access, persistent storage, an address for the web app and API, and TLS. A preflight check should report missing requirements before installation.

2. 2

   Install the platform chart

   Install web, API and worker. Include an agent to monitor the installation cluster. Choose bundled PostgreSQL for evaluation or connect an existing database for production.

3. 3

   Finish setup in the interface

   Create the first administrator within 15 minutes of the API starting and confirm the cluster connection. The installation is usable without registering it with Gita Cloud.

4. 4

   Connect other clusters

   Open Connect a cluster, name the cluster and pick a namespace. The platform registers it and shows one command to paste into a terminal on that cluster; each agent initiates its own connection to this platform.

Retention starts with data the agent has collected. Increasing it later cannot recover Kubernetes events that were never captured. Backup retention is configured separately from application data retention.

A self-hosted installation will need a supported Kubernetes cluster, Helm, persistent storage, a reachable application address and TLS. The agent needs permissions for the features the administrator enables. Production deployments also need database backups, resource sizing and an upgrade process.

The local installation prototype has two permission levels. An organization role controls who manages people and prepares new cluster registration. A cluster role controls which existing clusters a member can use. The API checks the current account, organization, cluster and operation on every request.

An organization manager adds a person from one access screen: enter their email, choose an organization role, then select clusters and roles when they are a member. Existing local accounts receive access immediately. New accounts need a one-use invitation code shown to the manager for private sharing; it expires after 24 hours. The installation administrator can manage all organizations, but cannot change an organization owner. Write actions and terminals need the Operator role (or owner or organization admin) and run as the user's own Kubernetes identity; kubeconfig download remains restricted to the installation administrator. Cluster registration currently generates an operator guide; updating the central Secret and deploying the agent are manual steps.

This is an experimental local authorization model for Gita v5 evaluation, not a released cloud identity contract. Email verification, account recovery, MFA, identity migration and automated cluster provisioning still need product and operational decisions before external use.