Unable to get a new developer cloud instance

When I try to get a new developer cloud instance, I get the following message:

Well, this is embarrassing. Our ordering system is currently unavailable.

I’m using this URL: https://www.atlassian.com/ondemand/signup/form?product=confluence.ondemand,jira-software.ondemand,jira-servicedesk.ondemand,jira-core.ondemand&developer=true

Am I still using the correct url? I’ve seen this message on multiple occasions in the past weeks.

1 Like

Hey @Maarten,

I just tried using this url: http://go.atlassian.com/cloud-dev (from the getting started guide)
And I was able to successfully register for a test instance.

Thanks for the URL Peter. Unfortunately I’m getting the same error there.

What browser are you using to get a developer instance?

I just tried a different Atlassian account and now it worked. Could it be that I hit some sort of max?

@rmassaioli: is there a max number of dev instances you can get using an Atlassian Account?

I’m curious why you’re spinning up many dev instances? Are you hitting the Free Trial limit? (btw: this is a known issue and something I’m trying to track down internally) or something else?

I currently have 3 instances:

  1. Developer instance running test
  2. Developer instance for demoing purposes
  3. Trial instance (expiring) to check out new functionality in Jira (issue experience)

Could it be that the expiring instance is blocking me from starting a new dev instance?

In the ideal situation I’d have these developer instances:

  1. Running the production version of our app
  2. Running the test version of our app
  3. Demo account for customer support

And when Atlassian is previewing new functionality under a feature flag, I’d like to preview this in another dev instance so that it doesn’t interfere with my day to day work. (issue experience for example)

1 Like

@rwhitbeck everyone in our team has (or should have) access to the 3/4 instances I described. But since we cannot share them, we all have our own set of instances.

I understand why dev instances are limited to only one user, but it seems like a waste of resources for everyone to have their own set of instances. And it makes testing with multiple users / roles kind of difficult.

Wouldn’t it be better for both Atlassian and app vendors if we could share certain dev instances?

  • Our demo instances is used to demo our product to new users (either at events or webcasts). It takes a while to set everything up.
  • Our production instance is mostly used for support. This is where we test bug reports, for example.
  • Our dev instance is used for developing new features. And non-devs use it to review and test functionality.
  • Early access instances are used to review, test and develop for new functionality that’s behind a feature flag. (Issue experience, for example)

I wouldn’t mind going through some sort of verification system to set up instances that we can share in the team. It would be very useful for the demo and production instances. And for non-developers it would work to share a test instance. (Our devs actually need separate instances so they don’t interfere with each other.)

5 Likes

Thanks, @Maarten for explaining how you’re using the developer instances. I do want to remind everyone that developer instances should only be used for development and testing. Things like demoing and support should not be handled under a developer instance.

Take a look at our Marketplace getting started page for another option for support and demoing. We can provide you with:

This support tools instance package includes Atlassian Cloud licenses for:

  • Jira Service Desk: 10 agents
    This is required in order to receive any of the below.

  • Jira Software: 100 users

  • Confluence: 100 users

  • Status Page: Business Tier

Requirements are that you have one paid app in the marketplace and that you apply for access. This seems like it would be a better option for your team.

Now that my Atlassian duties have been fulfilled let’s talk about the issues I see with the developer instances, as I have started to see some pain points with them. Disclaimer that what I am about to say is my personal opinion and what I’d personally like to see us get to, it does NOT indicate a roadmap or where we will go.

Let’s step back and look at how we got here. A few Super Moons :full_moon: ago the Atlassian SDK stopped supporting the cloud version of our products and thus we needed a way to support cloud devs in developing apps. We came up with the free very light user instance of Jira/Confluence that you see today, created a short link, updated documentation, and had a party :tada:, was epic! (One of those things is not true ⊭, the party was not epic :frowning:)

Developer instances are meant for one developer with limited test data to develop and test that what they’re building works as expected. We weren’t thinking about integrated testing when we set these up. We didn’t think about how to roll out new features or deployments to the cloud so that we can have the vendors test their apps before they went live. Turning on feature flags can be done but is all manual at this point. You have to request access.

So those are the things that I am aware of and trying to affect the change needed within Atlassian to make that better.

The way I see it developers should only need 1 or 2 instances. One that is a snapshot of how the current live instances are today. One that allows you to request dark feature flags to be turned on so you can test your apps (i.e. new issue view or the new Atlassian Design Guidelines rollout).

Hopefully, in the future, there will be the need for a third developer instance and that is instances that have requested “nightly” deploys to be able to test before we roll out to everyone else. Again, this is what I’d like to see.

Like I said these are the things I’m working on. I’m not very far with it yet. I was last working on getting a fix for new developer instances that get spun up expiring within a month because they were actually just free trials. I think the fix is rolling out soon.

Let me know what you think. Personally, as a developer, I don’t want to share my instance with @pvandevoorde when I’m developing an app. I want to be self-contained in my own sandbox. That was what I think we had in mind.

Replied with :heart:

1 Like

Thanks for the very elaborate reply, @rwhitbeck! Sorry to hear about the party, we’ll have to make up for it at AtlasCamp🍻.

I wasn’t aware that developer instances should not be used for demoing and support. We do use the support tools provided by Atlassian and use this instance to provide our users with support.

But since we are building a CRM, we cannot use this instance for demoing and testing out things during a support request. Here’s why:

Demo
We’re building a CRM app. Our support instance is filled with customer information. If we would demo the app on this instance we would reveal customer information, which would be very unprofessional.

We create a lot of dummy information during demos. If we would demo on our support instance, we would end up with a lot of clutter.

Support
We do use this instance for support. Jira Service Desk and Confluence are great tools to provide our users with the help they need.

But when a users asks questions about a specific situation, we use developer instances to test the situation without ruining our support instance.

  • Last year, for example, we got numerous reports that users weren’t able to install our app. We tested the installation flow on our developer instances and found there was a bug in the marketplace.
  • Another example: Users that have exotic permission schemes or settings and then report an issue. We don’t want to mess up our support instance, so we use developer instances to test these cases.

During the rollout of ADG3, we had to support users on the old and on the new experience. It was possible to move back-and-forth, so we didn’t need multiple instances. But there have been previews of new situations that you couldn’t move back-and-forth from. The new issue experience will be one of them, for example.


The way I see it developers should only need 1 or 2 instances. One that is a snapshot of how the current live instances are today. One that allows you to request dark feature flags to be turned on so you can test your apps (i.e. new issue view or the new Atlassian Design Guidelines rollout).

This could work for small apps. But we’re building a bigger app and have several environments of our own. Production, test, staging, nightly. We also have private betas, which sometimes are too big for a simple feature flag.

I agree that 2 instances could be enough for development. But it’s not enough when you take into account non-development processes. And our developers agree that they don’t want to share their sandbox development environment with each other. (Apparently that was a very dumb question, good thing I’m not a developer :upside_down_face:).


I do really wonder if we’re the only vendor that handles things this way. Did we create a messed-up situation for ourselves?

2 Likes

We have 1 or 2 Jira instances per developer (where we install the addon via some ngrok URL) and a dozen or so instances for automated testing and support (some with the staging version of our addon installed, some with the production version of our addon installed).

When there are alpha/beta releases by Atlassian then all our dev instances need to request that feature be enabled.

We use a combination of our development/support instances and our “company” Jira Cloud instance for debugging customer problems. We have some feature flags and use Launch Darkly in at least one of our apps.