Skip to main content
A self-hosted nao container needs to know where its context lives. The NAO_CONTEXT_SOURCE environment variable picks one of three sources. When the deployment owns the context, the in-app Settings -> Git page turns into a read-only summary instead of a connection wizard, so no one can accidentally repoint a managed deployment from the UI.

​
Context sources

If NAO_CONTEXT_SOURCE is unset, nao defaults to api in cloud mode and local otherwise. An unknown value stops the container at startup.

​
Git-managed context

Set NAO_CONTEXT_SOURCE=git to have the container clone your context repository when it boots. NAO_CONTEXT_GIT_URL is required; the rest scope and authenticate the clone:
The container picks the auth scheme from the URL: git@… / ssh://… needs NAO_CONTEXT_GIT_SSH_KEY, and https://… accepts an optional NAO_CONTEXT_GIT_TOKEN. GitHub and Bitbucket host keys are pre-pinned, so SSH connects without a known-hosts prompt. See Deployment guide for the full clone and secrets walkthrough, and Multiple projects for running several context repositories from one deployment.

​
The read-only Git summary

When NAO_CONTEXT_SOURCE=git, the deployment is the owner of the context setup. Settings -> Git then shows a read-only summary of the deployment-managed repository instead of the repository connection wizard: admins can see which repository, branch, and subpath the container was configured with, but the connect and disconnect flow is disabled because the source is controlled by the deployment’s environment, not the UI. To let admins connect and edit the context repository from the browser instead, leave NAO_CONTEXT_SOURCE on local (or api) and set the repository up in-app under Settings -> Git.
Changing NAO_CONTEXT_SOURCE takes effect on container restart, since the context is resolved at startup. Update the environment variable on your platform (Cloud Run, ECS, Kubernetes, …) and redeploy.