JEC (Jira Edge Connector) would help bridge gap for many when migrating from behind firewall! Vote!

[#1]

Anyone want to build a bridge?

So recently one of our engineers inquired about whether Jira could make an API call to one of our internal services (behind the firewall).

Back when we were on-prem, this was easy - for a different service, we had a webhook pointing at the internal service, and boom, done.

When we moved to Cloud, things got complicated, because Jira Cloud can't get through our firewall. When this came up in migration, the maintainer of the internal service had to do a bunch of extra work to make his service "public" via Amazon API Gateway.

I explained this to the more recent requestor, and they Googled around and found something called Jira Edge Connector (JEC) which is described as:

Jira Edge Connector (JEC) is a lightweight application that you can use to:

• integrate systems that are not accessible from the public internet with Jira Service Management
• run executables triggered by Jira Service Management
• deploy on-premises or in the customer’s cloud environment

Supported script technologies
JEC supports the following scripts:

• Groovy scripts (.groovy)
• Python scripts (.py)
• Go scripts (.go)
• Powershell scripts (. ps1)
• Shell scripts (.sh)
• Batch files (.cmd and .bat)

JEC supports environment variables, arguments, and flags that are passed to scripts. You can set these globally for all the scripts or locally on a per-script basis. Stderr and stdout options are also available. All the JEC scripts are written in Python3.

This was the first I had heard of such a tool! It sounded like a GREAT way to bridge the gap between Jira Cloud and internal services that are locked behind the firewall.

But oh. It's only for JSM? What a bummer. What was weird though is that I could see the Automation action to trigger JEC scripts in my NON-JSM Jira:

[Ok so making "Waiting for response" an Enterprise-only feature is super lame, but ok fine, if even just being able to trigger internal services would be useful!]

But when I click on that big beautiful blue Connect button, I get prompted to create an API key:

Oooh, looks so promising, but alas:

So... I filed a ticket.

Avery was kind enough to let me know that if my Jira also had JSM (which it does not), I could use this workaround:

Currently there is a workaround for using JEC with software projects if you have a JSM premium or enterprise license in the same site. If you do, you can create a global automation rule, add the JEC action there and then use the rule with your software project.

But ooof:

As far as standalone support for the action for software projects goes, it hasn't made it to the official roadmap yet and there is no timeline for when it will. However, I can tell you that Atlassian is very much aware of customer interest in this feature and it is being actively investigated internally. I would encourage you to keep an eye out on the public changelogs for the time being.

So then, as a wise man once said:

Don't Boo. Vote.

AUTO-2026 - Enable Jira Edge Connector for Jira Software/Business projects (Without a JSM subscription) 

Here's some use cases that Avery put into the ticket (the database lookup one is mine)

Use Cases

1. Internal Database Lookups

• Retrieve incident data from internal logging systems using incident IDs from custom fields

• Process large JSON responses that may exceed current Automation limits (16KB for Enterprise)

• Attach retrieved data as JSON files to issues (workaround for size limitations)

2. Legacy System Integration

• Connect with on-premise systems that cannot be exposed publicly

• Maintain existing integrations during cloud migration

• Preserve security policies that prohibit public endpoints

3. Internal Tool Automation

• Trigger internal build systems

• Update internal tracking databases
• Synchronize with proprietary internal tools

Why doesn't anyone know about this? (TW: OPINIONS)

I guess I'm not surprised there's not more outcry for this tool to be available to regular Jira instances because it's just not that well-known. I mean, to be fair, it came with the OpsGenie (RIP) acquisition, and was announced back in 2019:

• Secure bi-directional integrations with Opsgenie Edge Connector 

But this was before Automation, so it only worked with... Opsgenie Rules, which makes sense because it was and is very Ops-oriented.

It looks like Atlassian integrated JEC with Automation back in April 2024: Automation using Jira Edge Connector (JEC) 

And there's even a nice Loom about it: Automation using Jira Edge Connector (JEC): Run executable scripts on systems behind the firewall 

But I have to imagine that companies like mine MUST have internal tools that they want to integrate that aren't necessarily for Ops stuff, but rather Development. Those people use Jira for Development (AS GOD INTENDED, oh sorry).

And they could really use a bridge like this.

I mean, Atlassian clearly knew they had to deal with uh, Jira/Confluence/Bitbucket/Bamboo instances that might live behind the firewall, that's why they have Application Tunnels. 

It's wild to me that they OWN an existing solution (even if it's not explicitly designed for it) that would help companies that need to bridge the gap, but just kind of buried it. (Ok, with the fact that OpsGenie is going away, again, I should not be surprised.)

But SERIOUSLY did nobody bring this up to their CSM or TAM, sorry Advisory Manager, and nobody was like "Oh hey, we have this thing that might help with that? And huh, it's already built and stuff."

