DEV Community

Ronald (RDIT Products)
Ronald (RDIT Products)

Posted on

Jira Cloud can't reach your self-managed GitLab: 4 ways to fix it

You installed the GitLab for Jira Cloud app, entered your instance URL, and got Failed to update the GitLab instance. Or the sign-in button just hangs. If your GitLab runs on your own servers, the cause is usually the network, not the app.

Why it happens. Most GitLab–Jira integrations need to reach into your network. GitLab's own docs list the requirements:

  • Marketplace install: "Inbound and outbound connections between your GitLab Self-Managed instance and GitLab.com."
  • Manual install: "Inbound HTTPS connections from Jira Cloud to <instance_url>/-/jira_connect."
  • Behind a firewall: "Set up an internet-facing reverse proxy in front of your GitLab Self-Managed instance."

If your security team won't open an inbound path, the setup fails at exactly that step. Here are the four realistic ways out, with what each one costs you.

1. Make the instance reachable (reverse proxy + allowlist)

Put an internet-facing reverse proxy in front of GitLab and allowlist Atlassian's published IP ranges (and GitLab.com's, for the Marketplace install). Restrict by path where you can, e.g. /-/jira_connect/* and the API endpoints the app needs.

  • Good: you keep GitLab's own app with its full feature set.
  • Cost: a security sign-off for an inbound path, and upkeep, because both IP lists change over time.
  • Also note: since GitLab 19.0 the manual install is Forge-based. GitLab lists Node.js 22, the Forge CLI, envsubst, git, curl, an Atlassian developer account and an API token as prerequisites, and warns you to back up .env.self-managed, or every Jira site must re-install.

2. Use another vendor and allowlist its IP ranges

GitKraken's Git Integration for Jira is the most established alternative (about 8.6k Cloud installs and 4.4 stars as of September 2026). In its classic indexing mode it also needs to reach your server: its docs say Jira admins "are not able to connect Jira Cloud to self-hosted git servers when hosted behind a firewall or otherwise not reachable," and the fix is IP allowlisting.

  • Good: the richest feature set of the options here.
  • Cost: the same inbound-path conversation as option 1.

3. GitKraken's webhook mode (outbound only)

GitKraken also offers webhook indexing, which "only requires that your git server can make outbound Internet requests."

  • Good: no inbound access at all.
  • Cost: per their docs it gives up historical data, source code, code review, create-branch/create-merge-request and tags, and repositories "appear only after triggering push or merge request events."

4. An outbound-only app built around a system hook

GitLab system hooks are instance-wide and exist on self-managed and Dedicated instances, on the Free tier. An app can use one system hook to push commits, branches and merge requests to Jira's Development panel. Nothing connects in.

  • Good: one hook covers every current and future project; no per-repo setup and no inbound path. The app I built also queues a commit whose issue doesn't exist yet and links it once the issue is created.
  • Cost: needs GitLab admin access (system hooks are an admin feature). No pipelines, builds, deployments, tags or historical backfill. Linking starts from your next commit.

One limit applies to every webhook-based option (3 and 4): GitLab sends at most the newest 20 commits per push in a webhook. Larger pushes lose the rest, whichever tool receives them.

Side by side

Option Inbound access to GitLab? Main trade-off
1. Reverse proxy + GitLab's app Yes Security sign-off and IP-list upkeep
2. GitKraken, classic Yes (IP allowlist) Same inbound conversation
3. GitKraken, webhook mode No No history, code review, create-branch or tags
4. System-hook app No Needs GitLab admin; no pipelines, tags or backfill

How to choose

  • You can open an inbound path: option 1 or 2. You'll get the most features.
  • You can't, and need GitKraken's wider feature set: option 3, minus the items listed.
  • You can't, and want one instance-wide hook with no per-project setup: option 4.

Whatever you pick, check the 20-commit webhook limit against how your team pushes.


Disclosure: I'm the developer of option 4, Self-Managed Connector for Jira (GitLab Compatible), from RDIT Products. It's on the Atlassian Marketplace, free for up to 10 users: https://marketplace.atlassian.com/apps/2279017372?utm_source=devto&utm_medium=article&utm_campaign=launch-q4-2026 . The other options are described from their vendors' own documentation; if anything here is out of date, tell me in the comments and I'll fix it.

This app is not affiliated, endorsed, sponsored, or approved with or by GitLab Inc. GITLAB is a trademark of GitLab Inc. in the United States and other countries and regions.

Top comments (0)