Option A: connect a repository from the UI
Use this when the deployment does not manage the context itself (NAO_CONTEXT_SOURCE is local or api). Set it up in Settings -> Git.
1
Server keys - once per deployment
Register a GitHub OAuth App or a GitLab application, so nao can act on your team’s behalf, then set the credentials on the server and restart nao. Until then, the other steps stay disabled.
- GitHub:
GITHUB_CLIENT_IDandGITHUB_CLIENT_SECRET - GitLab:
GITLAB_CLIENT_IDandGITLAB_CLIENT_SECRET(plusGITLAB_BASE_URLfor a self-hosted instance)
2
The repository - once per project
Point nao at the repository holding your context files. This doesn’t overwrite your live project or push anything, and disconnecting it later deletes nothing. Only a project admin can disconnect it.
3
Your own account - once per person
Authorize nao with your personal GitHub or GitLab account. This is what commits and opens pull requests (or merge requests) as you, so your name is on the change and your own permissions apply.
Option B: edit the deployment’s own repository
When the deployment already clones its context from Git (NAO_CONTEXT_SOURCE=git), nao can commit and open review requests against that same repository with no OAuth app and no per-user authorization. It reuses the credential the deployment already has: the access token in NAO_CONTEXT_GIT_TOKEN, or the SSH deploy key in NAO_CONTEXT_GIT_SSH_KEY.
Nothing extra is required beyond the credential itself. Two optional variables cover the awkward cases:
Commits are still authored as the nao user who made the change, with nao as co-author, even though the push uses the deployment’s shared credential.
In this mode, Settings -> Git shows a read-only summary of the deployment-managed repository rather than the connection wizard, because the source is controlled by the environment and not the UI. Editing in the File Explorer still works. See Deployment-managed context files.