Contents

Team server Enterprise

On one machine, gitta sees every agent. When agents work on different laptops, CI runners or cloud machines, a team server connects them. It runs in your own cloud account.

Laptops, a CI runner and a cloud agent send reports to two team servers in your own cloud and get warnings back. An identity provider signs people in. LaptopClaude Code, 3 agents DesktopCursor, 2 agents CI runnerrunner token Cloud agent VMCodex, headless Your cloud account Team server 1zone a · HTTPS Team server 2zone b · HTTPS Kubernetes, or a unikernel VM onGoogle Cloud, AWS or Azure warning IdentityproviderOkta, Entra ID
Every machine reports to every server. Each server knows the whole team, so either one can answer.

How it works

At each agent step, gitta on the machine sends the agent's changed files to the team servers. It sends the file as it was at the agent's start and as it is now. The server compares that with the reports from every other machine and returns the warnings for this agent. The agent sees them in its session, marked Gitta (team).

 In a Claude Code session on desktop-2
Gitta (team): agent detect-language on laptop-1, working in parallel, changed `app.translate.translate`, which your new code in app/api/translate.py uses (high severity). Keep your code compatible with their change, or coordinate before landing.

Security warnings travel the same way. When an agent on one machine weakens a security control and an agent on another machine has new code that calls it, both get a Gitta (team): SECURITY (high severity) warning, and the team view shows it.

The report takes about 20 to 40 ms from a laptop to a server in the same region. If no server answers, the agent continues and gets the warnings from its own machine only.

Connect a repository

After the servers run, connect each repository on each machine. Use all server addresses, separated by commas.

 Terminal
$ gitta init --server https://gitta-1.example.com,https://gitta-2.example.com --token gt1_…
gitta is set up in microblog.

No agent worktrees exist yet. Every worktree an agent tool creates from now on is picked up on its own.
After every step an agent takes, gitta looks at what it changed. When one agent changes a function that another agent's new code calls, gitta tells that agent right away, so it can adapt before anything reaches main.
Merging works as always, with git merge, git pull or git push. No test command is set, so gitta runs no tests during a merge yet. Add one with `gitta init --gate "<your test command>"`.
Claude Code hooks already installed.
Team server https://gitta-1.example.com,https://gitta-2.example.com. Agents on other machines are included in the warnings.
When gitta tells an agent about a clash, the agent fixes its code itself and mentions it to you in one sentence in its chat.
gitta never asks you anything. When a merge removes tests or weakens a security check, it says so in the merge output and in the log. The merge goes ahead unless the committed .gitta.toml sets weakened_checks to block.
To share the test command and rules with your team and the CI check, run `gitta init --team` and commit .gitta.toml.

Start your agents the way you always do. `gitta watch` shows what gitta does as it happens, and `tail -f .gitta/gitta.log` follows the same story as plain lines.

With SSO, people run gitta login instead. See Tokens and sign-in. CI runners and cloud agents use the environment variables GITTA_SERVER and GITTA_SERVER_TOKEN.

Team view

Open a server's address in a browser and sign in with an admin or personal token. The page shows each agent, the person and machine behind it, its changed files and the current warnings. It updates every five seconds.

Sign-in sets a session cookie (HttpOnly, SameSite=Strict, Secure over HTTPS) for 12 hours. Tokens are never accepted in the address, where browser history, proxy logs and referrers would keep them. API calls send the token in the Authorization header.

Server settings

SettingUse
GITTA_TOKENS or --token-file FILEAdmin tokens, comma separated. The server does not start without one.
GITTA_SIGNING_KEY or --signing-key-fileAt least 32 random characters. The same on every server. Needed for personal tokens and sign-in.
GITTA_LISTEN, --listen, or PORTAddress and port. Default 0.0.0.0:8080.
GITTA_DATA, --data DIRWhere the server keeps its state and audit copies.
GITTA_SCIM_TOKEN, GITTA_SCIM_PEERSProvisioning from Okta or Entra ID. See SCIM provisioning.
GITTA_POLICY_FILE or --policy-fileTeam rules that every repository gets on top of its own. See Rules for agents.
GITTA_TLS_CERT, GITTA_TLS_KEYServe HTTPS directly. See TLS.
GITTA_LICENSE_FILE or GITTA_LICENSEYour licence. See Licence.
GITTA_OIDC_*SSO. See Tokens and sign-in.
GITTA_LOG_STDOUT, GITTA_SYSLOG, GITTA_LOG_WEBHOOKSend audit events to your log system. See below.
 Terminal
$ gitta server --listen 0.0.0.0:8080 --data /data
gitta server: listening on 0.0.0.0:8080, data in /data
gitta server: evaluation (5 people); set GITTA_LICENSE_FILE for your team
gitta server: personal tokens on
gitta server: plain HTTP: put TLS in front (ingress, load balancer) or pass --tls-cert and --tls-key

Send events to your log system

The server can send each audit event to your log system as it arrives. Use JSON lines on standard output for Google Cloud Logging, Amazon CloudWatch, Azure Monitor, Kubernetes and Docker. Use syslog over UDP, TCP or TLS for rsyslog, syslog‑ng and SIEM collectors. Use HTTPS for Splunk, Datadog or your own endpoint.

 Terminal
$ export GITTA_LOG_STDOUT=1
$ export GITTA_SYSLOG=tls://syslog.example.com:6514
$ gitta server --data /data
gitta server: audit events also go to stdout
gitta server: audit events also go to syslog tls://syslog.example.com:6514

Each output keeps a queue on disk, so the server sends the events later when a log system is down. Agents and merges never wait for it. See Send events to your log system for every setting and an example for each log system.

Check that a server runs with GET /healthz. It answers ok and needs no token.