»Provisioning No-Code Infrastructure

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.

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.

Permissions

To use no-code provisioning, you must be a member of a team with manage all projects & workspaces permissions, manage workspaces only permissions, or admin permissions for a project.

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, 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.

2. 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.

3. 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.

4. (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.

5. Cick Next: Workspace settings.

6. 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 for more guidance.

7. Choose a Project for the workspace. Teams with access to the specified project will automatically be able to view the workspace. Refer to Organizing Workspaces with Projects for more details.

8. Add an optional Description for the workspace.

9. 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.

10. 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.