RFCs are a way for Atlassian to share what we’re working on with our valued developer community.
It’s a document for building a shared understanding of a topic. It expresses a technical solution but can also communicate how it should be built or even document standards. The most important aspect of an RFC is that a written specification facilitates feedback and drives consensus. It is not a tool for approving or committing to ideas, but more so a collaborative practice to shape an idea and find serious flaws early.
Please respect our community guidelines: keep it welcoming and safe by commenting on the idea, not the people (especially the author); keep it tidy by staying on topic; and empower the community by keeping comments constructive. Thanks!
Project summary
This RFC introduces the Developer Space construct, focusing on role management, permissions, workflows, and future plans. It invites feedback on the proposed roles and design flows.
-
Publish: 2025-10-13T18:30:00Z
-
Discuss: 2025-10-19T18:30:00Z
-
Resolve: 2025-10-23T18:30:00Z
Problem
Following the recent release of developer spaces, we received feedback from both our internal teams and the developer community.
Key feedback themes
-
Adhere to the principle of least privilege regarding role assignments. Do not automatically assign Marketplace permissions to console roles or vice versa.
-
Roles and their associated permissions must be transparent to users. Users should be able to grant additional permissions or roles only at their discretion.
-
A Marketplace vendor account will not be created, nor will access to its views or Marketplace roles be provisioned upon the creation of a new developer space. Publication of the developer space on the Marketplace will occur only after acceptance of the Marketplace terms and conditions.
-
Some partners have shared that the term “Developer Space” might not fully capture the vision of unification we’re aiming for. Marketplace administrators and finance team members may not feel included in this unified developer space concept because of the name.
Based on the valuable feedback we’ve received from both internal teams and the developer community, we have refined our solution and are now inviting the community to review and share their thoughts on this updated proposal.
Proposed solution
What is Developer Space? Why are we building this?
As detailed in the Forge pricing update blog, invoices for Forge usage will be issued every month per developer space.
A developer space brings together multiple Forge apps—including development, testing, and Marketplace apps—created by individuals, partner organizations, or customers building Forge apps. Each developer space receives a single invoice that consolidates charges for all apps exceeding the free resource threshold. This setup is designed to simplify your payment management, so you can easily add a payment method that covers all your apps in the developer space at once.
Vision: The Future of Developer Space
Note: All screens in this section are presented solely for illustrative purposes, and the designs remain subject to modification. This represents our comprehensive long-term vision. Timelines are currently under evaluation and are yet to be finalized.
Unified User Experience and Role Management: We will consolidate the Developer Console and Marketplace vendor portals into a unified user interface and standardize roles into a single comprehensive list. This integration will still guarantee that members possessing the appropriate roles can access the relevant views and detailed information within a singular portal, thereby facilitating a seamless and cohesive end-to-end application management experience.
User groups: We will implement user groups. Organizations can assign members specific roles within particular forge applications. This approach provides an intermediate level of access control between application-level contributor roles and the forthcoming developer space-level roles, as detailed below.
Connecting developer spaces to the organization: We will integrate developer spaces with the organization, thereby provisioning managed accounts. This integration also enables the Forge team to integrate your forge apps with Atlassian Analytics and other additional Atlassian tools, thereby providing enhanced observability and monitoring capabilities for your Forge applications.
Revised proposal for Developer Spaces role management
Roles overview
| Role Name | Developer space touchpoint | Description |
|---|---|---|
| Billing Admin | Billing console | Manages billing for Forge resource usage costs (not Marketplace revenue). |
| Admin | Marketplace vendor profile | Manages the Marketplace vendor account within a developer space. |
| Admin | Developer Console | Managing the Developer Console only within a developer space. |
| Developer | Developer Console | Can build and manage those apps in the Developer Space. |
| Viewer | Developer Console | Read-only access is provided only within the Developer Console in a developer space. |
Important Notes:
- It is possible to assign multiple roles to an individual, thereby providing a combined set of permissions. For example:
- An individual can be both a Developer Console Admin and a Billing Admin, allowing them to manage apps and oversee billing for Forge usage within the same developer space.
- Another individual might be assigned both the Marketplace Admin and Developer Console Admin roles, enabling them to manage the Marketplace vendor account as well as administer apps in the Developer Console.
- These roles are separate from the Contributors app roles.
Billing management
Billing management permissions control access to invoices, payment methods, billing admin management, and billing-related app visibility. These are managed in the dedicated developer space’s billing account created at Billing Console. This is related only to Forge costs and not the marketplace revenue management, which will continue to be managed in the Marketplace vendor profile.
| Permission | Billing Admin | Admin | Admin | Developer | Viewer |
|---|---|---|---|---|---|
| Developer Space Touchpoint | Billing Account | Marketplace | Developer Console | Developer Console | Developer Console |
| View invoices |  |
– | – | – | – |
| View the last four digits of the payment method | |
– | |
– | – |
| Edit or remove the payment method | |
– | – | – | – |
| Add or remove billing admins | |
– | – | – | – |
| View addresses (billing and sold-to) | |
– | – | – | – |
| View all developer space apps in the billing account with the next bill estimate and date | |
– | |
– | – |
| View billing admins | |
– | |
– | – |
Important Notes:
- The first console admin to consent to app invoicing becomes the initial billing admin. This billing admin can add other billing admins directly to the billing account.
App management
App management permissions cover user role assignment, app creation and linking, app transfers, and default app viewer access.
| Permission | Billing Admin | Admin | Admin | Developer | Viewer |
|---|---|---|---|---|---|
| Developer Space Touchpoint | Billing Account | Marketplace | Developer Console | Developer Console | Developer Console |
| Add users to console roles | – |  ¹ |
|
– | – |
| Edit user console roles | – | – | |
– | – |
| View team members with Developer Space roles of Admin, Viewer, and Developer in the Developer Console | – | |
|
|
|
| Create a new Forge app in a developer space | – | – | |
|
– |
| Associate an existing unlinked private app to a developer space (must be app admin also) | – | – | |
|
– |
| Initiate transfer of non-marketplace apps between developer spaces | – | – | |
– | – |
| Auto-added to all Forge apps as app viewer contributor role (unless other roles assigned in the app) | – | – | |
² |
|
Important Notes:
- ¹ For marketplace vendor profiles without any console admins, Marketplace admins can add up to five console admins in the developer console. Once at least one console admin is added successfully, they lose the option to add further console roles. This supports the initial roles setup process on the console side.
- ² The console developer must select the add-on permission checkbox to be automatically added as a viewer to all developer space apps (unless other roles are assigned). Without this selection, they see only apps where they are contributors.
Developer Space management
Developer Space management permissions relate to space lifecycle and metadata.
| Permission | Billing Admin | Admin | Admin | Developer | Viewer |
|---|---|---|---|---|---|
| Developer Space Touchpoint | Billing Account | Marketplace | Developer Console | Developer Console | Developer Console |
| Archive developer space in console (if zero apps) | – | – | |
– | – |
| Edit metadata of developer space (name, logo) | – | ³ |
⁴ |
– | – |
| View metadata of developer space (name, logo) | – | |
|
|
|
Important Notes:
- The first person to create the developer space becomes the console admin.
- ³ Marketplace Admin can edit metadata after the developer space is published in the marketplace
- ⁴ Console admin in the developer console can edit metadata until the Marketplace profile is set up; then Marketplace team members with the right permissions take over.
Marketplace permissions
Marketplace permissions are specific to Marketplace Admins and relate to partner profile, publishing, and reporting. We are not making any changes to the permissions on the Marketplace.
| Permission | Billing Admin | Admin | Admin | Developer | Viewer |
|---|---|---|---|---|---|
| Developer Space Touchpoint | Billing Account | Marketplace | Developer Console | Developer Console | Developer Console |
| Manage partner profile, handle payments/pricing, publish/market apps, access reports | – | |
⁵ |
– | – |
Important Notes:
- ⁵ For unpublished Developer Spaces, the first admin in the developer console becomes the initial admin of the Marketplace vendor account when they accept the Marketplace terms to publish the developer space in Marketplace.
- When a person creates a marketplace vendor profile directly on the marketplace, they become the marketplace admin, and the developer space is published from day one for this scenario.
Proposed Flows
The Figma prototype below starts on the Developer Console landing page and covers the experience of a Marketplace admin setting up their Developer Space with:
- Adding the first admin roles in the developer console
- Adding a billing admin role
- Adding a payment method
- Creating a new Developer Space
- Assigning an app to a Developer Space
Clicking in the prototype will display hints of where to click. (not everything is clickable). To reset the prototype to the beginning, hit the ‘r’ key!
You can leave feedback directly on the prototype via the comments tool, which you can find on the top left of the prototype.
Figma prototype link 
Asks
Request for Feedback
This RFC is focused only on the Developer Space construct, role management, and forthcoming plans. We are seeking your input on:
- The proposed roles and permissions, their names, and whether they fit your use case.
- Any concerns or observations regarding the proposed design workflows
- We’d love to hear your thoughts on the naming options for Developer Space. Please take a moment to share your feedback in this survey Forge app terminology - Naming Survey
- We are seeking feedback on an alternative name for the “developer” role in the developer space
- Given that organisations will now be charged for Forge usage, with the new roles, are partners confident about being able to control who has access to building apps and can incur costs?
- Any additional comments or considerations pertaining to the content of this post
Not covered in this RFC (but planned for January 2026)
- Billing mechanism, observability, etc
Future roadmap (Timelines are To Be Determined)
- Additional roles in Marketplace
- Option for users to create their own roles in the Developer Console or the Marketplace
- User groups and app groups to manage a subset of apps in a Developer Space
- Managed accounts, Atlassian Access/SAML-based role management
Frequently Asked Questions (FAQs)
-
What will happen to app contributor roles?
App contributor roles remain unchanged. The new Developer Space roles operate at a higher level, managing access across all apps in a space. If you want to limit someone’s access to a single app, assign them an app-level role instead of a space-level role. -
Does the experience change for current app contributors without space-level roles?
No, users can still only access apps where they are contributors. They have limited Developer Space access: they can see their own apps in the space, but not other apps or space-specific options like members or settings.
-
What happens to existing Marketplace vendor profiles?
A Developer Space will be automatically displayed in the Developer Console, using the same name as your Vendor Profile. When you log in, you’ll see the new space and your apps. As a Marketplace admin, you’ll need to assign console admin privileges (to yourself or others) to manage the space. This is a one-time setup. -
Can multiple developer spaces be linked to a single Marketplace vendor profile?
No. Each Marketplace vendor profile is linked to a single Developer Space, reflecting our unified approach. There is always a 1:1 mapping between a vendor profile and its Developer Space. -
Who can assign an unpublished Forge app to a developer space?
To assign an existing private Forge app to a Developer Space, you must have the admin role in the app and either the console admin or developer role in the space. This ensures only authorized users can link apps at the space level. -
How will new Forge apps that are created or registered on the CLI link to a Developer Space?
- With the new CLI, when you register or create a new app, you’ll be prompted to assign it to an existing Developer Space or create a new one.
- Apps created with earlier CLI versions can be linked via the Developer Console.
. I love the idea of one single point of truth and the different roles seem to cover everything for us as a Marketplace Partner.