---
name: reference_gitea_git_op_latency
description: Gitea git-op latency benchmarks - SSH is SLOWER than internal HTTP+token; the SOPS credential lookup is only ~0.33s, not the bottleneck. Do not switch to SSH for speed.
metadata:
  type: reference
---

Benchmarked 2026-06-01 on GURU-5070 (ls-remote HEAD, claudetools repo):

| Path | Time |
|---|---|
| SOPS decrypt of Gitea token (`vault.sh get-field services/gitea.sops.yaml credentials.api.api-token`) | ~0.33s |
| Internal HTTP+token `http://...@172.16.3.20:3000` | ~0.55s |
| External HTTPS `git.azcomputerguru.com` (Cox/NPM/Cloudflare) | ~0.83s |
| **SSH passwordless** `git@172.16.3.20:2222` | **~1.5s** (SLOWEST) |

Takeaways:
- The "credential lookup" is only ~0.33s - NOT the cause of slow git ops. Do NOT switch git transport to SSH expecting a speedup; the SSH handshake to :2222 costs more than the SOPS decrypt it saves.
- Gitea built-in SSH server is `git@172.16.3.20:2222` (publickey-only). The repo API `ssh_url` advertises `git@172.16.3.21` (port 22) which is WRONG - that's a host sshd (offers password), not Gitea. Gitea `SSH_DOMAIN`/`SSH_PORT` config is misconfigured; the real endpoint is `.20:2222`.
- Switching `origin` to SSH also breaks `sync.sh` submodule credential reuse (it derives submodule creds from an embedded-cred HTTP origin URL, ~line 181).
- If repeated 0.33s SOPS decrypts in a session add up, the right optimization is caching the decrypted token (credential helper / session env), NOT changing transport.
- Intermittent real slowness is usually the NPM SSL-renewal reload blips on the EXTERNAL domain - stay on internal `172.16.3.20:3000` (see [[reference_gitea_internal]]).
- An SSH key named "GURU-5070" (ed25519) was added to the shared `azcomputerguru` Gitea account during this test; remove it if the SSH approach is abandoned.