Sending dynamic values to manifest.yml file during runtime in forge jira app

Hello Community,

I’m currently developing an Atlassian Forge app and I have a requirement to dynamically send URL to manifest.yml file. I understand that the manifest.yml file is static and cannot be modified at runtime.

Here’s a snippet of my manifest.yml file:

modules:
  jira:issuePanel:
    - key: ....
      resource: ...
      resolver:
        function: resolver
      viewportSize: small
      title: ABCD
      icon: https://developer.atlassian.com/platform/forge/images/issue-panel-icon.svg
      displayConditions:
        issueType: Story
  function:
    - key: resolver
      handler: index.handler
      providers:
        auth:
          - microsoft
providers:
  auth:
    - key: microsoft
      name: microsoft
      scopes:
        - User.Read
        - offline_access
      type: oauth2
      clientId: CLIENT_ID
      remotes:
        - microsoft-graph
        - custom-backend
      bearerMethod: authorization-header
      actions:
        authorization:
          remote: microsoft-login
          path: /TENENT_ID/oauth2/v2.0/authorize
        exchange:
          remote: microsoft-login
          path: /TENENT_ID/oauth2/v2.0/token
        retrieveProfile:
          remote: microsoft-graph
          path: /v1.0/me
          resolvers:
            id: id
            displayName: displayName
remotes:
  - key: microsoft-login
    baseUrl: https://login.microsoftonline.com
  - key: microsoft-graph
    baseUrl: https://graph.microsoft.com
  - key: custom-backend
    baseUrl: CUSTOM_BACKEND_BASE_URL
    operations:
      - fetch
resources:
  - key: .....
    path: .....
app:
  id: ari:cloud:ecosystem::app/APP_ID
  runtime:
    name: nodejs20.x
permissions:
  scopes:
    - read:jira-work
    - .....
  content:
    styles:
      - "unsafe-inline"
    scripts:
      - "unsafe-inline"
      - "unsafe-hashes"
  external:
    images:
      - "*"
    fetch:
      client:
        - "*"
      backend:
        - remote: custom-backend
        - "*"
        - "https://graph.microsoft.com"
        - "https://login.microsoftonline.com"
 

I’ve built an input form that accepts baseURL (CUSTOM_BACKEND_BASE_URL) . However, I’m looking for a way to send this baseURL dynamically and automatically when they are added from the input form.

I’m considering storing the dynamic data (i.e., new baseURL) in an Atlassian’s product storage, and then fetching this data at runtime to determine which baseURL to be utilised.

Has anyone implemented something similar or could provide some guidance on how to achieve this? Any help would be greatly appreciated!

Thank you!

Hey @PatilShashidhar,

Today remotes can only be defined statically at deployment time for Forge apps, however you can modify it on each deployment through the utilisation of environment variables.

We recently published RFC-94: Configurable Egress and Remotes, which may be similar to the use case you’ve mentioned here. It would support the ability to define / modify the remote at runtime.

Hi @SeanBourke. We’re exited and awaiting for the RFC-94 to be released, thanks for working on that. We have a question tho. Will there a way to have a manifest endpoint using a custom path segment per customer? Let me elaborate if you don’t mind. Let say I have the following trigger calling an endpoint in my manifest:

  trigger:
    - key: my-trigger
      endpoint: my-endpoint
      events:
        - avi:forge:installed:app
  endpoint:
    - key: my-endpoint
      remote: dynamic-customer-remote
      route:
        path: /remote_app/fix_path/fix_endpoint

We know remotes allow URI’s only up to the hostname e.g. https://example.com. So my endpoint route path must start from there to have the following complete URI at runtime: https://example.com/remote_app/fix_path/fix_endpoint. The thing is our customers have means to change the first path segment, e.g. /remote_app_customer1/fix_path/fix_endpoint whereas other customer may have /remote_app_customer2/fix_path/fix_endpoint. Do you know if configurable remotes will have a mean to support this or could you think other ways we can support this path customization to avoid forcing all customers to use the same first path segment always?

Howdy @RicardoHerrera

The general topic of making the manifest file dynamic and to use dynamic variables etc is covered in the RFC-95 and RFC-98 threads.

Thanks for responding, @anon96974232! I see that, as for Nov 2025, the only dynamic module available is “trigger”. This is nice because it is actually the module I need to use somehow dynamically, however, the part that needs to change, in my case, is one part of the “endpoint” path used by the trigger. One may say, I only need to dynamically declare my trigger to point to the right endpoint, right? but that does not work for me, because I don’t know what is endpoint for each customer, so I cannot put that in advance on my manifest, what I need to be dynamic is the endpoint module itself. Do you know if there’s an estimate/roadmap for that?

Thanks again!