Project access tokens

NOTE: Project access tokens are supported for self-managed instances on Free and above. They are also supported on GitLab SaaS Premium and above (excluding trial licenses).

• Introduced in GitLab 13.0.
• Became available on GitLab.com in GitLab 13.5 for paid groups only.
• Feature flag removed in GitLab 13.5.

WARNING: This feature might not be available to you. Check the version history note above for details.

Project access tokens are scoped to a project and can be used to authenticate with the GitLab API. You can also use project access tokens with Git to authenticate over HTTP.

Project access tokens expire on the date you define, at midnight UTC.

For examples of how you can use a project access token to authenticate with the API, see the following section from our API Docs.

Creating a project access token

1. Log in to GitLab.
2. Navigate to the project you would like to create an access token for.
3. In the Settings menu choose Access Tokens.
4. Choose a name and optional expiry date for the token.
5. Choose the desired scopes.
6. Click the Create project access token button.
7. Save the project access token somewhere safe. Once you leave or refresh the page, you won't be able to access it again.

Project bot users

Project bot users are GitLab-created service accounts and do not count as licensed seats.

For each project access token created, a bot user is created and added to the project with Maintainer level permissions.

For the bot:

• The name is set to the name of the token.
• The username is set to project_{project_id}_bot for the first access token, such as project_123_bot.
• The username is set to project_{project_id}_bot{bot_count} for further access tokens, such as project_123_bot1.

API calls made with a project access token are associated with the corresponding bot user.

These bot users are included in a project's Members list but cannot be modified. Also, a bot user cannot be added to any other project.

• The username is set to project_{project_id}_bot for the first access token, such as project_123_bot.
• The username is set to project_{project_id}_bot{bot_count} for further access tokens, such as project_123_bot1.

When the project access token is revoked the bot user is deleted and all records are moved to a system-wide user with the username "Ghost User". For more information, see Associated Records.

Revoking a project access token

At any time, you can revoke any project access token by clicking the respective Revoke button in Settings > Access Tokens.

Limiting scopes of a project access token

Project access tokens can be created with one or more scopes that allow various actions that a given token can perform. The available scopes are depicted in the following table.

Scope	Description
api	Grants complete read/write access to the scoped project API, including the Package Registry.
read_api	Grants read access to the scoped project API, including the Package Registry.
read_registry	Allows read-access (pull) to container registry images if a project is private and authorization is required.
write_registry	Allows write-access (push) to container registry.
read_repository	Allows read-only access (pull) to the repository.
write_repository	Allows read-write access (pull, push) to the repository.

Enable or disable project access tokens

Project access tokens are deployed behind a feature flag that is enabled by default. GitLab administrators with access to the GitLab Rails console can disable it for your instance, globally or by project.

To disable it globally:

Feature.disable(:resource_access_token)

To disable it for a specific project:

Feature.disable(:resource_access_token, project)

To enable it globally:

Feature.enable(:resource_access_token)

To enable it for a specific project:

Feature.enable(:resource_access_token, project)