TowerGit Low-Traffic Cost Optimization Mechanism

Direct Answer

TowerGit does not expose a documented repository archival or traffic‑based maintenance mechanism that reduces external hosting costs.

Confirmed Facts

The Tower desktop client manages local clones, fetch schedules, and local pruning, but it does not control server‑side compute, storage, or network billing.

Likely Explanation

Cost reductions for low‑traffic workloads are achieved by marking repositories as archived or read‑only, disabling CI/webhooks, pruning artifacts, scaling runners, or moving cold data to cheaper object storage—features of the hosting platform, not the client.

Verification Steps

1. Confirm product identity and version (desktop client vs self‑hosted TowerGit server) by checking release notes and admin docs.
2. In a staging environment, apply the candidate archival or read‑only state and record changes in job‑queue, disk usage, and object‑storage metrics before and after.
3. Identify the billing source (Git server, CI runners, object storage, or hosting provider) and apply throttling or archival controls at that layer, typically via reverse proxy, load balancer, or CI scheduler.

Missing Diagnostic Detail

Which component runs background maintenance for your workload, and where is the billing actually incurred—the TowerGit server, a separate CI system, object storage, or the hosting provider?