diff --git a/website/data/cloud-docs-nav-data.json b/website/data/cloud-docs-nav-data.json index 32d4f9f0e..4253ba622 100644 --- a/website/data/cloud-docs-nav-data.json +++ b/website/data/cloud-docs-nav-data.json @@ -315,6 +315,19 @@ } ] }, + { + "title": "No-Code Provisioning", + "routes": [ + { + "title": "Designing No-Code Ready Modules", + "path": "no-code-provisioning/module-design" + }, + { + "title": "Provisioning No-Code Infrastructure", + "path": "no-code-provisioning/provisioning" + } + ] + }, { "title": "Migrating to Terraform Cloud", "path": "migrate" diff --git a/website/docs/cloud-docs/api-docs/private-registry/modules.mdx b/website/docs/cloud-docs/api-docs/private-registry/modules.mdx index 3ecb0ef1f..72497ac17 100644 --- a/website/docs/cloud-docs/api-docs/private-registry/modules.mdx +++ b/website/docs/cloud-docs/api-docs/private-registry/modules.mdx @@ -252,12 +252,13 @@ This POST endpoint requires a JSON object with the following properties as a req Properties without a default value are required. -| Key path | Type | Default | Description | -| --------------------------------------------- | ------ | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `data.type` | string | | Must be `"registry-modules"`. | -| `data.attributes.vcs-repo.identifier` | string | | The repository from which to ingress the configuration. | -| `data.attributes.vcs-repo.oauth-token-id` | string | | The VCS Connection (OAuth Connection + Token) to use as identified. This ID can be obtained from the [oauth-tokens](/cloud-docs/api-docs/oauth-tokens) endpoint. | -| `data.attributes.vcs-repo.display_identifier` | string | | The display identifier for the repository. For most VCS providers outside of BitBucket Cloud, this will match the `data.attributes.vcs-repo.identifier` string. | +| Key path | Type | Default | Description | +| --------------------------------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `data.type` | string | | Must be `"registry-modules"`. | +| `data.attributes.vcs-repo.identifier` | string | | The repository from which to ingress the configuration. | +| `data.attributes.vcs-repo.oauth-token-id` | string | | The VCS Connection (OAuth Connection + Token) to use as identified. You can obtain this ID from the [oauth-tokens](/cloud-docs/api-docs/oauth-tokens) endpoint. | +| `data.attributes.vcs-repo.display_identifier` | string | | The display identifier for the repository. For most VCS providers outside of BitBucket Cloud, this identifier matches the `data.attributes.vcs-repo.identifier` string. | +| `data.attributes.no-code` | boolean | | Allows you to enable or disable the no-code publishing workflow for a module. A VCS repository identifier is a reference to a VCS repository in the format `:org/:repo`, where `:org` and `:repo` refer to the organization (or project key, for Bitbucket Server) and repository in your VCS provider. The format for Azure DevOps is `:org/:project/_git/:repo`. @@ -274,6 +275,7 @@ The OAuth Token ID identifies the VCS connection, and therefore the organization "oauth-token-id":"ot-hmAyP66qk2AMVdbJ", "display_identifier":"lafentres/terraform-aws-my-module" } + "no-code": true }, "type":"registry-modules" } @@ -369,13 +371,14 @@ This POST endpoint requires a JSON object with the following properties as a req Properties without a default value are required. -| Key path | Type | Default | Description | -| ------------------------------- | ------ | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `data.type` | string | | Must be `"registry-modules"`. | -| `data.attributes.name` | string | | The name of this module. May contain alphanumeric characters, with dashes and underscores allowed in non-leading or trailing positions. Maximum length is 64 characters. | -| `data.attributes.provider` | string | | Specifies the Terraform provider that this module is used for. May contain lowercase alphanumeric characters. Maximum length is 64 characters. | -| `data.attributes.namespace` | string | | The namespace of this module. Cannot be set for private modules. May contain alphanumeric characters, with dashes and underscores allowed in non-leading or trailing positions. Maximum length is 64 characters. | -| `data.attributes.registry-name` | string | | Indicates whether this is a publicly maintained module or private. Must be either `public` or `private`. | +| Key path | Type | Default | Description | +| ------------------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `data.type` | string | | Must be `"registry-modules"`. | +| `data.attributes.name` | string | | The name of this module. May contain alphanumeric characters, with dashes and underscores allowed in non-leading or trailing positions. Maximum length is 64 characters. | +| `data.attributes.provider` | string | | Specifies the Terraform provider that this module is used for. May contain lowercase alphanumeric characters. Maximum length is 64 characters. | +| `data.attributes.namespace` | string | | The namespace of this module. Cannot be set for private modules. May contain alphanumeric characters, with dashes and underscores allowed in non-leading or trailing positions. Maximum length is 64 characters. | +| `data.attributes.registry-name` | string | | Indicates whether this is a publicly maintained module or private. Must be either `public` or `private`. | +| `data.attributes.no-code` | boolean | | Allows you to enable or disable the no-code publishing workflow for a module. ### Sample Payload (private module) @@ -387,6 +390,7 @@ Properties without a default value are required. "name": "my-module", "provider": "aws", "registry-name": "private" + "no-code": true } } } @@ -403,6 +407,7 @@ Properties without a default value are required. "namespace": "terraform-aws-modules", "provider": "aws", "registry-name": "public" + "no-code": true } } } diff --git a/website/docs/cloud-docs/no-code-provisioning/module-design.mdx b/website/docs/cloud-docs/no-code-provisioning/module-design.mdx new file mode 100644 index 000000000..09110ccb9 --- /dev/null +++ b/website/docs/cloud-docs/no-code-provisioning/module-design.mdx @@ -0,0 +1,50 @@ +--- +page_title: Designing No-Code Ready Modules - No-Code Provisioning - Terraform Cloud +description: No-code ready modules let users deploy a module's resources without writing configuration. Prepare modules for no-code ready provisioning. +--- + +# Designing No-Code Ready Modules + +-> **Note:** No-code provisioning is in beta and available in the [Terraform Cloud Business tier](https://www.hashicorp.com/products/terraform/pricing). + +Terraform [modules](/language/modules) let you define standardized collections of infrastructure resources that downstream users can more easily deploy. No-code ready modules build on these advantages by letting users deploy a module's resources without writing any Terraform configuration. This practice is called no-code provisioning. + +No-code provisioning enables a self-service workflow that lets users provision approved collections of resources without learning Terraform or infrastructure best practices. You can enable no-code provisioning for any public or private module in your [private registry](/cloud-docs/registry). Users can then [provision no-code infrastructure](/cloud-docs/no-code-provisioning/provisioning), set the module's input variables, and deploy its resources. + +> **Hands On:** Try the [Create and Use No-Code Ready Modules tutorial](https://learn.hashicorp.com/tutorials/terraform/no-code-provisioning). + +The same best practices apply to both standard and no-code ready module design. However, no-code modules have additional requirements and considerations. + +## Requirements + +A no-code ready module must meet the following requirements: +- **Root Module Structure:** The module must follow [standard module structure](/language/modules/develop/structure) and define its resources in the root directory of the repository. This structure allows the public and private registries to generate documentation, track resource usage, and parse submodules and examples. +- **Provider Configuration:** A no-code ready module must declare the required provider(s) directly in the module. This configuration differs from the recommendations for [modules used in written configuration](/language/modules/develop/providers#legacy-shared-modules-with-provider-configurations). + +### Provider credentials + +Organization administrators must determine how no-code workspaces access credentials for provider authentication and design modules accordingly. + +When module consumers follow the no-code workflow, Terraform Cloud automatically creates a new workspace for the resources and attempts to provision them. New workspaces must be able to access credentials for all providers defined within the module. + +You can grant new no-code workspace provider credentials using one of the following methods: + +- Create a [global variable set](/cloud-docs/workspaces/variables/managing-variables#variable-sets) that Terraform Cloud applies to all existing and future workspaces in the organization. This action automatically grants newly-created workspaces access to the required provider credentials. +- Expose provider credentials as sensitive outputs in another workspace. You must add additional configuration to the module to access these values through [remote state data sources](/language/state/remote-state-data) and then reference them in provider configuration. This approach provides more control over access to these credentials than placing them in a global variable set. +- Elect to let the first run in new no-code workspaces fail and have module users add credentials directly to the workspace after creation. This approach provides the most control over access to provider credentials, but requires manual intervention. Module users must manually start a new run to provision infrastructure after they configure the credentials. + +## Module Design Recommendations + +Similarly to a [standard module](/language/modules/develop#when-to-write-a-module), a well-designed no-code ready module composes resources so that they are easy for others to deploy. However, no-code module users are less familiar with Terraform, so we recommend the following best practices for no-code module design. + +### Build For a Specific Use Case + +No-code ready module users are typically less familiar with Terraform and infrastructure management. Reduce the amount of technical decision-making required to deploy the module by scoping it to a single, specific use case. This approach lets users focus on business concerns instead of infrastructure concerns. + +For example, you could build modules that satisfy the following well-scoped use cases: +- Deploying all resources needed for a three-tier web application +- Deploying a database with constraints on resource allocation and deployment region + +### Provide Variable Defaults When Possible + +The no-code provisioning workflow prompts users to set values for the module's input variables before creating the new workspace and deploying resources. We recommend setting reasonable defaults when possible to reduce the effort and expertise needed to deploy the module. Remember that the workspace can also access variable values set through global variable sets in your organization. diff --git a/website/docs/cloud-docs/no-code-provisioning/provisioning.mdx b/website/docs/cloud-docs/no-code-provisioning/provisioning.mdx new file mode 100644 index 000000000..7c4e3378e --- /dev/null +++ b/website/docs/cloud-docs/no-code-provisioning/provisioning.mdx @@ -0,0 +1,54 @@ +--- +page_title: No-Code Provisioning - Provisioning No-Code Infrastructure +description: How to provision infrastructure from a no-code ready module. +--- + +# Provisioning No-Code Infrastructure + +-> **Note:** No-code provisioning is in beta and available in the [Terraform Cloud Business tier](https://www.hashicorp.com/products/terraform/pricing). + +No-code provisioning lets you deploy infrastructure resources in a new Terraform Cloud workspace without writing any Terraform configuration. You can create a no-code workspace from any module labeled **No-code Ready** in your organization's [private registry](/cloud-docs/registry). + +The no-code provisioning workflow is best for quickly deploying relatively static infrastructure. Beyond changing variable values, you cannot apply configuration changes to existing no-code workspaces. If you need to deploy updates to the no-code ready module's configuration, you must create new no-code workspaces with new resources. We recommend standard modules for use cases that require dynamic configuration and development. + +> **Hands On:** Try the [Create and Use No-Code Ready Modules tutorial](https://learn.hashicorp.com/tutorials/terraform/no-code-provisioning). + +## Permissions + +To use no-code provisioning, you need permissions to [manage workspaces](/cloud-docs/users-teams-organizations/permissions#manage-workspaces). + +## Provider Credentials + +Terraform automatically starts a new run to provision no-code infrastructure upon workspace creation. No-code modules contain provider blocks in their configuration, but still require provider credentials for successful deployment. Organization administrators determine how new workspaces should [access provider credentials](/cloud-docs/no-code-provisioning/module-design#provider-credentials), which may require specific module design. + +## Creating a Workspace and Deploying Resources + +The no-code provisioning workflow creates a new Terraform Cloud workspace to deploy and manage the no-code ready module's resources. Terraform Cloud automatically starts a run to provision the module's resources in the new workspace. Depending on the workspace's settings, Terraform either automatically applies the plan or prompts you for approval to provision the infrastructure. + +To launch the no-code workflow: + +1. Click **Registry** in the main Terraform Cloud navigation to access your organization's private registry. + +1. Click **Modules** to view the list of available modules in the private registry. You can filter for no-code ready modules in your registry. No-code enabled modules have a **No-code Ready** badge next to their names. + +1. Select the no-code ready module to view its details, then click **Provision workspace**. The **Configure module inputs** page appears. + + Terraform Cloud scans the module configuration for input variables and prompts for values for any variables without defaults or undefined in an existing global variable set. Terraform requires values for these variables to successfully complete runs in the workspace. Terraform Cloud performs type validation for the variable values if the module configuration specifies a type. + +1. (Optional) Set values for the input variables. You can choose to skip this step and configure the variables later. However, Terraform Cloud does not prompt you for these values again and your Terraform runs may fail. + +1. Cick **Next: Workspace settings**. + +1. Enter a **Workspace Name**. The name must be unique within the organization and can include letters, numbers, dashes (-), and underscores (_). Refer to the [workspace naming recommendations](/cloud-docs/workspaces/naming) for more guidance. + +1. Add an optional **Description** for the workspace. + +1. Select an apply method for the workspace. **Auto apply** automatically applies any successful runs in the workspace, including the initial run on workspace creation. **Manual apply** prompts operators to review and confirm the changes in a run. **Auto apply** is the default option for a no-code workspace. + +1. Click **Create workspace**. Terraform Cloud creates a new workspace and starts a run. Depending on the apply method, it automatically applies your infrastructure or prompts you for approval to create the no-code module's resources. + +## Operations in No-Code Workspaces + +No-code workspaces have a limited feature set because you cannot access the resource configuration. However, you can edit workspace variables and settings, including notifications, permissions, and run triggers. You can use run triggers to connect the workspace to one or more source workspaces, start new runs when you change workspace variables, or queue destroy runs. + +If the module’s configuration changes, you must destroy the workspace and create a new one to provision resources with the updated configuration. diff --git a/website/docs/cloud-docs/registry/add.mdx b/website/docs/cloud-docs/registry/add.mdx index 6e57259c4..a271d232a 100644 --- a/website/docs/cloud-docs/registry/add.mdx +++ b/website/docs/cloud-docs/registry/add.mdx @@ -35,7 +35,7 @@ To add a public provider or module: ![Terraform Cloud screenshot: the Search Public Modules page](/img/docs/add-search-public-modules-providers.png) -1. Enter any combination of namespaces (e.g. hashicorp), and module or provider names into the search field. You can click **Providers** and **Modules** to toggle between lists of providers and modules that meet the search criteria. +1. Enter any combination of namespaces (such as hashicorp), and module or provider names into the search field. You can click **Providers** and **Modules** to toggle between lists of providers and modules that meet the search criteria. 1. Do one of the following to add a provider or module to your private registry: - Hover over the provider or module and click **+ Add**. @@ -45,9 +45,26 @@ To add a public provider or module: 1. Click **Add to organization** in the dialog box. Members of your organization can now begin using it from the private registry. +## Enabling and Disabling No-Code Provisioning + +-> **Note:** No-code provisioning is in beta and available in the [Terraform Cloud Business tier](https://www.hashicorp.com/products/terraform/pricing). + +You can enable no-code provisioning for public modules after adding them to your registry. + +To support the auto-apply workflow, ensure that downstream users can automatically load provider credentials into their new no-code workspaces. You can enable access by either creating a global variable set with the credentials for the module's provider, or by accessing outputs with credentials from other workspaces. Refer to [Provider Credentials](/cloud-docs/no-code-provisioning/module-design#provider-credentials) for more details. + +To enable no-code provisioning: +1. Verify that the module meets the [requirements for no-code provisioning](/cloud-docs/no-code-provisioning/module-design#requirements). +1. Click the module to view its details. +1. Select **Enable no-code provisioning** from the **Manage Module for Organization** dropdown. + +Your module’s details page now has a **No-Code Ready** badge to indicate that it supports no-code provisioning. + +To disable no-code provisioning, select **Disable no-code provisioning** from the **Manage Module for Organization** dropdown. Disabling also removes the **No-Code Ready** badge from the module’s details page. + ## Removing a Public Provider or Module -Removing a public provider or module from a private registry does not remove it from the public Terraform Registry. Users in the organization will still be able to use the removed provider or module without changing their configurations. +Removing a public provider or module from a private registry does not remove it from the public Terraform Registry. Users in the organization can still use the removed provider or module without changing their configurations. To remove a public provider or module from an organization's private registry: @@ -56,4 +73,4 @@ To remove a public provider or module from an organization's private registry: 1. Select the provider or module to view its details, open the **Manage for Organization** menu, and click **Remove from organization** (providers) or **Delete module** (modules). ![Terraform Cloud screenshot: the delete module button](/img/docs/add-delete-module-button.png) -1. Enter the provider or module name in the dialog box to confirm and then click **Remove** (providers) or **Delete** (modules). The provider or module is removed from the organization's private registry. +1. Enter the provider or module name in the dialog box to confirm and then click **Remove** (providers) or **Delete** (modules). The provider or module no longer appears in the organization's private registry. diff --git a/website/docs/cloud-docs/registry/publish-modules.mdx b/website/docs/cloud-docs/registry/publish-modules.mdx index 8ec45b308..59f299d26 100644 --- a/website/docs/cloud-docs/registry/publish-modules.mdx +++ b/website/docs/cloud-docs/registry/publish-modules.mdx @@ -11,7 +11,7 @@ description: >- > **Hands-on:** Try the [Share Modules in the Private Module Registry](https://learn.hashicorp.com/tutorials/terraform/module-private-registry-share) tutorial. -In addition to [adding modules from the Terraform Registry](/cloud-docs/registry/add), you can publish private modules to an organization's Terraform Cloud private registry. The registry handles downloads and controls access with Terraform Cloud API tokens, so consumers don't need access to the module's source repository, even when running Terraform from the command line. +In addition to [adding modules from the Terraform Registry](/cloud-docs/registry/add), you can publish private modules to an organization's Terraform Cloud private registry. The registry handles downloads and controls access with Terraform Cloud API tokens, so consumers do not need access to the module's source repository, even when running Terraform from the command line. The private registry uses your configured [Version Control System (VCS) integrations][vcs] and defers to your VCS provider for most management tasks. For example, your VCS provider handles new version releases. The only manual tasks are adding a new module and deleting module versions. @@ -19,7 +19,7 @@ The private registry uses your configured [Version Control System (VCS) integrat ## Permissions -Private modules are only available to members of the organization where you add them. In Terraform Enterprise, they are also available to organizations that are configured to [share modules](/enterprise/admin/application/module-sharing) with that organization. +Private modules are only available to members of the organization where you add them. In Terraform Enterprise, they are also available to organizations that you configure to [share modules](/enterprise/admin/application/module-sharing) with that organization. Members of the [owners team](/cloud-docs/users-teams-organizations/permissions#organization-owners) and teams with [Manage Private Registry permissions](/cloud-docs/users-teams-organizations/permissions#manage-private-registry) can publish and delete modules from the private registry. @@ -47,11 +47,11 @@ A module repository must meet all of the following requirements before you can a - **`x.y.z` tags for releases:** At least one release tag must be present for you to publish a module. The registry uses release tags to identify module versions. Release tag names must be a [semantic version](http://semver.org), - which can optionally be prefixed with a `v`. For example, `v1.0.4` and `0.9.2`. The registry ignores tags that do not look like version numbers. + which you can optionally prefix with a `v`. For example, `v1.0.4` and `0.9.2`. The registry ignores tags that do not look like version numbers. ## Publishing a New Module -You can publish modules through the UI as shown below or with the [Registry Modules API](/cloud-docs/api-docs/modules). The API also supports publishing modules without a VCS repo as the source, which is not possible via the UI. +You can publish modules through the UI as shown below or with the [Registry Modules API](/cloud-docs/api-docs/modules). The API also supports publishing modules without a VCS repo as the source, which is not possible in the UI. To publish a new module: @@ -69,6 +69,10 @@ To publish a new module: You can search the list by typing part or all of a repository name into the filter field. Remember that VCS providers use `/` strings to locate repositories. The namespace is an organization name for most providers, but Bitbucket Server (not Bitbucket Cloud) uses project keys, like `INFRA`. +1. (Optional) If this module is a [no-code ready module](/cloud-docs/no-code-provisioning/module-design), select the **Add Module to no-code provision allowlist** checkbox. + + -> **Note:** No-code provisioning is in beta and available in the [Terraform Cloud Business tier](https://www.hashicorp.com/products/terraform/pricing). + 1. Click **Publish module**. Terraform Cloud displays a loading page while it imports the module versions and then takes you to the new module's details page. On the details page, you can view available versions, read documentation, and copy a usage example. @@ -77,15 +81,15 @@ To publish a new module: ## Releasing New Versions of a Module -To release a new version of a module, push a new release tag to its VCS repository. The registry will automatically import the new version. +To release a new version of a module, push a new release tag to its VCS repository. The registry automatically imports the new version. Refer to [Preparing a Module Repository](#preparing-a-module-repository) for details about release tag requirements. ## Deleting Versions and Modules --> **Note:** Deleting a tag from your VCS repository will not automatically remove the version from the private registry. +-> **Note:** Deleting a tag from your VCS repository does not automatically remove the version from the private registry. -You can delete individual versions of a module or the entire module. If deleting a module version would leave a module with no versions, Terraform Cloud will remove the entire module. To delete a module or version: +You can delete individual versions of a module or the entire module. If deleting a module version would leave a module with no versions, Terraform Cloud removes the entire module. To delete a module or version: 1. Navigate to the module's details page. @@ -96,8 +100,8 @@ You can delete individual versions of a module or the entire module. If deleting 1. Select an action from the menu: - **Delete only this module version:** Deletes only the version of the module you were viewing when you clicked **Delete module**. - - **Delete all versions for this provider for this module:** Deletes the entire module for a single provider. This is important if you have modules with the same name but with different providers. For example, if you have module repos named `terraform-aws-appserver` and `terraform-azure-appserver`, the registry treats them as alternate providers of the same `appserver` module. - - **Delete all providers and versions for this module:** Deletes all modules with this name, even if they are from different providers. For example, both `terraform-aws-appserver` and `terraform-azure-appserver` would be deleted. + - **Delete all versions for this provider for this module:** Deletes the entire module for a single provider. This action is important if you have modules with the same name but with different providers. For example, if you have module repos named `terraform-aws-appserver` and `terraform-azure-appserver`, the registry treats them as alternate providers of the same `appserver` module. + - **Delete all providers and versions for this module:** Deletes all modules with this name, even if they are from different providers. For example, this action deletes both `terraform-aws-appserver` and `terraform-azure-appserver`. ![Terraform Cloud screenshot: the deletion dialog](/img/docs/publish-delete.png) @@ -112,8 +116,8 @@ Deletion is permanent, but there are ways to restore deleted modules and module ## Sharing Modules Across Organizations -Terraform Cloud does not typically allow one organization's workspaces to use private modules from a different organization. This is because Terraform Cloud gives Terraform temporary credentials to access modules that are only valid for that workspace's organization. Although it is possible to mix modules from multiple organizations when you run Terraform on the command line, we strongly recommend against it. +Terraform Cloud does not typically allow one organization's workspaces to use private modules from a different organization. This restriction is because Terraform Cloud gives Terraform temporary credentials to access modules that are only valid for that workspace's organization. Although it is possible to mix modules from multiple organizations when you run Terraform on the command line, we strongly recommend against it. -Instead, you can share modules across organizations by sharing the underlying VCS repository. Grant each organization access to the module's repository, and then add the module to each organization's registry. When you push tags to publish new module versions, both organizations will update accordingly. +Instead, you can share modules across organizations by sharing the underlying VCS repository. Grant each organization access to the module's repository, and then add the module to each organization's registry. When you push tags to publish new module versions, both organizations update accordingly. Terraform Enterprise administrators can configure [module sharing](/enterprise/admin/application/module-sharing) to allow organizations to use private modules from other organizations. diff --git a/website/docs/cloud-docs/registry/using.mdx b/website/docs/cloud-docs/registry/using.mdx index 3ba4c774b..9758b5c65 100644 --- a/website/docs/cloud-docs/registry/using.mdx +++ b/website/docs/cloud-docs/registry/using.mdx @@ -7,14 +7,16 @@ description: Find available providers and modules and include them in configurat All users in an organization can view the Terraform Cloud private registry and use the available providers and modules. A private registry has some key requirements and differences from the [public Terraform Registry](/registry): -- **Location:** You must use Terraform Cloud's web UI to search for providers, modules, and usage examples. +- **Location:** Search for providers, modules, and usage examples in the Terraform Cloud private registry UI. - **Provider and Module block `source` argument:** Private providers and modules use a [different format](/cloud-docs/registry/using#using-private-providers-and-modules-in-configurations). - **Terraform version:** Terraform Cloud workspaces using version 0.11 and higher can automatically access your private modules during Terraform runs, and workspaces using version 0.13 and higher can also automatically access private providers. - **Authentication:** If you run Terraform on the command line, you must [authenticate](/cloud-docs/registry/using#authentication) to Terraform Cloud or your instance to use providers and modules in your organization’s private registry. +Terraform Cloud supports using modules in written configuration or through the [no-code provisioning workflow](/cloud-docs/no-code-provisioning/provisioning). + ## Finding Providers and Modules -To find available providers and modules, click the **Registry** button in the main navigation bar. The **Registry** page appears. +To find available providers and modules, go to your organization, and click **Registry**. The **Registry** page appears. ![Terraform Cloud screenshot: a filtered list of available providers](/img/docs/registry-page-filtered.png) @@ -38,6 +40,10 @@ Use the **Submodules** menu to navigate to the detail pages for any nested modul ![Terraform Cloud screenshot: a module submodules button](/img/docs/using-submodules-dropdown.png) +## Provisioning Infrastructure from No-Code Ready Modules + +You can use modules marked **No-Code Ready** to create a new workspace and automatically provision the module's resources without writing any Terraform configuration. Refer to [Provisioning No-Code Infrastructure](/cloud-docs/no-code-provisioning/provisioning) for details. + ## Using Public Providers and Modules in Configurations > **Hands-on:** Try the [Use Modules from the Registry](https://learn.hashicorp.com/tutorials/terraform/module-use?in=terraform/modules) tutorial. diff --git a/website/docs/cloud-docs/workspaces/creating.mdx b/website/docs/cloud-docs/workspaces/creating.mdx index 7347a0d9f..2d7fcdee1 100644 --- a/website/docs/cloud-docs/workspaces/creating.mdx +++ b/website/docs/cloud-docs/workspaces/creating.mdx @@ -14,6 +14,7 @@ Workspaces organize infrastructure into meaningful groups. Create new workspaces - **Terraform Cloud UI:** [Create a Workspace](#create-a-workspace) - **Workspaces API:** [Create a Workspace endpoint](/cloud-docs/api-docs/workspaces#create-a-workspace) - **Terraform Enterprise Provider:** [`tfe_workspace` resource](https://registry.terraform.io/providers/hashicorp/tfe/latest/docs/resources/workspace) +- **No-Code Provisioning:** The no-code provisioning workflow creates a new workspace and deploys a [no-code ready module's](/cloud-docs/no-code-provisioning/provisioning) resources in it. ## Permissions