doc/administration/settings/jira_cloud_app.md
{{< details >}}
{{< /details >}}
[!note] This page contains administrator documentation for the GitLab for Jira Cloud app. For user documentation, see GitLab for Jira Cloud app.
With the GitLab for Jira Cloud app, you can connect GitLab and Jira Cloud to sync development information in real time. You can view this information in the Jira development panel.
To set up the GitLab for Jira Cloud app on your GitLab Self-Managed instance, do one of the following:
<i class="fa-youtube-play" aria-hidden="true"></i> For an overview, see:
The videos above show the older Universal Plugin Manager interface which might be unavailable on newer Jira Cloud instances. The following instructions cover both old and new app management interfaces.
If you install the GitLab for Jira Cloud app from the Atlassian Marketplace, you can use the project toolchain developed and maintained by Atlassian to link GitLab repositories to Jira projects. The project toolchain does not affect how development information is synced between GitLab and Jira Cloud.
For Jira Data Center or Jira Server, use the Jira DVCS connector developed and maintained by Atlassian.
Whether you want to install the GitLab for Jira Cloud app from the Atlassian Marketplace or manually, you must create an OAuth application.
Prerequisites:
To create an OAuth application on your GitLab Self-Managed instance:
In the upper-right corner, select Admin.
In the left sidebar, select Applications.
Select New application.
In Redirect URI:
https://gitlab.com/-/jira_connect/oauth_callbacks.<instance_url>/-/jira_connect/oauth_callbacks and replace <instance_url> with the URL of your instance.Clear the Trusted and Confidential checkboxes.
[!note] You must clear these checkboxes to avoid sign in errors.
In Scopes, select the api checkbox only.
Select Save application.
Copy the Application ID value.
In the left sidebar, select Settings > General.
Expand GitLab for Jira App.
Paste the Application ID value into Jira Connect Application ID.
Select Save changes.
{{< history >}}
org-admins group introduced in GitLab 16.6.{{< /history >}}
In your Atlassian organization, you must ensure that the Jira user that is used to set up the GitLab for Jira Cloud app is a member of either:
org-admins) group. Newer Atlassian organizations are using
centralized user management,
which contains the org-admins group. Existing Atlassian organizations are being migrated to centralized user management.
If available, you should use the org-admins group to indicate which Jira users can manage the GitLab for Jira Cloud app. Alternatively you can use the
site-admins group.site-admins) group. The site-admins group was used under
original user management.If necessary:
Browse users and groups permission to the Jira user.{{< history >}}
{{< /history >}}
You can use the official GitLab for Jira Cloud app from the Atlassian Marketplace with your GitLab Self-Managed instance.
With this method:
Alternatively, you might want to install the GitLab for Jira Cloud app manually if:
To set up your GitLab Self-Managed instance for Atlassian Marketplace installation in GitLab 15.7 and later:
https://gitlab.com to install the app from the Atlassian Marketplace.To link your GitLab Self-Managed instance to the GitLab for Jira Cloud app:
You can use the Rails console to check if Jira Cloud is linked to:
A specific group:
JiraConnectSubscription.where(namespace: Namespace.by_path('group/subgroup'))
A specific project:
Project.find_by_full_path('path/to/project').jira_subscription_exists?
Any group:
installation = JiraConnectInstallation.find_by_base_url("https://customer_name.atlassian.net")
installation.subscriptions
{{< history >}}
{{< /history >}}
[!warning] The previous manual install method relied on Atlassian Connect development mode. Atlassian disabled Connect-based private installs on 2026-03-31. If you previously installed the app manually with the App descriptor URL workflow, migrate to the Forge-based install described in this section.
Install the GitLab for Jira Cloud app manually if you cannot use the official Atlassian Marketplace listing. For example, if:
The manual install method is now based on Atlassian Forge. You publish a private copy of the GitLab for Jira Cloud Forge app under your own Atlassian developer account, pointed at your GitLab Self-Managed or GitLab Dedicated instance.
<instance_url>/-/jira_connect (Atlassian IP addresses).*.atlassian.net to push development data to Jira.*.atlassian.net is required for the development panel and other Jira-side surfaces.envsubst, git, and curl.To set up your GitLab Self-Managed instance for manual installation:
To publish a private copy of the GitLab for Jira Cloud Forge app and install it on your Jira site:
Clone the gitlab-jira-forge repository:
git clone --depth 1 https://gitlab.com/gitlab-org/gitlab-jira-forge.git
cd gitlab-jira-forge
Export the required environment variables. Replace the example values with your GitLab instance URL, Jira site, and Atlassian credentials:
export GITLAB_URL=https://gitlab.example.com
export JIRA_SITE=acme.atlassian.net
export [email protected]
export FORGE_API_TOKEN=<your-atlassian-api-token>
Run the wrapper script to register, deploy, and install the app:
./scripts/install-self-managed.sh
The wrapper:
forge register on first use to create a Forge app under your Atlassian account.manifest.yml from the template, pinned to your GITLAB_URL.forge deploy -e production.forge install --site $JIRA_SITE --product jira.The script caches the registered APP_ID in .env.self-managed. Back up this file:
if you lose it, you must re-register the app, which forces all installed Jira sites to re-install.
For step-by-step instructions, manual forge commands, troubleshooting, and the upgrade workflow, see the
Self-managed install guide
in the gitlab-jira-forge repository.
After the app is installed, configure the GitLab for Jira Cloud app in Jira to link your GitLab namespaces.
To pull upstream manifest changes into your private Forge app, re-run the wrapper with --update:
./scripts/install-self-managed.sh --update
The script fast-forwards the local clone, regenerates the manifest, and redeploys the app. For more information about minor and major version upgrades, see Upgrading in the self-managed install guide.
Use the GitLab for Jira app to connect multiple GitLab instances to a single Jira Cloud instance. The installation methods depend on which instances you want to connect.
Prerequisites:
For GitLab.com + GitLab Self-Managed:
For multiple GitLab Self-Managed instances:
Jira Cloud displays a GitLab for Jira Cloud app for each installation.
Only one GitLab instance per organization can use the official Atlassian Marketplace listing.
[!note] For most users, this configuration is not necessary. To Jira Cloud with multiple instances, you can connect each instance with the GitLab for Jira Cloud app.
A GitLab instance can serve as a proxy for other GitLab instances through the GitLab for Jira Cloud app. You might want to use a proxy if you're managing multiple GitLab instances but only want to manually install the app once.
To configure your GitLab instance to serve as a proxy:
Other GitLab instances that use the proxy must configure the following settings to point to the proxy instance:
The following security considerations are specific to administering the app. For considerations related to using the app, see security considerations.
When you Install the GitLab for Jira Cloud app from the Atlassian Marketplace, GitLab.com receives lifecycle events from Jira. These events are limited to when the app is installed in or uninstalled from your Jira Project.
In the install event, GitLab.com receives a secret token from Jira.
GitLab.com stores this token encrypted with AES256-GCM to later verify incoming lifecycle events from Jira.
GitLab.com then forwards the token to your GitLab Self-Managed instance so your instance can authenticate its requests to Jira with the same token. Your GitLab Self-Managed instance is also notified that the GitLab for Jira Cloud app has been installed or uninstalled.
When data is sent from your GitLab Self-Managed instance to the Jira development panel, it is sent from your GitLab Self-Managed instance directly to Jira and not to GitLab.com. GitLab.com does not use the token to access data in your Jira project. Your GitLab Self-Managed instance uses the token to access the data.
For more information about the lifecycle events and payloads that GitLab.com receives, see the Atlassian documentation.
sequenceDiagram
accTitle: Dataflow of the GitLab for Jira Cloud app installed from the Atlassian Marketplace
accDescr: How GitLab.com handles lifecycle events when the GitLab for Jira Cloud app was installed from the Atlassian Marketplace
participant Jira
participant Your instance
participant GitLab.com
Jira->>+GitLab.com: App install/uninstall event
GitLab.com->>-Your instance: App install/uninstall event
Your instance->>Jira: Your development data
When you have installed the GitLab for Jira Cloud app from the Atlassian Marketplace, the links to create a branch from the development panel initially send the user to GitLab.com.
Jira sends GitLab.com a JWT token. GitLab.com handles the request by verifying the token and then redirects the request to your GitLab instance.
GitLab does not share an access token with Jira. However, users must authenticate through OAuth to configure the app.
An access token is retrieved through a PKCE OAuth flow and stored only on the client side. The app frontend that initializes the OAuth flow is a JavaScript application that's loaded from GitLab through an iframe on Jira.
The OAuth application must have the api scope, which grants complete read and write access to the API.
This access includes all groups and projects, the container registry, and the package registry.
However, the GitLab for Jira Cloud app only uses this access to:
Access through OAuth is only needed for the time a user configures the GitLab for Jira Cloud app. For more information, see Access token expiration.
You should avoid using a reverse proxy in front of your GitLab Self-Managed instance if possible. Instead, consider using a public IP address and securing the domain with a firewall.
If you must use a reverse proxy for the GitLab for Jira Cloud app on a GitLab Self-Managed instance that cannot be accessed directly from the internet, keep the following in mind:
gitlab-jira-connect-${host} app key.
Otherwise, you might get a Failed to link group error.This server block is an example of how to configure a reverse proxy for GitLab that works with Jira Cloud:
server {
listen *:80;
server_name gitlab.mycompany.com;
server_tokens off;
location /.well-known/acme-challenge/ {
root /var/www/;
}
location / {
return 301 https://gitlab.mycompany.com:443$request_uri;
}
}
server {
listen *:443 ssl;
server_tokens off;
server_name gitlab.mycompany.com;
ssl_certificate /etc/letsencrypt/live/gitlab.mycompany.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/gitlab.mycompany.com/privkey.pem;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384';
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;
ssl_session_timeout 1d;
access_log "/var/log/nginx/proxy_access.log";
error_log "/var/log/nginx/proxy_error.log";
location / {
proxy_pass https://gitlab.internal;
proxy_hide_header upgrade;
proxy_set_header Host gitlab.mycompany.com:443;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
In this example:
gitlab.mycompany.com with the reverse proxy FQDN
and gitlab.internal with the internal GitLab FQDN.ssl_certificate and ssl_certificate_key to a valid certificate
(the example uses Certbot).Host proxy header to the reverse proxy FQDN
to ensure GitLab and Jira Cloud can connect successfully.You must use the reverse proxy FQDN only to connect Jira Cloud to GitLab. You must continue to access GitLab from the internal GitLab FQDN. If you access GitLab from the reverse proxy FQDN, GitLab might not work as expected. For more information, see issue 21319.
{{< history >}}
{{< /history >}}
When GitLab receives a JWT token from Jira, GitLab verifies the token by checking the JWT audience. By default, the audience is derived from your internal GitLab FQDN.
In some reverse proxy configurations, you might have to set the reverse proxy FQDN as an additional JWT audience. To set an additional JWT audience:
https://gitlab.mycompany.com).