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.
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).
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.
$ 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
| Setting | Use |
|---|---|
GITTA_TOKENS or --token-file FILE | Admin tokens, comma separated. The server does not start without one. |
GITTA_SIGNING_KEY or --signing-key-file | At least 32 random characters. The same on every server. Needed for personal tokens and sign-in. |
GITTA_LISTEN, --listen, or PORT | Address and port. Default 0.0.0.0:8080. |
GITTA_DATA, --data DIR | Where the server keeps its state and audit copies. |
GITTA_SCIM_TOKEN, GITTA_SCIM_PEERS | Provisioning from Okta or Entra ID. See SCIM provisioning. |
GITTA_POLICY_FILE or --policy-file | Team rules that every repository gets on top of its own. See Rules for agents. |
GITTA_TLS_CERT, GITTA_TLS_KEY | Serve HTTPS directly. See TLS. |
GITTA_LICENSE_FILE or GITTA_LICENSE | Your licence. See Licence. |
GITTA_OIDC_* | SSO. See Tokens and sign-in. |
GITTA_LOG_STDOUT, GITTA_SYSLOG, GITTA_LOG_WEBHOOK | Send audit events to your log system. See below. |
$ 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-keySend 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.
$ 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:6514Each 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.