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.
Listing pending publication. Until then this goes to the Marketplace itself.
this panel is live - toggle a group, then press Launch
- deploy-api.ymlqueued
- migrate.ymlqueued
Closing this panel does not stop the deployment. Tracking continues on the server.
- auth
No personal access tokens
Every GitHub call runs as the app installation, on a short-lived token minted per operation and never stored.
- surface
No bots in comments
The deployment lives on the issue itself, next to the context and the audit trail it belongs to.
- hosting
No second tool to log into
Forge functions, Forge storage, Forge UI. Atlassian-hosted end to end, with no vendor server in the path.
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.
- 01
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.
- 02
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, and the execution mode is parallel or sequential.
- 03
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 nobody retypes the issue key.
- 04
Launch and walk away
Matching groups arrive preselected, inputs render pre-filled and validated, Launch dispatches. 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
A group can be open to the team and still be closed to production.
Every group is open by default: anyone who can edit the issue can launch it. That is the point of the app. The ones that are not like that carry three rules instead, and all three are enforced on the server, on the form load and again at launch.
- A restricted group is never sent to a browser that may not launch it, and a launch naming it is refused by name.
- If Jira group membership cannot be read, the check fails closed: the group stays hidden and the panel says the check could not be completed.
- Nothing vanishes without a word. The panel always says how many groups are hidden, and why.
Offered on issue types
BugTask
Picked from the project’s own scheme. Empty means every issue in the project.
Offered in statuses
Ready for release
Re-read at launch, so a panel that went stale cannot launch what the issue no longer qualifies for.
Who can launch it
Sam Riverarelease-managers
Jira groups are resolved live, by their stable ID, on every load and every launch.
What everyone else sees on the issue: 1 more group is restricted to other users. Ask a project administrator if you need to launch it.
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.
Configuration only
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.
- authorize account
- list installations
- stops here
Every operation
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.
- sign JWT
- mint token
- dispatch and poll
- discard
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.
Activity log
Deployment settings decide who can ship what, so they keep a record.
Not "the configuration was updated". Every launch, every refused launch, every settings change and every GitHub connection change, with the actual change written out. Readable by project administrators, scoped to their project, filterable by kind.
- GitHub Action invoked
Launched Backend (2 actions)
Backend / Deploy API - octo/checkout-api deploy-api.yml @ feature/PROJ-1234 with environment=staging
- Launch refused
Refused - was not allowed to launch Release to production
Release to production is restricted to other users.
- Settings changed
Changed 1 setting
Release to production: who can launch it anyone who can edit the issue -> Sam Rivera, release-managers
- GitHub connection
Pointed this project at a GitHub App installation
Account: octo-engineering
Showing 4 entries, more history is available, entries are kept for 90 days.
- what a launch keeps
Who, when, from which issue, which workflows in which repositories, at which ref, and the values they were dispatched with - copied into the entry, because the deployment record itself is swept after its own retention window.
- what a refusal keeps
Who tried, which group, and which rule said no: access, issue type, or status. Only policy refusals are recorded, so the ones that matter are not buried under invalid forms.
- how long
90 days, then swept. The footnote under the list always says what is on screen and what is not, so a short list is never mistaken for the whole history.
Everything the common case needs, none of the ceremony.
- jira:issueAction + jira:issueContext
Deploy from the issue
An issue action and an always-visible issue context panel.
- label: backend
Label-driven presets
Issues labeled backend preselect the backend group. No thinking required.
- sequential | parallel
Ordered multi-workflow deploys
Sequential with a failure policy, or parallel when order does not matter.
- api.github.com
Live dropdowns
Branches and environments come from GitHub itself, at the moment the form opens.
- {{issue.key}}
Templated defaults
The issue key, summary, project and user flow into workflow inputs on their own. Nobody retypes a ticket number.
- queue consumer + watchdog
Background tracking
Runs keep being followed after the browser is gone. No status stuck because a tab closed.
- Retry-After
Honest failure handling
GitHub's own Retry-After and rate-limit headers are respected. Transient network errors are retried, not reported as workflow failures.
- 5 minutes untouched
A status that admits doubt
When nothing has updated a running deployment for five minutes, the panel stops calling it current and offers the run on GitHub instead.
- one project, one connection
Per-project isolation
Every Jira project has its own GitHub connection and its own groups. One Jira site, many teams, many GitHub organizations.
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.
Every workaround you have now, and what replaces it.
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.
Listing pending publication. Until then this goes to the Marketplace itself.