Environments and versions

When you call forge create, we automatically create three environments for you:

• development
• staging
• production

Environments are where you deploy your app. Once an app is running in an environment, you can install it from that environment on to an Atlassian site with forge install. This process is documented in our app tutorials.

We recommend using the development environment for testing your changes, staging for a stable version of your app, and production as the version of your app that’s ready for use.

By default, the CLI will run commands for the development environment unless you specify another with the --environment flag.

While your app is deployed to development, your app title will have the suffix (DEVELOPMENT). Similarly, while your app is deployed to staging, it will have the suffix (STAGING). Once you deploy your app to production, your app title will no longer have any suffix.

Environment restrictions

When using the staging environment, you can't use the forge tunnel command. You'll need to redeploy your app using forge deploy each time you make a code change.

When using the staging and development environments, you won't be able to view the scopes defined for the APIs included in your Forge app. You'll need to deploy your app to the production environment for scopes to display. See View Forge app permissions for more details.

When using the production environment, you can't use the forge tunnel or forge logs commands. To debug issues, you’ll need to redeploy your affected code to the staging or development environments where you have access to debugging tools. For apps installed on sites you don’t have access to, you’ll need to ask the app user to download the logs for your app and send them to you.

Environment variables

Environment variables are key-value pairs you can manage via the Forge CLI variables commands. Each of your variables has separate values corresponding to the different environments your app is deployed to (development, staging, production). As with other Forge CLI commands, the Forge CLI variables commands act on the development environment unless another environment is specified explicitly.

• List your environment variables by running:

  1
  2
  forge variables list
  

• Set a variable with key MY_KEY and value my-value by running:

  1
  2
  forge variables set MY_KEY my-value
  

• Set an encrypted variable by providing the --encrypt option by running:

  1
  2
  forge variables set --encrypt MY_KEY my-value
  

  Encrypted values are protected from forge variables list output. However, they are passed to your app's environment as clear text.

• Unset a variable with key MY_KEY by running:

  1
  2
  forge variables unset MY_KEY
  

• Read a variable with key MY_KEY in your code as below:

  1
  2
  process.env.MY_KEY
  

• The same variable can be set in the production environment through the --environment option.

  1
  2
  forge variables set --environment production --encrypt MY_KEY my-value
  

Forge tunnel

When you're using the forge tunnel command, you must prefix environment variables with FORGE_USER_VAR_.

Set the value of MY_KEY by prefixing FORGE_USER_VAR_ to the variable name, then running the following command in your terminal:

1
2
export FORGE_USER_VAR_MY_KEY=test

You do not need to change variable assignment when using environment variables with forge tunnel, the variable is still accessed with MY_KEY.

1
2
const myVar = process.env.MY_KEY // MY_KEY will be "test"

Versions

When you deploy a Forge app, a new version is created in the Forge environment you specified, or by default; the development environment. As you iterate on the app and deploy changes, you'll create more versions.

Forge app version numbers are handled automatically by the platform and cannot be specified in the manifest.yml file. The Forge CLI does not show explicit version numbers, instead it shows latest or out-of-date when viewing app installations. Site administrators have access to the Forge version number when managing app installations in an Atlassian product.

After deploying a new version of your app, you'll see one of two different behaviors based on whether your changes are considered “minor” or “major”. There are various factors that we use to determine this, outlined below.

Major upgrades

Major version upgrades are not applied to an app installation immediately. This is because major versions involve significant changes that may require users and admins to re-consent or review the changes before continuing.

The following changes are considered major version upgrades, and are all applied to the manifest.yml file:

• Modifying scope permissions. This includes:
  • Adding a scope.
  • Swapping a scope for one not already listed.
  • Removing a scope.
• Modifying content permissions CSP options. This includes:
  • Adding a CSP option.
  • Swapping a CSP option for one not already listed.
• Modifying external permissions CSP options and URLs. This includes:
  • Adding a CSP option or URL.
  • Swapping a CSP option or URL for one not already listed.
• Adding or removing a providers.
• Changing a provider client ID.
• Changing the base URL of a remote.

You can use the Forge CLI to complete a major upgrade with forge install --upgrade. Site admins can select upgrade from the manage apps screen to complete the app upgrade.

Minor upgrades

Minor upgrades are not versioned. Instead, your app code is replaced with a new latest version. The Forge CLI shows latest as the changes are applied as part of the forge deploy process.

Minor upgrades are automatic and don't require any action by users or site admins.