> For the complete documentation index, see [llms.txt](https://docs.release.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.release.com/reference-documentation/account-settings/account-info.md). # 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 details Example](https://585411240-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M1neGLLQ0sDXeK6ooSo%2Fuploads%2Fgit-blob-874dfd1d0d97982a736051c7fea6ee7238fc7064%2Fworkspace-details.png?alt=media) ## 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. ![General settings](https://585411240-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M1neGLLQ0sDXeK6ooSo%2Fuploads%2Fgit-blob-ae5ea45e5482764a903ac07a0e9af27ae2a4152c%2Fworkspace-settings.png?alt=media) ### 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 [overridden](/reference-documentation/application-settings/github-1.md) 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 `` 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](/reference-documentation/gitops.md), 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. ![Account Settings Example](https://585411240-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M1neGLLQ0sDXeK6ooSo%2Fuploads%2Fgit-blob-a6f631d787d29a9e1f7cb5b73d1571b02b2c3117%2Faccount-settings-source-control.png?alt=media) * **Pull request comments:** Release will automatically comment on a pull request with a link to the running environment for that PR. More info [here](/integrations/source-control-integrations/github/pull-request-comments.md). * **Pull request status updates:** This setting integrates with [GitHub's status check features](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/about-status-checks) to push information about the PR status and any checks from Release to GitHub. More info [here](/integrations/source-control-integrations/github/github-statuses.md). * **Pull request deployment updates:** This setting integrates with [GitHub's deployment features](https://docs.github.com/en/rest/deployments) to push information from Release to GitHub. More info [here](/integrations/source-control-integrations/github/github-deployments.md). * **Create Environments when the following label is applied to a Pull Request:** This setting integrates with [GitHub's labeling features](https://docs.github.com/en/issues/using-labels-and-milestones-to-track-work/managing-labels) so that you can create environments in Release by adding labels to PRs in GitHub. More info [here](/integrations/source-control-integrations/github/pull-request-labels.md). These labels can be overridden by the [application settings](/reference-documentation/application-settings/github.md). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.release.com/reference-documentation/account-settings/account-info.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.