​
Organization name and ID

At the top of the Organization settings page you will see the Organization name and ID. The Organization name is a human-readable name that you can change at any time. The Organization ID is a unique identifier useful for support requests or when using the Gitpod API.

​
Default Workspace Image

Setting a default image for your Organization (instead of relying on the default workspace-full image) is useful when you want to create a default workspace experience for your Organization members without adding a .gitpod.yml to every repository. The Organization workspace image setting is a default and can still be overwritten by updating the repository .gitpod.yml file.
The user must have the Organization Owner role to update the Organization default workspace image. All Organization members can view this setting only.
See Workspace Image for more.

​
Authentication for private Docker images

Authentication for the images is based on multiple things:
  1. the GITPOD_IMAGE_AUTH environment variable, containing Docker username/password credentials for one or more registry hosts. One way to set it is in the Organization settings.
  2. [Enterprise only] What the Gitpod installation can access. For instance, if you are using a ECR private registry which is configured to grant Gitpod access (cmp. this section).

​
Docker Registry authentication

This section allows to configure the GITPOD_IMAGE_AUTH on the organization level. See this section on the expected format.
The user must have the Organization Owner role to update the Docker registry authentication configuration. All other organization members can view this setting only.

​
Insights

​
Git commit annotation

To better understand usage of Gitpod in your organization, you can enable the “Annotate git commits” feature, which will mark all commits created from within Gitpod workspaces with a special trailer in the format of Tool: gitpod/<GITPOD HOST>. This feature is disabled by default and works by injecting a prepare-commit-msg hook into the cloned repository’s .git/hooks directory. The hook will not overwrite any existing prepare-commit-msg hook and its use is hence not enforced.