Custom apps for Jira and Confluence, built on Atlassian's own platform — priced before you commit.
Forge is Atlassian's app platform for Jira, Confluence and Jira Service Management. You write the app; Atlassian runs it. There is no server to provision, no certificate to renew and no third-party cloud for a security team to review — the functions execute inside Atlassian's own infrastructure, next to the data they operate on.
In Atlassian's own words, Forge “replaces Connect” and “will become Atlassian's only app development platform.” That is the whole reason this page exists rather than a page about Connect.
A Forge app is a manifest plus some functions. The manifest declares which modules the app adds, which Atlassian scopes it needs and every external domain it is allowed to call. For a security team that turns “where is this vendor hosting our data” into “what does this manifest ask for” — a question with a written answer.
UI Kit renders Atlassian's own components, so the app inherits Jira's look and behaviour for almost no front-end work. Custom UI gives you a sandboxed frame and your own React build, which is what a rules table or a console actually needs — at the cost of owning the styling, dark mode included. We wrote a tutorial on getting that right because it is the part that bites.
It is not general-purpose hosting. Long work has to move onto the async queue instead of running inline. Every call to a system that is not Atlassian has to be declared up front and is shown to whoever installs the app. And some problems are not app problems at all — see below before you pay us anything.
Two of the tutorials we publish here solve real Jira problems with configuration and zero code: blocking time logging on specific work types using workflow properties and getting a default field value back when “None” disappears. If your problem is one of those, we will say so — and it costs you nothing.
A custom app is the most expensive of the four ways to change how Jira or Confluence behaves. Here is honestly where each one fits, and the point at which each stops.
Good at
No-code rules for the common shapes — transition on a condition, notify someone, sync a field, run on a schedule. Free, instant, nothing to deploy.
Where it stops
A fixed vocabulary reacting to events. Anything with its own screen, its own data model, or judgement that a rule builder cannot express is out of scope.
Good at
Deterministic scripted logic for teams that already have the Groovy or JS skills and the appetite to maintain what they write.
Where it stops
You write and own code inside somebody else's app, on top of a second vendor licence — and you cannot ship the result to anyone else.
Good at
The framework a large share of existing Cloud Marketplace apps still run on. If you already have a Connect app, it still works today.
Where it stops
Atlassian is retiring it on a published timeline. New Connect apps cannot be listed at all, and existing ones are frozen. Starting here is buying a migration.
Good at
Atlassian-hosted compute and storage, a declared permission model, and every extension point the platform offers — validators, panels, custom fields, admin pages, scheduled jobs.
And then some
It is the platform Atlassian is standardising the whole ecosystem on, so an app built here is the one that does not need rebuilding in two years.
Atlassian published the timeline in March 2025 and it runs in three phases, two of which have already passed. Since 17 September 2025, no new Connect app can be listed on the Marketplace at all — a new Cloud app “must be created on Forge and may not contain any Connect modules.” From 31 March 2026, existing Connect apps are frozen: vendors can still fix what is broken, but they cannot add new modules, scopes or surfaces. At the end of 2026 Connect reaches full end of support and becomes, in Atlassian's phrase, “use at your own risk.”
For Marketplace apps this is mostly the vendor's problem. For the integration your own team wrote in-house on Connect years ago, it is entirely yours — nobody is coming to migrate that one.
Named by the module, because that is what actually gets declared in the manifest and what decides whether your idea is a two-day app or a two-week one.
Gate a Jira transition, hide it entirely, or act after it fires. This is the densest part of the platform and the one we know best — CogniRunner is built entirely out of these three module types.
See it shippedContextual surfaces that sit inside the issue or the Confluence page — showing data, offering an action, or warning about state. Sentinel Vault's page banner tells a reader a file on that page is sealed before they touch it.
See it shippedField types Jira does not ship — with their own edit view, their own read view, and their own rules about what a valid value is. The part people underestimate is search and indexing behaviour, not the UI.
The screen where an admin configures the app: settings, permissions, roles and scopes. CogniRunner ships Viewer, Editor and Admin roles with a scope that narrows a role to a user's own rules — so delegation does not mean handing over everything.
Queued consumers and cron-style triggers for anything too slow or too periodic to run inside a request. Sentinel Vault runs an hourly expiry sweep, an hourly index rebuild, a daily nudge and a real-time attachment trigger.
Calls out to systems that are not Atlassian — an LLM provider, an internal API, a CMDB — each domain declared in the manifest and visible to the installing admin. We published a full tutorial on wiring an LLM into a Forge app for Jira.
Read the tutorialTwo of them, publicly listed on the Atlassian Marketplace, both open source. That is a more useful thing to judge us on than an adjective.
Forge app for Jira · AGPL-3.0
A semantic layer for Jira workflows. Native validators check structure — required, not empty, matches a regex. CogniRunner checks meaning: it sends field content, attachments and related issues to an AI model and evaluates them against criteria you describe in plain English, then validates, decides and acts on the transition.
Background reading: the gap nobody filled and local AI, zero-key models and actions that write back.
Forge app for Confluence · paid via Atlassian · open source
Confluence has no native file locking — any user with edit access can upload a new version of any attachment at any time. Sentinel Vault adds a platform-enforced seal layer on top of Confluence attachments and page sections, plus an enforced approval workflow — violations are detected in real time and reverted automatically.
Three stages, and you get a price at each one before it starts. Almost nobody in this market publishes a number — that is the whole reason we do.
days, not weeks
Every engagement starts here. We build the risky part first — the module that actually has to work — and put it on a demo site or, if you prefer, your own instance. You click it. Nothing about the price of the full build is guessed until this exists.
~2 days to ~1 month
Once the prototype is in front of you, the size is no longer a guess and we quote a flat price for the rest: S €1,000 (~2 days), M €2,000 (~1 week), L €4,000 (~2 weeks), XL €12,000 (~1 month). Anything larger we scope together rather than pretend a tier covers it.
no retainer lock-in
Going live, the Atlassian listing review if you want the app published, and everything after launch is billed by the hour at a flat €50. No retainer, no minimum. We can also set your own developers up to keep building on it.
Already running Atlassian Cloud and just need someone to keep the app healthy? That is Atlassian maintenance, same flat hourly rate.
Every engagement starts with a €500–€1,000 prototype. Describe the app and see a transparent UAT price — the final size is confirmed after the prototype.
Hi! I'll help you scope a custom Jira/Confluence app — in plain English, no tech jargon. To start: what would you love this app to do, or what headache should it take off your plate?
Going to production, ongoing changes, and keeping the app healthy after launch are billed by the hour at a flat €50/hour — no retainer lock-in. We can also help your own team get set up to develop with AI.
None of this is in the sales pitch, and all of it decides what the app costs. The numbers below are the ones we actually work against — platform limits marked as platform limits, and our own design choices marked as ours.
| Constraint | Value | Notes |
|---|---|---|
| Synchronous function timeout | 25 seconds | Forge platform limit. CogniRunner budgets 22 seconds for an agentic validation so it always returns a verdict rather than timing out on the user. |
| Async queue consumer timeout | 900 seconds | The escape hatch from the 25-second cap. Sentinel Vault's realm scan consumer runs here for space-wide seal audits. |
| External egress | Declared per domain | Every non-Atlassian domain the app calls is listed in the manifest and shown to the admin installing it. Undeclared calls fail. |
| App storage | Forge platform storage | App data lives inside Atlassian, per installation. Sentinel Vault keeps everything there and has no external dependency at all. |
| Attachment size — our cap | 10 MB / file | A CogniRunner design limit, not a Forge one. Files above it are skipped, and the AI is told they were skipped rather than silently losing them. |
| Total attachments — our cap | 20 MB | Combined size across all attachments per CogniRunner validation. Again ours, chosen to fit the 25-second budget. |
| Upload size — our cap | 4 MB / file | Sentinel Vault's inline panel and overlay upload zone. Ours, not the platform's. |
A Forge function invoked synchronously has 25 seconds. That is plenty for a panel and nowhere near enough for a space-wide audit or a model call chain. The fix is architectural, not a flag: the slow work moves onto an async queue whose consumer gets a much longer timeout — 900 seconds in Sentinel Vault's realm scan. Anyone quoting you a Forge app without asking which of your operations are slow has not thought about this yet.
App data lives in Forge's own storage, per installation. The interesting constraints are usually the ones you impose on yourself to stay inside the time budget — CogniRunner skips attachments over 10 MB and caps a validation at 20 MB total, and tells the model what it skipped so the reasoning stays honest. Those are our numbers. We will tell you which of your numbers we would pick, and why.
The moment your app calls something outside Atlassian, that domain goes in the manifest and the admin installing it sees it. It changes the security conversation and it changes what you have to be able to answer. A clean automated scan, incidentally, is not the same thing as a secure app — we wrote up exactly why, including the classes of risk Forge scanning structurally cannot see.
Forge apps render inside an iframe on a real Atlassian site, behind a real login. Unit tests against mocks will happily pass while the deployed app is broken. We drive the real, deployed UI — here is how we run end-to-end tests against a deployed Forge app, including getting past the login that headless browsers cannot.
Choose Custom UI and you own the styling, which means you own dark mode. It is the single most common way a Forge app looks unfinished on day one, and it is entirely avoidable — dark mode done right in Forge Custom UI.
Every engagement starts with a €500–€1,000 prototype. After you have clicked it, the build to a UAT-ready app is flat-priced by size: €1,000 for a small focused app, €2,000 for a few connected features, €4,000 for a bigger multi-part app and €12,000 for a large full-featured one. Production go-live, support and Marketplace work are billed at a flat €50 per hour with no retainer.
The prototype takes days. From there the UAT-ready build runs roughly two days for a small app, a week for a few connected features, two weeks for a multi-part app and about a month for a large one. The listing review, if you want the app on the Atlassian Marketplace, sits outside our control and adds time.
Yes. You get the code, the knowledge and ongoing support, so you can keep building on it with us or without us. Both of the apps we publish ourselves are open source — CogniRunner is AGPL-3.0 with the full source on GitHub — which is a fair indication of how we feel about locking code away.
Forge. Since 17 September 2025 a new Cloud app cannot be listed on the Atlassian Marketplace on Connect at all, and from 31 March 2026 existing Connect apps are frozen — vendors can no longer add new modules, scopes or permissions. Connect reaches full end of support at the end of 2026. Building anything new on Connect today is buying yourself a migration.
Yes, and this is the work with a real deadline attached. Marketplace vendors are carrying their own apps across, but the integration your team wrote in-house years ago is nobody else's job. We rebuild it on Forge, starting from the same €500–€1,000 prototype so you can see the risky part working before committing to the rest.
Yes. We have taken two of our own apps through it — CogniRunner for Jira and Sentinel Vault for Confluence are both publicly listed on the Atlassian Marketplace. We also publish what we learned about Forge security scanning, including why a clean automated scan is not the same as a secure app.
It depends on the module, and we tell you which before you buy rather than after. CogniRunner, for example, runs on both company-managed and team-managed Jira projects. Some Jira extension points behave differently between the two, so the answer is part of the prototype, not an assumption.
By default, nowhere outside Atlassian. Forge runs your app on Atlassian's own infrastructure and stores its data in Atlassian's platform storage. Sentinel Vault has no external dependency at all — no third-party services, no API keys, no egress. If an app does need to call something outside Atlassian, that domain has to be declared in the manifest and is shown to whoever installs it.
Describe the app in a couple of minutes and see the prototype and UAT numbers, or just ask us whether it needs to be an app at all.