Install Gita in your cluster.

• A conformant Kubernetes cluster and a kubectl context with permission to create a namespace, cluster-wide RBAC and PersistentVolumeClaims, on amd64 or arm64 nodes. Tested with k3s 1.36 and k3d 1.35.
• Helm 3.14 or newer, which installs charts from OCI registries such as registry.gitlab.com/gita-public/releases.
• A default StorageClass. The chart requests 1 GiB for accounts and 2 GiB for the evaluation PostgreSQL.
• Outbound access to registry.gitlab.com to pull the images, or a mirror of them.

Resource requests are small: under 0.2 vCPU and about 300 MiB of memory for the whole installation at rest.

Run this from a terminal whose current kubectl context points at the cluster that will host Gita. It creates the gita namespace and waits until every component is ready.

helm upgrade --install gita oci://registry.gitlab.com/gita-public/releases/charts/gita \
  --version 0.1.0-beta.23-dev.23 -n gita --create-namespace --wait

The defaults install the whole of Gita, so the command carries no settings: images of the chart's own version, incidents and alerts with an evaluation PostgreSQL, Pod metrics and right-sizing, resource actions and terminals. Turn a feature off with --set, for example localApi.resourceActions.enabled=false for a read-only installation or localApi.terminal.podExec=false. The chart also generates the encryption key of the account store and the database password as Kubernetes Secrets.

When the install finishes, Helm prints these steps. Open the panel:

kubectl -n gita port-forward svc/gita-web 18080:80

Go to http://localhost:18080/register and sign up. No code is needed: the first account becomes the administrator of this installation and sees the cluster it runs in as Installation cluster. Later accounts start without access until an administrator invites them.

To keep a forgotten installation from being claimed by someone else, the first account can only be created in the 15 minutes after the API starts. If you miss it, restart the API to open a new window:

kubectl -n gita rollout restart deployment/gita-local-api

To give your team a real address, create the TLS Secret in the gita namespace first (for example with cert-manager), then install with the Ingress enabled. Replace the hostname and Secret name with yours.

helm upgrade --install gita oci://registry.gitlab.com/gita-public/releases/charts/gita \
  --version 0.1.0-beta.23-dev.23 -n gita --create-namespace \
  --set web.ingress.enabled=true --set localApi.allowIngress=true \
  --set-string web.ingress.host=gita.example.com \
  --set-string web.ingress.tlsSecretName=gita-tls --wait

With the Ingress, session cookies are marked Secure and the first account signs up at https://<your host>/register. Create it right after installing: the 15-minute window also applies here. Long-lived connections (live updates and the agent tunnel) need proxy timeouts of about one hour; on ingress-nginx set nginx.ingress.kubernetes.io/proxy-read-timeout: "3600" and the matching proxy-send-timeout through web.ingress.annotations.

In the panel, open Connect a cluster, name the cluster and choose a namespace. Gita registers it and gives you one command to paste into a terminal on the other cluster, already pointing at this chart and version. The agent opens an outbound connection to your panel, so the other cluster needs no inbound port and no shared kubeconfig.

When a new version is out, the panel shows Update available with the exact command and a link to its patch notes. It keeps your settings and moves to the images of the new chart version:

helm upgrade gita oci://registry.gitlab.com/gita-public/releases/charts/gita \
  --version <new version> -n gita --reset-then-reuse-values --wait

Back up the account PVC together with its encryption key Secret before upgrading: one without the other cannot be restored.

helm uninstall gita -n gita

Accounts, their encryption key and the database are kept on purpose, so a reinstall finds them again. To erase everything, delete the namespace with kubectl delete namespace gita; this cannot be undone.

• No account recovery, e-mail verification or MFA yet.
• The bundled PostgreSQL is for evaluation: one replica on a PVC, without backups. Use your own database for anything you need to keep.
• Accounts live in one API replica with its own volume; plan backups of that volume with its key.
• Port-forward access uses plain HTTP on your computer only. Use the Ingress with TLS for any shared access.