Skip to main content
Private preview. fremforge is in private preview — invited customers only. Content is still subject to change. Request access →
Integrations
Jira Data Center

Jira Data Center

Jira Data Center (and the legacy Jira Server) is the self-hosted variant of Atlassian’s tracker, addressed by your own hostname (e.g. https://jira.example.com/browse/<KEY>-<NUMBER>). Same URL template as Jira Cloud — just the hostname differs.

Forgejo side: external issue tracker

Repo Settings → “Advanced Settings” → External issue tracker.

FieldValue
External issue tracker URLhttps://jira.example.com/browse/{user}-{index}
External issue tracker URL formathttps://jira.example.com/browse/{user}-{index}
External issue tracker number formatRegexp
External issue tracker number format regexp([A-Z][A-Z0-9]+)-([0-9]+)

Replace jira.example.com with your DC hostname. If your Jira lives behind a VPN or private network, the link still works — the URL only opens in the customer’s browser, not from the fremforge backend.

Recommended commit-message format

fix(auth): session-token refresh race

PROJ-456

Same convention as Jira Cloud. References go at the end of the commit body.

Tracker side: DVCS Connector (optional)

The classic path for Jira DC ↔ Git is the DVCS Connector plugin (free, ships with Jira since 8.x):

  1. Jira DC → Settings → Applications → DVCS accounts → Link Bitbucket or GitHub account.
  2. DVCS Connector only natively supports Bitbucket / GitHub today; for Forgejo use the generic webhook path:
    • Jira → Settings → System → WebHooks → Create a WebHook.
    • URL: https://jira.example.com/rest/api/2/issue/{issue.key}/remotelink (or your tenant’s custom automation endpoint).
  3. In fremforge: Repo Settings → Webhooks → Add Webhook → Forgejo → paste the DC webhook URL. Tick Push and Pull Request.

If your Jira DC fronts no public surface, the webhook is the right primitive: fremforge POSTs from its outbound proxy (egress whitelisted to your Jira’s hostname via admin → Integration → Webhooks).

Sub-processor implications

Self-hosted = no new sub-processor. Jira DC runs in your infra (whether on-prem, your AWS, your Azure). Commit metadata never crosses your perimeter:

  • No DPA addendum needed beyond what you already have for your own Jira DC deployment.
  • Sovereignty story stays intact — both fremforge and your Jira DC stay in the EU (or wherever you’ve deployed them).

This is the recommended Jira flavour for sovereignty-sensitive customers.

What this doesn’t do

  • No auto-close on merge (DC supports automation rules via the Automation for Jira plugin; configure those rules against the inbound webhook payload).
  • The legacy “smart commits” syntax (PROJ-123 #close) requires the DVCS Connector + a Bitbucket/GitHub-side commit-poller; on Forgejo the equivalent is your customer-side Automation rule reading the webhook payload.
  • Migration timing: if you’re moving FROM Jira DC AND TO fremforge in the same window, link a final time at cutover and freeze; running both webhooks simultaneously during a long migration produces duplicate “linked commit” entries.
Jira CloudAzure Boards