# How to rotate GitLab access tokens > Reissue a GitLab personal, project or group access token without breaking pipelines, and know when the built-in Rotate action cuts off the old token at once. URL: https://crunu.com/rotate/gitlab Language: en Updated: 2026-10-30 Create a new access token with the same scopes, and for a project or group token the same role, move every pipeline and script to it, and revoke the old token once nothing uses it. Two tokens can be active together, so the switch costs no downtime. GitLab's built-in **Rotate** action is faster but has no overlap: it creates a token with the same permissions and scope, and the original becomes inactive immediately ([GitLab docs](https://docs.gitlab.com/user/profile/personal_access_tokens/)). Keep Rotate for leaks, or for tokens with a single consumer you can update in the same minute. Crunu doesn't create, rotate or revoke GitLab tokens. It works out which GitLab values a departing person received, stores the replacement as a new version of the environment, and hands it to the jobs that need it. *Figure: Timeline of rotating the Personal, project or group access token. Step 1: a new key is issued while the old one keeps working. Step 2: every place that uses the key is updated, with no downtime because both keys work. Step 3: the old key is revoked. After revocation the old key stops working at once.* ## Which GitLab token you hold Personal, project and group access tokens all start with `glpat-`. Only the personal token prefix can be configured, so on a self-managed instance it may differ. Other credentials have their own prefixes, which helps when you sort a list of leaked values: `gldt-` for deploy tokens, `glcbt-` for CI/CD job tokens, `glrt-` for runner authentication tokens and `glptt-` for trigger tokens ([token overview](https://docs.gitlab.com/security/tokens/)). - **Personal access token.** Acts as a person with the scopes you pick. GitLab's documentation now labels these legacy personal access tokens and links to a newer fine-grained type. - **Project access token.** GitLab creates a bot user for it, named like `project_{project_id}_bot_{random_string}`, and the bot gets the role and scopes you choose. Creating one needs the Maintainer or Owner role, and on GitLab.com a Premium or Ultimate subscription ([project tokens](https://docs.gitlab.com/user/project/settings/project_access_tokens/)). - **Group access token.** The same idea at group level, for automation that spans several projects. For pipelines and integrations, project or group tokens survive staff changes better than a person's token, because no human account sits behind them. ## Expiry forces a reissue anyway By default every new token must have an expiry date, and that date can be at most 365 days ahead; leave it blank and GitLab sets 365 days. On GitLab 17.6 and later an administrator can change the maximum, and a 400-day limit exists behind a feature flag that is off by default. Tokens expire at midnight UTC and can't be reactivated. GitLab emails the owner 7 days before expiry, and since 17.7 also 30 and 60 days before; in 17.6 those earlier notices were behind a feature flag. For project tokens, the mail goes to members with the Maintainer or Owner role. In practice every GitLab token gets reissued at least once a year, so the steps below are worth making routine. ## Reissue without downtime 1. Create the replacement where the old token lives: your user settings for a personal token, or the project's or group's **Access tokens** settings. Copy the scopes, the role and a sensible expiry date from the old token. The value is shown once. 2. Save it in Crunu, for example as `GITLAB_TOKEN` in `web-app / production`. Each save is a new environment version with an author and a time. 3. Switch consumers. A script or deploy job started as `crunu run --env web-app/production -- …` reads the latest version when it starts; services launched with `--restart on-change` restart themselves. 4. Run each job that depends on the token once, and confirm it authenticates with the new value. 5. Revoke the old token. GitLab invalidates it immediately and keeps it for auditing: tokens can't be deleted outright, and revoked project and group tokens are removed after 30 days by default. Personal, project and group tokens can also be rotated through their own API endpoints, which suits a scheduled job. Remember that an API rotation behaves like the button: the previous token stops working at once. ## When to reissue a GitLab token - **A departure.** Personal tokens belong to the person. GitLab's docs say the tokens of deleted or blocked enterprise users are revoked automatically; for anyone else, check their tokens yourself. Everything they could read is a different matter: project and group tokens, a shared bot's personal token, trigger tokens. In Crunu, removing the person produces a reissue checklist of the values they received, by name. - **A leak.** Rotate or revoke at once and accept the short break. GitLab keeps both versions of a rotated token for its audit records. - **An expiry email.** Treat the 30-day notice as the start of a planned reissue, not a reminder to extend. GitLab's own advice helps here too: name tokens consistently so you can judge the impact of rotating or revoking each one, and review active tokens of every type regularly. [What to rotate when a developer leaves](https://crunu.com/guides/developer-offboarding-secret-rotation) covers the full order of work, and the [offboarding checklist](https://crunu.com/tools/offboarding-checklist) builds the list for your stack. Crunu's environment history then shows when each GitLab value was replaced and by whom, while the token changes themselves stay in GitLab. ## FAQ ### Does GitLab's Rotate action keep the old token working? No. Rotate creates a new token with the same permissions and scope, and the original becomes inactive immediately. Tools using the old value fail until you update them. For an overlap, create a separate token with the same scopes and revoke the old one later. ### How long can a GitLab access token live? By default a new token must have an expiry date no more than 365 days ahead, and a blank date becomes 365 days. Administrators on GitLab 17.6 and later can change the maximum. Tokens expire at midnight UTC on that date and can't be reactivated. ### Do project access tokens stop working when the person who created them leaves? A project access token belongs to a bot user that GitLab creates for the project, not to the person who made it. Treat it as still valid after that person leaves, and reissue it if they could read its value. ### Does Crunu rotate GitLab tokens? No. Crunu has no GitLab integration and never calls its API. It shows which GitLab values a departing person received, stores the replacement as a new environment version, and passes it to jobs and services through crunu run. ## Sources - [GitLab Docs: Personal access tokens](https://docs.gitlab.com/user/profile/personal_access_tokens/) (accessed 2026-10-30) - [GitLab Docs: Project access tokens](https://docs.gitlab.com/user/project/settings/project_access_tokens/) (accessed 2026-10-30) - [GitLab Docs: GitLab token overview](https://docs.gitlab.com/security/tokens/) (accessed 2026-10-30)