Hey everyone π
Over the last few weeks I've been going deep on the Atlassian ecosystem and building real Forge apps end to end. Luna is the latest β and honestly the one I'm most excited about, because it solves a problem I felt myself every single day as a developer. Sharing it here for feedback, and because I'd love to connect with others (and folks at Atlassian) building in this space.
The problem I wanted to kill A developer opens a Jira issue and immediately has questions that Jira can't answer: What branch is this on? Is there an open PR? Did the pipeline pass? What's actually deployed to staging? Answering them means leaving the issue and bouncing across tools β Jira β Bitbucket β CI/CD β deployment dashboards. Every hop is a context switch, and context switches quietly tax focus and flow all day long. The information already exists. It's just never where the developer is looking.
So I brought it to them.
What Luna does Luna is a Forge UI Kit app that lives right in the Jira issue panel. Open an issue and it instantly shows that issue's Bitbucket reality:
Pipeline β latest Bitbucket Pipelines run for the relevant branch (Passing / Running / Failed) with build number, commit, and timestamp πΏ Branches β branches that reference the issue key π Pull Requests β related PRs with state, author, and review summary π Recent Commits β the last few commits with hash, message, and author π Deployments β per-environment health (Production / Staging) where the repo uses Bitbucket environments
All in clean status-lozenge cards, each linking back into Bitbucket. The developer understands the full development and deployment state of an issue without ever leaving Jira.
Why I think it matters This is the kind of "reduce context-switching, keep developers in flow" problem that compounds across an entire team. One saved tab-hop is trivial; thousands a week across an org is real productivity. That's the thesis Luna is built on.
Engineering decisions I'm proud of Security first. Bitbucket auth (an Atlassian API token) lives in an encrypted Forge environment variable, read only inside a resolver β it never touches the frontend. Every external call is backend-side. No fragile assumptions. Workspace, repo, and credentials are all configuration. I never assume the Jira project key equals the repo name, that every issue has a branch, that every branch has a PR, or that every repo runs Pipelines/deployments. Graceful degradation over fake data. No deployment environments? The panel says so β it never invents a status. Same for no branch / no PR / no pipeline. Honest, typed errors. Structured error codes (auth / permission / repo-not-found / API failure) drive clear per-case UI messages instead of a generic crash β and real errors are never hidden. Performance built in. Assembled results are cached in Forge KV (~5 min TTL per issue) with a manual Refresh that bypasses the cache; a lozenge shows cached vs. live. Minimal scopes. Only what each feature needs β read:jira-work, backend external fetch to api.bitbucket.org, storage:app.
Tech stack Forge UI Kit (@Forge /react) Β· Forge resolvers (@Forge /resolver + @Forge /api) Β· Jira REST API Β· Bitbucket Cloud REST API v2 (branches, PRs, Pipelines, commits, deployments via a declared remote + egress) Β· Forge KV Storage (@Forge /kvs)
This is one of four Forge apps I've shipped recently (alongside an AI JSM knowledge-base assistant, a Confluence/Jira sprint dashboard, and an AI sprint-health + auto-escalation panel), all cross-product Atlassian integrations. I'm genuinely enjoying building on this platform and want to go a lot deeper.
Questions for the community For linking an issue to Bitbucket work, I match on the issue key in branch/PR names. Has anyone had better results using Bitbucket's native development-panel links instead of name-matching? Tradeoffs at scale? Deployments are optional per repo β any clean patterns for detecting deployment environments before rendering that section, beyond /environments + handling empty/404? Any gotchas with Bitbucket API tokens + read:pipeline:bitbucket, or rate limits on /pipelines and /commits at scale?
Happy to go deep on any part β architecture, the caching layer, the error model, whatever's useful. Feedback very welcome, and always up to connect with other Forge builders (and the Atlassian team π). π
