Development v.s. production Atlassian Cloud add-on

Hello everyone. When I try to develop an Atlassian cloud add-on using ACE and Node.js on my local machine it works perfectly. The add-on is connected to the cloud instance and the output is as expected (the add-on works properly), but when I try to deploy the add-on (the same project) on a https server, and install the add-on, the output is different, and there is not rendering content at all. Can someone help me on this case?

Hi @Ivana1, when you run ACE locally, I imagine you have the credentials.json file present, which contains your instance name and API token. With that file present, ACE will invoke some magic (run ngrok tunnel, install app on your instance, etc.) When you run this app on a remote server:

  • remove that credentials.json file
  • update your config.json AND/OR descriptor (atlassian-connect.json) to make sure your descriptor’s baseUrl correctly reflects the hostname of where your http server is running.
  • your host needs to be behind https

If you’ve already covered the above, and are still having problems, please post any output (errors or logs). Please be sure not to include any sensitive information (i.e. access tokens, etc.)



Thank you @nmansilla for the response. Yes, I follow the steps, remove the credientials.json file, made the changes in the mentioned files, but since the add-on is dynamic I use authentication type “jwt”, and coming up with this type of error

Hi @Ivana1 ,

Have you tried viewing your app’s Connect descriptor in a browser to see how it renders? If that looks OK, you can then try sending a POST request to your app’s /installed endpoint with dummy data to see if it returns a 404. My guess is a configuration problem.



Hey there,

Check if your atlassian-connector.json “lifecycle” section has “installed” key value set. This is the endpoint where Atlassian will send POST request to confirm add-on install. E.g.

    "lifecycle": {
        "installed": "/installed"

This endpoint needs to respond with 204 or 201 HTTP code. If you’re using latest ACE version - this endpoint route is automatically set up when addon is being bootstrapped (as in you don’t need to write code for this route, unless you want to do something custom when request is sent).

Next try using some HTTP client (Postman, Boomerang, etc) to send POST to this endpoint to see what your server responds with. Use {{localBaseUrl}} value for host and /installed for path, e.g. if {{localBaseUrl}} is set to, then you should send POST to and review result. At the same time you could run Node.js server in DEBUG mode to see requests/responses to your server in real-time.

That’s the start. Once you’ve done above and didn’t find the issue - report back.

1 Like

Hi @ViliusZigmantas. I am having a similar issue with my install process. This reply of yours helped me to confirm that my /installed route is working. The reply I got is: “Installation verification error: 401 No baseUrl provided in registration info.”

I could use some help putting together the data for the POST /installed call from Postman to get closer to the source of my issue. I have not found any description of that call

If you or any other could have a look at it and reply to me in my thread: Cannot install ACE React app from Heroku

All help very much appreciated :slight_smile:


The /installed endpoint, and all the lifecycle events are documented with the Connect app descriptor. Specifically, you can find an example request payload.

That said, I would agree with @nmansilla about where the most common problems exist: in the baseUrl for the app, and in making sure the app is available on valid HTTPS. One thing that I do for debugging is to make sure to log lifecycle events and trap errors (example in Node.JS Express, not ACE. Some adjustments will be necessary).

1 Like

@ibuchanan thanks for pitching in and sharing the trap script (nice!)

@HallbjrnMagnsson during initial dev I have found Atlassian Connect Inspector tool useful. It creates atlassian-connect.json which will be valid for 3 days that you can install on your Jira instance and try out various lifecycle events in real-time and see all the payloads.

If you have proper dev env set up, you should be able to see all incoming requests and payloads through Ngrok’s web-app too.


Hi @ViliusZigmantas
I have developed an ACE cloud add-on with Node.js.
The add-on works properly on a local machine, with npm start and development as an environment. We put the same add-on on a Linux server, and try to start it from our own https server (without ngrok). The configuration is the same as the local machine.
Use case 1: We run the pm2 start npm – start command, the descriptor is served from the https url from the browser, and we successed to install it on the cloud instance (without errors on server), but the add-on is not working, thus is not rendering the content from the endpoints. This is the first use case where we use authentication type set as none.
Use case 2: When we use authentication type: “jwt” and with lifecycle “installed”., we came along with the error :

And in the Postman when we try yo send POST to this endpoint ("/installed"), the server response with 404 error.
Does someone has an idea why the addon doesn’t work properly from the server? Is it the wrong command for starting, problem with the authentication types, or maybe the configuration file. (just to note that we want to test the addon on the https server but in the development environment).
Thank you


HTTP 404 status in the error message indicates that your server doesn’t answer to your Jira Cloud instance when it tries to confirm installation by attempting to load https://<baseUrl>/installed

  • Navigate to your atlassian-connect.json URL and check what value is set for baseUrl
  • Confirm that your HTTPS certificates are valid and not expired
  • Check the web-server logs to confirm that there are attempts logged to access atlassian-connect.json and /installed (and check for any errors)

Additional things you could try:

  • check your app’s config.json and confirm if it has production section, then check the values set in localBaseUrl and port (this is the URL:PORT that your app is running on, where web-server would usually proxy requests to it)
  • as suggested earlier try to use some HTTP client to send POST to https://<baseUrl>/installed (see sample POST payload below)
  • /installed endpoint is expected to respond with 201 or 204 HTTP status, check if you have a custom route in your code for /installed endpoint (usually there is no need to define custom one, since ACE will define one during bootstrapping, I have found it better than my custom one)

Sample POST payload for /installed:

    "key": "<application-key-from-ace-descriptor>",
    "clientKey": "<unique-id-for-your-cloud-instance>",
    "publicKey": "<public-key-for-auth>",
    "sharedSecret": "<shared-secret-for-auth>",
    "serverVersion": "100166",
    "pluginsVersion": "1001.0.0-SNAPSHOT",
    "baseUrl": "<your-cloud-instance-url>",
    "productType": "<product-value-from-config-json-or-default>",
    "description": "Atlassian JIRA at <your-cloud-instance-url> ",
    "eventType": "installed"

Could you please provide more details on how you’re starting the application on the server?

  • Is it manually launching npm start or through systemd service or nodemon app.js or in some other way?
  • Can you confirm that NODE_ENV is actually set to production? You could set it explicitly with NODE_ENV=production node <main-script>.js
    • where <main-script>.js is your entry script which loads express.js, bootstraps ACE, defines routes and starts HTTP server to listen for connections
    • command expects node to be in your $PATH, if it is not then instead of node type in full path to the binary (e.g. NODE_ENV=production /usr/local/bin/node <main-script>.js
  • Can you start your app with DEBUG enabled and check if all endpoints are set up during launch (or catch any other errors)? Use DEBUG=express:* node <main-script>.js

Hope that something from above will help. Good luck and patience.


Thank you @ViliusZigmantas
Everything is done and it works now.

@Ivana1 any chance you could share which suggestion have worked for you to solve the issue?

1 Like

Yes of course.
Firstly I noticed that the nginx server configuration was not correct. The nginx was not serving the static files, just the descriptor, so I changed the location in the server block. Then I had a custom route in my code for ‘/installed’ endpoint, which I delete it afterwards, and this solved my HTTP 404 error. Also I added the localBaseUrl in the config.json file in the development environment to be my https server url . (just to note that the whole testing was in development environment).