Oof.

So yeah, please vote. OKTHX.

</soapbox>

[Matt Doar _Adaptavist_]

Well, enough customers wanted similar things so Adaptavist created ScriptRunner Connect. 
https://community.atlassian.com/forums/Jira-articles/JEC-Jira-Edge-Connector-would-help-bridge-gap-for-many-when/ba-p/3101365#M20403
I'll let the other partners add their ideas and offerings here.

And JEC seems like a product that never quite made the big time?

[Darryl Lee]

Hey thanks @Matt Doar _Adaptavist_ - I think maybe you meant to link to this?

• https://www.scriptrunnerhq.com/atlassian-apps/jira/scriptrunner-connect

However, hrm, specifically regarding connecting to hosts inside the firewall, it looks like we run into the same issue of having to poke holes / reconfigure services to be accessible from ScriptRunner Connect:

• Connection to the third-party service can be established. Behind the firewall, services may need to be configured to let the connection from ScriptRunner Connect side go through by either allowlisting our static IP or by setting up a reverse proxy in a less restricted network.
  (Source: https://docs.adaptavist.com/src/latest/connectors/generic-connector)

While I understand the appeal to some of Code over No-Code, regarding the behind the firewall  thing I don't think (?) that ScriptRunner has any advantage over Automation + Web Requests.

Happy to be corrected though! Is there some undocumented/secret ScriptRunner Connector "Bridge" product that exists?

[Darryl Lee]

Some unrelated related notes:

Ah, ok so I didn't see this article before, but clearly I'm not the first person to "discover" the utility of JEC for maybe non-Ops related things, as @Dominique Wille wrote in Dec 2024:

• Jira Edge Connector... super great but no connector feedback ? 

As Dominique writes:

Overall super simple, very efficient and communication is bottom-up (edge to jira-cloud) which does NOT require to open a port from Jira to edge.

This is a fantastic feature, and super happy it exists now. Solves a hell of issues.

(Although having chatted with Matt earlier today, we are curious about HOW JEC does what it does. Seems like our security/trust team would want to know about the internals. Oh wait, does this repo maybe include source code for the JEC server too? I see code for poller and token, which you would expect for a service like this. But yeah, how does the JEC register / connect with the API token that you'd get in Automation. Hmmm. Ah, reader.go mentions jsmUrl and also a apiKey so I guess that's something... Well, at least it was updated... 8 months ago.)

But yeah, it seems like Dominque's happiness was short lived:

But... I am crying.

To get it working in first direction, you need to have Jira service mgt premium or enterprise. Great it works for us (20 pax).

But this guy can give a feedback to Jira too (the other direction)... but....

This action supports waiting for response only for Enterprise plan.

As @Richard Landman concurred:

Hi Dominique, I think you are right. JEC has huge potential and we are also investigating what use cases make sense. The waiting for response should be in premium. Or at least offer it as an "add-on" service which you can purchase separately.

---

OOH and in Jan 2025, @Belliveau, John asked a VERY relevant question:

In light of the recent migration from OpsGenie to Jira Service Management, are there any plans to deprecate the OpsGenie Edge Connector (OEC) or migrate users to the Jira Edge Connector (JEC)?

And in July @Tom DuVally also expressed interest:

I'm also interested in this, since OEC seems to be a dead project, but JEC doesn't seem to be much more active that OEC. They are still using the exact same awful documentation, but don't mention the migration in any of it.

Heh. But yeah well, at least somebody updated the Github (not Bitbucket?) repo back on Jan 30. Hm @metehanozturk's LinkedIn says he's a Software Engineer on Opsgenie. Uhoh.

---

IN CONCLUSION

Are you seeing these posts Atlassian? JEC is solving a real problem. It's something that (at least some) customers WANT to pay for! (That isn't Enterprise, sorry. :-)

@Eugene Pak way back in Apr 2024 your What's New in Jira Service Management - April '24 post included the new ability for Automation to use JEC. @Dana Frederick posted the Loom recorded by @Makarand Gomashe demoing the feature, and so I'll pose these questions to y'all:

1. Is JEC going to be deprecated? What's on the roadmap?
2. Will JEC be made available to regular Jira Cloud users?
3. Can response data from JEC be made available to Automation in Premium sites, or maybe as an add-on? Apparently some people would be willing to PAY for this! (But not for Enterprise, sorry!)

Ohey, and I know @Charlie Gavey is always looking for feedback about Automation, so here's a bunch. :-}

[Belliveau, John]

Thanks @Darryl Lee for putting this all together! It would be a welcome change to see some engagement from Atlassian (not only on this matter, but in general). Appearances would seem to indicate they have been operating in stealth mode 😒