RFC:113 - Free App entitlements on Sandboxes

[AdithyaRamesh]

Project Summary

We are actively working towards the general availability of Multiple Sandboxes, a feature that allows customers to attach more than one sandbox to a production site. This will allow enterprise customers to parallelize testing for various work streams and setup change management processes across Dev → Staging → Prod environments.

As part of this release, we want to ensure that sufficient guardrails are in place to ensure that our partners are not adversely affected by the capability. Thus, we are looking to cap the number of sandboxes an app can be added to for free to ensure fair use.

Publish: 23 Sept 2025

Discuss: 7 Oct 2025

Resolve: 21 Oct 2025

Problem:

Today, if a customer has a paid subscription for an app on the production environment, the app can be added for free on the sandbox. More details here: Manage apps for a sandbox | Atlassian Support

With the general availability of multiple sandboxes per site, customers will have the option to purchase additional sandboxes beyond the default limits included in their license. This means that, in theory, they could install an app on many sandboxes for free if they only pay for it on one production site.

Proposed Solution:

With the general availability of Multiple Sandboxes, purchasing a Marketplace app for a production site allows the customer to use up to 5 copies of that app on associated sandbox instances at no additional cost. We’ve arrived at this number based on the analysis of customer usage statistics of apps in sandboxes during the Open Beta of multiple sandboxes.

Sample Scenarios & Behaviour:

Scenario 1: A CEE customer has a total of 2 sites and 10 sandboxes. They have purchased the app subscription on both the sites. Each site has exactly 5 sandboxes linked to it.

Proposed Behaviour: The app will be available for free on all the sandboxes.

Scenario 2: A CEE customer has only 1 site. They have purchased the app subscription on the site. The site has 7 sandboxes linked to it.

Proposed Behaviour: The app, at any given point in time, can be installed for free on 5 sandboxes. If the customer needs it on a 6th sandbox, then the customer needs to uninstall the app from one of the other sandboxes, or purchase the app for exclusively using it on the 6th sandbox.

Scenario 3: A CEE customer has a total of 2 sites and 10 sandboxes. They have purchased the app subscription on only one site (site 1). Each site has exactly 5 sandboxes linked to it.

Proposed Behaviour: The app will be available for free only on the 5 sandboxes linked to site 1.

Points to note:

1. We will continue to monitor the usage of apps on sandboxes, and will revisit this proposal based on usage data and customer feedback

2. We will grant time-bound exemptions from this limit to customers who are in the process of migrating from DC to cloud in order to facilitate better testing and accelerate their migration to the cloud.

Asks:

While we would appreciate any reactions you have to this RFC, we’re especially interested in learning more about:

• What do you think about the proposed change’s impact on your app?

• Do you foresee any potential challenges to your app’s operation because of the change?

If you’d like to talk to us about this proposal, please schedule 1:1 time through this calendly link. Thank you!

[marc]

Is Forge billing also integrated with sandboxes? By that I mean will there be billing for Forge for app vendors? Or can we serve Forge apps for free without a charge from Atlassian on sandboxes?

[BorisBerenberg]

@AdithyaRamesh

customers will have the option to purchase additional sandboxes

Has Atlassian considered allowing customers to purchase additional sandboxed apps? Seems odd that customers pay Atlassian for the service, but we give ours away for free?

[markrekveld]

Some question on this:

1. Will license/subscription/transaction records be updated so vendors can identify sandbox usage?
2. Will the Developer Console be updated to list sandbox instances and their usage?
3. What is acceptable usage for a sandbox app by a customer?
4. Will vendors be able to impose limits on sandbox installations of apps? (To reduce costs of providing this service)
5. Will Forge usage for these free apps be billed to the customer, Atlassian, or the vendor?
6. What are the expectations of customers and Atlassian when it comes to app data within sandbox instances?
   • Should the app support migrating between instances?
   • Or is it only for testing and throwing it away and redoing/replaying steps on their production instance?
   • How long are sandbox instances kept for?

I also support the idea from @BorisBerenberg to allow customers to purchase additional sandboxed apps. And would also support if its for a reduced price since its for testing only and should have limited usage because of that.

I’ll also take you up on your invite to schedule a 1:1

[AaronMorris1]

@AdithyaRamesh

If the customer needs it on a 6th sandbox, then the customer needs to uninstall the app from one of the other sandboxes, or purchase the app for exclusively using it on the 6th sandbox.

@AdithyaRamesh – The above scenario will not be easily supported in the new admin experience, where it can take 30 days to remove an app from a Cloud site:
https://community.developer.atlassian.com/t/unistalling-app-with-the-new-admin-expirience/95447

