Account info

Edit your account-level information by clicking the Settings button in the left navigation bar.

Edit general information about your workspace in the "Details" sub menu.

The Owner can change the name or avatar of the workspace.
Professional plan account holders can edit the domain name.

Workspace settings

Under Settings > General you can configure properties such as when stale environments are destroyed or recreated, and how public access to your ephemeral environments works.

Environment settings

Recreate Pull Request environments on push: If your environments are set to expire, you can recreate them when new changes are pushed to a branch. When this setting is on, Release will check for related expired environments for each change pushed. If it finds a match, it will recreate the environment with the latest code changes.
Create ephemeral environments for users who don't have Release accounts: If you have users who will open PRs to your GitHub repository but don't have Release accounts, turn this setting on so that Release can create an ephemeral environment for them.
Destroy ephemeral environments after no activity: If your team opens a high volume of pull requests and your cluster is filling up quickly, then it's a good idea to destroy your ephemeral environments as they become stale. Switch this feature on to specify how long your ephemeral environments will stay alive. If you have a low volume of pull requests, then you can leave this off and manually clean up environments as they are no longer needed. If you need an old ephemeral environment that has expired, you can easily re-create it by closing the stale pull request and re-opening it, or by turning on the Recreate feature described above.
Period to wait before marking an environment as inactive: Choose how long you want your environments to stay around for even if they are not being used. A longer time period is more convenient, while a shorter one saves on costs. The default of 7 days works for many people.
Enable unauthenticated environments page: In some cases, it is useful for non-technical staff to access preview environments. For example, your Product Managers, UI/UX designers, and other managerial staff may want to check out new changes and offer design feedback or approval. Turn this feature on to allow your ephemeral environments to be viewed publicly using a <magic_string> slug that only your team knows about. You can edit and save your team's slug.

Cluster settings

Use elevated permissions when creating clusters: This uses our elevated permissions role which might be required in some cases, such as running administrative services. Contact us to find out the details of what permissions are supplied in the elevated role permissions and how to access the ARN for assuming that role, but usually leave this setting off.

Miscellaneous

Enable GitOps: GitOps is a framework for using your git repository to manage your infrastructure and app configuration files. Read more about GitOps, but if you prefer configuring your environment settinsg through the web console then leave this setting off.

Source control settings

If you've integrated your Release account with source control, the Source Control settings page allows you to set how Release automatically posts information back to your source control provider.

PreviousAccount settings NextManaging users

Last updated 1 year ago

Was this helpful?

Workspace settings

Under Settings > General you can configure properties such as when stale environments are destroyed or recreated, and how public access to your ephemeral environments works.

Environment settings

Create Environments when Pull Requests are opened: If this setting is on, Release will create a new ephemeral environment for each new pull request made on your integrated GitHub repositories. We recommend leaving this on so your team can view preview environments for each proposed change to your code base. This can be at the app level as needed.

Recreate Pull Request environments on push: If your environments are set to expire, you can recreate them when new changes are pushed to a branch. When this setting is on, Release will check for related expired environments for each change pushed. If it finds a match, it will recreate the environment with the latest code changes.

Create ephemeral environments for users who don't have Release accounts: If you have users who will open PRs to your GitHub repository but don't have Release accounts, turn this setting on so that Release can create an ephemeral environment for them.

Destroy ephemeral environments after no activity: If your team opens a high volume of pull requests and your cluster is filling up quickly, then it's a good idea to destroy your ephemeral environments as they become stale. Switch this feature on to specify how long your ephemeral environments will stay alive. If you have a low volume of pull requests, then you can leave this off and manually clean up environments as they are no longer needed. If you need an old ephemeral environment that has expired, you can easily re-create it by closing the stale pull request and re-opening it, or by turning on the Recreate feature described above.

Period to wait before marking an environment as inactive: Choose how long you want your environments to stay around for even if they are not being used. A longer time period is more convenient, while a shorter one saves on costs. The default of 7 days works for many people.

Enable unauthenticated environments page: In some cases, it is useful for non-technical staff to access preview environments. For example, your Product Managers, UI/UX designers, and other managerial staff may want to check out new changes and offer design feedback or approval. Turn this feature on to allow your ephemeral environments to be viewed publicly using a <magic_string> slug that only your team knows about. You can edit and save your team's slug.

Cluster settings

Use elevated permissions when creating clusters: This uses our elevated permissions role which might be required in some cases, such as running administrative services. Contact us to find out the details of what permissions are supplied in the elevated role permissions and how to access the ARN for assuming that role, but usually leave this setting off.

Miscellaneous

Enable GitOps: GitOps is a framework for using your git repository to manage your infrastructure and app configuration files. Read more about GitOps, but if you prefer configuring your environment settinsg through the web console then leave this setting off.

Source control settings

If you've integrated your Release account with source control, the Source Control settings page allows you to set how Release automatically posts information back to your source control provider.

Pull request comments: Release will automatically comment on a pull request with a link to the running environment for that PR. More info .

Pull request status updates: This setting integrates with to push information about the PR status and any checks from Release to GitHub. More info .

Pull request deployment updates: This setting integrates with to push information from Release to GitHub. More info .

Create Environments when the following label is applied to a Pull Request: This setting integrates with so that you can create environments in Release by adding labels to PRs in GitHub. More info . These labels can be overridden by the .