Skip to content


API Token

GoReleaser requires an API token with the api scope selected to deploy the artifacts to GitLab. That token can either be a Personal, or a Project one.

This token should be added to the environment variables as GITLAB_TOKEN.

Alternatively, you can provide the GitLab token in a file. GoReleaser will check ~/.config/goreleaser/gitlab_token by default, but you can change that in the .goreleaser.yaml file:

# .goreleaser.yaml
  gitlab_token: ~/.path/to/my/gitlab_token


If you use a project access token, make sure to set use_package_registry to true as well, otherwise it might not work.

GitLab Enterprise or private hosted

You can use GoReleaser with GitLab Enterprise by providing its URLs in the .goreleaser.yml configuration file. This takes a normal string, or a template value.

# .goreleaser.yml

  # set to true if you use a self-signed certificate
  skip_tls_verify: false

  # set to true if you want to upload to the Package Registry rather than attachments
  # Only works with GitLab 13.5+
  # Since: v1.3.
  use_package_registry: false

  # Set this if you set GITLAB_TOKEN to the value of CI_JOB_TOKEN.
  # Default: false
  # Since: v1.11.
  use_job_token: true

If none are set, they default to GitLab's public URLs.


Releasing to a private-hosted GitLab CE will only work for version v12.9+, due to dependencies on release functionality and direct asset linking.

Generic Package Registry

GitLab introduced the Generic Package Registry in Gitlab 13.5.

Normally, goreleaser uploads release files as "attachments", which may have administrative limits. Notably, hosted instances have a 10MB attachment limit, which cannot be changed.

Uploading to the Generic Package Registry does not have this restriction. To use it instead, set use_package_registry to true.

# .goreleaser.yml
  use_package_registry: true

Example release

Here's an example of what the release might look like:

Example release on GitLab.