Data residency and POPIA

Every account on Gitza gets the same answer to “where is our code?”: South Africa, every layer, with the facility named rather than implied.

Where your data lives

Gitza runs on xneelo Cloud in Samrand, Gauteng. That is not only the Git repositories. The database that holds your issues, pull requests and account, the file storage behind LFS and attachments, and the backups all stay in the same country. If any part of it quietly lived offshore, the promise would be worthless, so it is not built that way.

The practical effect you notice first is latency: sub-30ms from a South African connection against the 150-220ms round-trip to an offshore forge, on every clone, pull and push, on the free tier too.

What is never done with your code

No AI training on your code, ever. Your repositories are not used to train models, public or private, and no third party is given access to them for that or any other purpose.

POPIA

The Protection of Personal Information Act does not forbid hosting your repositories offshore. What it does is put the burden on you, under section 72, to justify the cross-border transfer that offshore hosting is. For a South African business whose customers, staff and auditors are all here, that is a burden with no upside. Keeping the data in the country removes the question rather than answering it.

On the public service, that residency is the default for every account and needs nothing from you. Teams that need it in writing can have a signed POPIA operator agreement on Gitza Enterprise, which names the hosting locations and covers return and deletion of your data on exit.

Proving it

Ask. We host on named South African infrastructure, and on Enterprise those locations are written into your operator agreement. That is the entire product, and the people who run it are in your time zone.