I suggest that Atlassian should improve customers’ abilities to manage app installations as part of this RFC. Otherwise:

1. Customers will have a hard time managing the number of sandbox instances in which an app is installed.
2. Vendors will incur unnecessary Forge platform fees as sandbox apps linger for 30 days before they are deleted by Atlassian.

Sorry if I’m misunderstanding something.

[MattDoar]

@markrekveld

Will Forge usage for these free apps be billed to the customer, Atlassian, or the vendor?

Mark wrote:

”Will Forge usage for these free apps be billed to the customer, Atlassian, or the vendor?”

This is an key question

[danielwester]

As the admins spin up the sandboxes - do they re-agree to the vendor’s terms of service? If they don’t there could be a problem… Also - can sandboxes be in different data regions?

[nathanwaters]

Atlassian right now is like a hundred separate teams all running off cliffs in every direction.

Are multiple sandboxes really a necessary feature?

There are already many unresolved bugs with licensing, billing and installing apps for a single sandbox.

And obviously the Forge usage costs element of this has been completely overlooked in the RFC. The partner comments in this thread all immediately understood the financial risk and burden of this change.

[david]

@nathanwaters

Atlassian right now is like a hundred separate teams all running off cliffs in every direction.

This perfectly describes so much I see in RFCs, but key things are still blocking the move from Connect to Forge – As they have been for the last 6 years – Is Forge really that old and not reached feature parity with Connect yet?

Btw, with Connect we had to suck up the costs of hosting these sandboxes for free, but at least we had a choice of hosting rather than a monopoly.

Maybe it’s time to charge for sandboxes? Problem solved.

[ernst.stefan]

I think as a vendor you will need to option to restrict sandbox usage. I guess for some apps (email processing for example), it does not even make sense to provide these for sandboxes while others (mine included) will be able to support an almost unlimited amount of sandboxes

[tobitheo]

I generally like the intention behind this RFC. I can see that this feature would be quite useful for some admins

What do you think about the proposed change’s impact on your app? Do you foresee any potential challenges to your app’s operation because of the change?

Compute resource usage on Forge is going to be a main factor for most of our apps. While most of them don’t use resources unless they are used, some of them have scheduled triggers that run regardless.

So there will be a cost increase which might necessitate an impact on the apps’ pricing structures. Some kind of visibility for how much cost sandboxes cause in the developer console would be neat.

However, some of our apps also use external APIs which causes us additional cost. This is then usage-based, so as long as the sandboxes are actually used for what they are supposed to be used, this is not an issue.

But I would appreciate it if Atlassian could monitor sandboxes for abuse (i.e. usage as anything else than a sandbox) since I am unaware of how apps can distinguish sandboxes from real sites.

Cheers,
Tobi

[david.toussaint]

Thanks for sharing, It is good that Atlassian will finally allow monetization of Sandboxed apps above a certain threshold, we’ve asking for this for quite some time.

However I would like to better understand where the limit of “5” is coming from. Can you share any insights on what cohort of customers tend to go beyond the 5? The number (percentage) off apps being used in more than 5 sandboxes at a time by the same customer?

I generally do not have an issue with providing those sandbox instances free of charge until a certain limit - as long as that does not incur any additional cost on our end. Be it forge monetization, support, anything else.

A different approach (one I would have liked to see instead) is mirroring the behavior of the Atlassian products wrt sandboxes. This would make life (and billing…) much easier for customers and also Solution Partners, working with our clients.

[NickWade]

Like others, we’ll need to understand implications on Forge billing (as an app vendor) for any free sandbox apps, could you please update the RFC to include this missing detail?

[markrekveld]

@AdithyaRamesh

I’ve been thinking a bit more on sandboxes, the customers that use them and our discussion earlier this week, and maybe I found a way that multiple sandboxes per instance can be supported without braking the bank.

Have you or the team though about these two options for partners:

• a per app opt-out, where a partner can state that free sandboxes are not supported for a given app.
• limit free sandboxes to specific plans, free, standard or advanced of an app.

As I understand it now, please correct me if I’m wrong, sandboxes are used by enterprise customers, typically the bigger once, to test, validate and migrate without impacting production much if at all.

While there are apps out there that could support multiple sandboxes, while having a limited impact on the profit margin of those apps, there are also apps that would see their profit margin decline to a point where the partner would have to increase the price for all customers to support a smaller number of enterprise customers needs for sandbox instances.

I don’t think that the wishes of the few should increase the price paid by the many customers out there.

Giving partners control of their profit margin when it comes to sandboxes, will I think, increase the broader support stands of partners to support our mutual customers.

