Administration: General Settings

General settings control global behavior in Terraform Enterprise. To access general settings, visit the site admin area and click Settings in the left menu. To save the settings, click Save Settings at the bottom of the page.

Require Site Admins to Enable Two-factor Authentication

This setting can make the site more secure by requiring that admins enable two-factor authentication to access site admin functionality. You can use this setting in conjunction with SAML.

Admins that do not have two-factor authentication enabled may still log in, but will be unable to perform any admin-only functions until they enable and verify two-factor authentication.

You can use this setting in conjunction with SAML Single Sign On.

Contact Info

The support email address is used in system emails and other contact details. It defaults to support@hashicorp.com. If you'd like users of your instance to reach out to a specific person or team when they have issues, it can be changed to a local email address.

Organization Creation

Organization creation can be limited to site administrators or allowed for all users. Limiting organization creation to administrators means that the need for new organizations can be audited and their creation easily monitored.

When new user accounts are created, if they cannot create their own organizations, they will be unable to access any Terraform Cloud resources until they are added to a team.

API Rate Limiting

By default, requests to the Terraform Cloud API from a single user or IP address are limited to 30 requests per second to prevent abuse or hogging of resources. Since usage patterns may vary for a given instance, this can be updated to match local needs. A few endpoints have lower limits to prevent certain spam and abuse scenarios. If you receive a rate limited response, the limit will be reflected in the x-ratelimit-limit header once triggered.

Terraform Run Timeout Settings

The default time-out setting for Terraform runs are 2h for plans, and 24h for applies.

These are configurable on a global level:

or in the Admin settings at an organization level:

Commit Statuses for Untriggered Speculative Plans

This setting affects Terraform Enterprise's behavior with shared VCS repositories that contain multiple Terraform configurations.

Workspaces that use part of a shared repository typically don't run plans for changes that don't affect their files; this includes speculative plans on pull requests. Since "pending" status checks can block pull requests, a workspace will automatically send passing commit statuses for any PRs that don't affect its files.

However, if this results in sending too many status checks to your VCS provider due to a large number of workspaces sharing one VCS repository, you can disable this behavior and ignore the pending status checks for unaffected workspaces.

Remote State Sharing

The "Share state globally by default" admin setting determines the default value for the "Share state globally" setting on newly created workspaces.

• When true, a newly created workspace will allow all workspaces in its organization to read its state.
• When false, a newly created workspace will not allow any other workspaces to read its state.

In all cases, a workspace's state access settings can be changed after creation by workspace admins; this admin setting only affects the initial default value. Additionally, if the global-remote-state attribute is provided when creating a workspace via the API, the provided value will be used instead of using the default.

Refer to the following resources for more information:

• Terraform State in Terraform Cloud: Accessing State from Other Workspaces
• Workspace Settings: Remote State Sharing

Allow Speculative Plans on Pull Requests from Forks

This setting is supported for the following VCS providers: GitHub.com, GitHub.com (OAuth), GitHub Enterprise, Bitbucket Cloud, Azure DevOps Server, Azure DevOps Services.

By default, this setting is disabled because Terraform Enterprise assumes that forks of a trusted repository are not necessarily themselves trusted. Enabling this setting may allow Terraform Enterprise to execute malicious code or expose sensitive information through speculative plans on pull requests that originated from a repository fork.