100% Atlassian Forge
Deploy the ticket you are looking at.
Launch GitHub Actions workflows straight from a Jira issue, and watch them finish without leaving Jira.
Marketplace listing pending. This control becomes the listing link at publication.
- no personal access tokens
- no bots in comments
- no second tool to log into
- deploy-api.ymlqueued
- migrate.ymlqueued
closing this panel does not stop the deployment
The problem
Shipping a ticket to staging is rarely one click.
A tester needs PROJ-1234 on staging. They ping a developer, because they cannot run the pipeline themselves. The developer hunts for the right repository, the right workflow, hand-types the branch - often several workflows, in the right order. Then everybody goes back to Jira and waits for someone to comment "done".
The handoff
Testers, PMs and designers cannot deploy, so every deployment queues behind the few people who can - and they are always busy.
The tribal knowledge
Which workflow, which branch, which inputs, in which order. It lives in people's heads and in pinned Slack messages.
The mistakes
A typo in a branch name, the wrong environment, the migration that was supposed to run first.
The missing trail
Jira says "In testing". GitHub says a workflow ran. Nothing connects the two.
The usual workarounds are worse. A shared personal access token attributes every deployment to one person, and one leak is total access. Giving everybody GitHub write access is not a permission model, it is a shrug. A ChatOps bot just moves the tribal knowledge into a different chat window.
How it works
Configure once per project. Then anyone who can edit the issue can deploy it.
Connect the project
An administrator authorizes their GitHub account and picks a GitHub App installation. The app validates it and loads its repositories - repositories are always chosen from that list, never typed by hand. Disconnecting removes only that project’s mapping.
Define Actions groups
A group bundles every workflow behind one kind of deployment: Deploy API, then Run migrations, then Invalidate CDN. Jira labels preselect it, the execution mode is parallel or sequential, and sequential groups carry a failure policy: stop, or continue.
Describe the inputs once
Six input types cover what deployment workflows actually ask for. Any input can carry a default template built from safe placeholders, so a workflow is told which ticket it is deploying without anyone retyping the issue key.
Launch and walk away
Matching groups arrive preselected, inputs render pre-filled and validated, Launch dispatches. Parallel groups fire at once; sequential groups advance action by action. Closing the panel does not stop the deployment - tracking continues on the server.
| Type | The user sees | Notes |
|---|---|---|
| string | Text field | - |
| choice | Dropdown | Options defined by the administrator |
| boolean | Toggle | - |
| number | Numeric field | Optional min and max |
| environment | Dropdown | Live GitHub Environments of that repository |
| branch | Dropdown | Live branches of that repository |
{{issue.key}}{{issue.summary}}{{project.key}}{{user.displayName}}- safe placeholders available in every default template
Security model
There is no personal access token anywhere in this app.
No shared secret in an environment variable that everybody's deployments run through, and no fallback to one if something fails. Two GitHub identities do two different jobs.
A project administrator connects their GitHub account through Forge External Authentication. It is used for exactly one thing: discovering which GitHub App installations that person may pick from. It never runs anything.
Reading branches and environments, dispatching workflows, polling runs: all performed as the GitHub App installation, using short-lived tokens minted from a JWT signed with the app's private key. Tokens are never stored.
Least privilege, your repos only
- Actions - read and write
- Contents - read
- Environments - read
- Metadata - read
Jira permissions decide
Launching needs EDIT_ISSUES; changing configuration needs project admin. Both are re-validated on the server on every save and every launch - the browser is never trusted.
Two hosts, nothing else
The app talks to github.com and api.github.com. No dynamic egress, no telemetry endpoint, no third party in the path.
Workflow inputs are not secret. They are visible operational data, by design. Never pass passwords, tokens, or credentials through them.
Built on Forge, and only Forge
Forge functions, Forge storage, Forge external authentication, and a UI rendered natively by Atlassian. No Connect modules, no iframes hosted somewhere else, and no data leaving Atlassian's infrastructure for a vendor-run server, because there is no vendor-run server. For an admin evaluating the app, the data-residency and security posture is Atlassian's, not ours.
What you get
Everything the common case needs, none of the ceremony.
Deploy from the issue
An issue action and an always-visible issue context panel.
Label-driven presets
Issues labeled backend preselect the backend group. No thinking required.
Ordered multi-workflow deploys
Sequential with a failure policy, or parallel when order does not matter.
Live dropdowns
Branches and environments come from GitHub itself, at the moment the form opens.
Background tracking
A queue consumer plus a watchdog keep following runs after the browser is gone. No status stuck because a tab closed.
Honest failure handling
GitHub's own Retry-After and rate-limit headers are respected. Transient network errors are retried, not reported as workflow failures.
QA and testers
Who need a specific branch on a specific environment, right now, without asking anybody.
Developers
Who are tired of being the deployment button for their team.
Release and platform engineers
Who want the deployment path standardized and least-privilege, not GitHub write access handed out.
Product managers
Who want to know whether the ticket is actually deployed without reading a workflow log.
Why not the alternatives
Instead of → you get
A shared PAT in a script
Per-installation GitHub App auth, short-lived tokens, nothing stored
GitHub write access for everyone
Deployment rights granted through Jira issue permissions
A ChatOps bot in Slack
The deployment lives on the ticket, where the context and the audit trail already are
"Just click Run workflow"
The right workflows, in the right order, with the right inputs, pre-filled
A Connect-based integration
100% Forge: no vendor server, no external iframe, Atlassian-hosted end to end
Frequently asked
The questions admins ask first.
Any workflow with a workflow_dispatch trigger, committed to the repository’s default branch - that is what GitHub reports through its API. The workflow itself can run on any branch you point the action at.
No. Nothing has to be exposed or configured on the GitHub side beyond installing the app.
Not currently. The app targets github.com.
Editing the connection is blocked until an administrator reconnects. Deployments already running are unaffected - they run under the installation identity, not yours.
No. Tracking continues server-side and the status is waiting when the issue is reopened, by anyone.
Yes. The GitHub connection is per Jira project.
Deploy the ticket you are looking at.
From Jira, with GitHub Actions, without a token.
Marketplace listing pending. This control becomes the listing link at publication.