[rachelminer]

Hey @AdithyaRamesh. I’ve collected some thoughts and questions on this RFC from around Appfire and I’ve organized them below. Some our questions mirror questions asked above but I think it’s worth calling them out again to emphasize their importance. I’ve also booked some time to chat about this further.

Financial

1. Who pays for the costs when apps are used in Sandboxes (ex. infrastructure costs, Forge included)? The customer, Atlassian, or vendor?

2. How do we monitor sandbox usage and billing?

Billing mechanics

1. Would there be different pricing prod vs sandbox? Can we set a lower price for additional sandbox licenses?

2. Assuming that pricing is different, how would this display on the marketplace?

3. How does this work with multi-instance licensing?

   1. If a customer buys MIL and has up to 150 “paid” instances of our app, can they get up to 5 sandbox instances for each of these MIL child licenses? Depending on the answers above, this may change our math on MIL pricing…

      • When MIL is live, will this also make use of the “FREE” value for “licenseType”? If so (internal question for Aida/team), are there any other fields we will need to distinguish between regular paid licenses, paid MIL parent licenses, “free” MIL child licenses, free sandbox licenses, and paid 6+ sandbox licenses?

4. Alignment with Atlassian’s editions = Misalignment with app licensing models — Free sandbox app licenses are only available to customers on Atlassian’s premium and enterprise editions, yet we can’t differentiate our app pricing based on the parent product edition. This will cause a misalignment where we’re charging the same price for our app to Atlassian Standard customers and to Atlassian Prem/Ent customers even though they aren’t getting the same value.

   • This may be part of an argument for why Atlassian or the customer should pay Forge costs for sandboxes, as we cannot differentiate our pricing to cover the unique costs of Atlassian’s higher edition customers.

Technical

1. How does data residency work? Is it entirely under customer control?

   1. What if there are sandboxes in multiple regions?

   2. Assumption: the customer controls the spec and we do whatever they say OR there is some well documented, standardized behavior that Atlassian defines

2. We would love to see how this is represented in the data. What does the data look like? How are multiple sandboxes linked to a prod instance?

   1. Reporting — app licenses used in sandboxes currently appear in the licenses table with a “FREE” value for “licenseType” and “Yes” value for “installedOnSandbox”. A good start…but we need more. I would check with Aida both to validate my suggestions and to see what else we want to ask for, but here’s what I would propose:

      1. We need to be able to tie to sandboxes licenses back to the paid licenses. A new field indicating the “parent” commecial app entitlement ID would be great. (I don’t think we can do this today…)

      2. Sandbox licenses appear to have a maintenance start date but no maintenance end date. MEDs should match the parent commercial license. Is this a bug? Need this reporting/licensing gap filled.

      3. If a customer pays for a 6th sandbox, what will it look like in the licenses table? Will it still show “Yes” for “installedOnSandbox”? Will it show “COMMERCIAL” since it’ll be paid?

      4. How are changes managed in the data? For example, last week a customer had 5 sandboxes and he takes a 6th, which is paying. This week he churns one of the free ones - does the 6th one become free sandbox?

      5. How do we we differentiate the different types of paid sandboxes?

         1. 1st type of paid sandboxes: Those that are paying because the customer does not pay for another non-sandbox instance they own (this case already exists today).

         2. 2nd type of paid sandboxes: the type suggested in this RFC

3. Will there be any control for the app vendor? For example, a limit on the number of sandboxes or usage associated with each sandbox?

4. How do you migrate data from different sandboxes? If the assumption is for customers to use the sandboxes as progressive staging environments, how do vendors migrate data between the sandboxes

5. Assumption: Sandboxes would use the same end points as Commercial Cloud. Is this true?

   1. If not, we’ll have more questions on how this would work

Rollout mechanics

1. When this is enabled what happens to 5+nth sandbox installs?

   1. Is app functionality disabled after the 5th sandbox install?

   2. How do they pick site if an existing customer has more than 5 sandboxes?

Misc

1. Why 5? How did Atlassian arrive at this number?

[AdithyaRamesh]

Hello Everyone!

Thank you for the feedback, perspective, and the detailed questions. I am working through some of the more complex questions & asks, and will get back to every question by next week. Apologies for the delay, and thank you for the patience!

[Alex_Zavorski]

