← Kuunda Docs
Console

Kuunda Git (hosted Git)

Kuunda Git hosts your project Git repository on Kuunda infrastructure: HTTPS clone and push with a project token, no third-party service and no copy of your code outside the project zone.

One repository per project

Every Kuunda project hosts its own Git repository. The first git push creates it, with the name you choose: nothing to declare beforehand. The repository lives with the project, in its residency zone.

  • One repository per app or service: the name you choose becomes the last segment of the Git address.
  • Repository content counts against the project allowance, with a per-repository cap.
  • Code stays out of the project database: it lives in its own space, while rights, quotas and logs stay managed by the console.
  • The repository stays a standard Git repository: git clone --mirror gives you a full copy, with no lock-in.

Access tokens

A repository does not open with your account password: it needs a token, created from the project, under Services → Kuunda Git.

  • Read scope: clone and fetch — the right choice for a workstation.
  • Write scope: clone, fetch and push — for the machine that publishes (CI, agent).
  • A token only grants access to this project, until its expiry date (from a few days to never).
  • Its value is shown only once: copy it into your secret manager or your CI variables.
  • A token can be revoked from the same page; revocation cuts access without touching the repository.

Clone and push

The address shown in the console pastes as is: git asks for the kuunda username and the token. The credential.helper avoids retyping the secret on every command.

Terminal

git remote add kuunda <url>
git config credential.helper '!f() { echo username=kuunda; echo password=<token>; }; f'
git push kuunda main

Replace <url> with the address shown under Services → Kuunda Git, and <token> with the value created just before. The console offers the same command block already filled in, ready to copy.

What a push triggers

A project site can be wired to a repository: the push then becomes a deployment, with no manual step.

  • The push is accepted before the build: if the build fails, the commit is kept and the published version stays online.
  • Build logs and the deployed revision stay available from the site page.
  • A repository with no site wired to it is just a Git repository: nothing is built.
  • Issues, pull requests and reviews live in the project (same roles). No wiki, no code search, no public runners.

Delete and restore

Deletion removes the repository from the project space, but it is reversible: an encrypted backup is written and read back before removal. Confirmation requires the exact repository name. A restore never recreates an existing repository: delete it first to go back to an earlier backup.

Next steps

Open the console