@AdithyaRamesh I’m late to review and respond. Appreciate the RFC and understand the need for sandboxes. However, this RFC fails to address the economics for the marketplace. At a basic level, Atlassian is able to monetize Jira Cloud Standard, Premium and Enterprise editions, whereas Marketplace apps are anchored at the Cloud Standard edition. Yes we can have Advanced Editions and soon Multi-Instance, but we are unable to monetize for Jira Cloud Premium or Enterprise edition customers today. We carry the operational costs with no financial benefit. The costs are not just hosting, but also support and knowledge. Sandboxes increase the expectations and support required to support enterprise customers. Atlassian cannot expect that to be carried by Marketplace Partners for free. We need to be able to monetize the value.

[AaronMorris1]

Atlassian doesn’t absorb the cost of sandbox environments. Customers pay Atlassian extra for sandbox sites. Sandboxes are only available to customers willing to buy Premium or Enterprise licenses.

So, perhaps the fairest solution to everyone is to extend that structure to Marketplace apps. Meaning:

1. Either: Enterprise customers automatically pay Marketplace vendors more for apps, thus offsetting the added costs of support and hosting.
2. Or: Permitting sandbox installations can be made a toggle-capable feature that vendors can enable in higher app tiers. (Like Atlassian does.)
3. Or: Atlassian absorbs the hosting (Forge) costs of Marketplace apps in sandbox environments, thus reducing the cost to vendors.

Expecting vendors to absorb the cost of up to 5 sandbox sites without compensation seems unreasonable, especially considering 1) Atlassian itself is unwilling to absorb the cost of sandboxes, and 2) vendors pay Atlassian for hosting (Forge). This proposal creates the perception of hypocrisy. And combined with the current initiatives related to Forge, it even creates the perception of exploitation.

(To be clear, I’m not accusing Atlassian of exploiting vendors, and I don’t want this to be construed as disparagement. I’m simply warning about that perception.)

[AdithyaRamesh]

Hello Everyone!

Thank you for your engagement - we sincerely appreciate the thoughtful feedback. A common theme raised was the cost implications of supporting apps on Sandboxes. We hear your concerns, and I’m pleased to advise that for Runs on Atlassian apps, your Forge consumption bill will exclude any costs incurred by app usage on sandbox sites for Forge hosted apps. This change will come into effect at some point before April 1, when we will transition all customers from the Beta to GA . Any changes to this timeline will be communicated in advance.

Additionally, to address a few other points raised in this thread.

• Terms of Service : The app installation flow on sandboxes mimics the experience in the production environment, which includes agreeing to the vendor’s terms of service.

• Data Residency: Sandboxes, by default, are located in the same region as the production site but can be moved to a different region by the customer.

• Ability to uninstall apps immediately: Our Marketplace team is actively working on the capability to providing customers with the ability to uninstall immediately without having to go through the “unsubscribe” flow that exists today.

• Technical considerations for app purchases on sandbox (above the limit of 5): We are still working through the implementation details of the purchasing and will share an update in this area as we make further progress.

• Rationale on limit on number of app instances: Five instances of the same app on sandboxes tied to a site covered the 99% percentile of customer usage during the feature’s beta.

• Monitoring capabilities: The Marketplace Licenses API will have an installedOnSandbox field that you can query. Partners with apps on Forge remote can use this information to throttle app usage on sandboxes if they encounter high costs. Based on our observed usage during Beta, app usage on sandboxes account for less than 5% of total app usage. We recommend that you throttle sandbox app usage only if you observe sandbox costs to be more than 5% of the customer’s usage on production for a period of at least 3 months.

As part of our long-term strategy, we will continue to explore how app testing on sandboxes can unlock potential revenue opportunities for you, our partners, including, but not limited to, aligning future capabilities with app editions and considering consumption based pricing for sandbox app usage. We will share further updates through a separate RFC as we make progress.

[scott.dudley]

Hi AdithaRamesh,

Thanks for these updates. One clarification:

@AdithyaRamesh

for Runs on Atlassian apps, your Forge consumption bill will exclude any costs incurred by app usage on sandbox sites for Forge hosted apps

It is great news that Atlassian is not planning to charge vendors for some Forge app usage on sandboxes. Was it truly intentional to say that the “free sandbox usage” offer excludes Forge apps that are not RoA? If so, why are such apps excluded? Vendors with non-RoA apps have effectively all of the same concerns with the sandboxes as RoA vendors.

Monitoring capabilities: The Marketplace Licenses API will have an installedOnSandbox field that you can query.

Hitting the Marketplace Licenses API requires data egress, so not only is this solution impossible for RoA apps (meaning no solution between now and when the free grants are provided around April), but it is also mostly a business non-starter for existing non-RoA apps because it would require admins to approve an additional egress.

The “is a sandbox” information would ideally be provided natively in the context (functions) and FIT (remote), as well as being usable in display conditions.

Cheers,
Scott