No-code provisioning

No-code provisioning is a simplified option allowing non-practitioners to provision and manage infrastructure leveraging your existing Terraform codebase. Developers can now deploy infrastructure using Terraform without having to learn the language, in a self-service fashion. We recommend that No-Code modules are made available for common patterns/Use Cases (e.g RDS database, Java Web Application that can be used by end users to deploy infrastructure rapidly without having to write terraform code.

No-code provisioning allows you to take the infrastructure patterns you’ve developed and codified as Terraform modules and easily repackage them so that a wider population of users in your organization can benefit from those building blocks.

Updates to the pattern can easily be published and applied to existing no-code workspaces as HCP Terraform will notify every workspace that uses the module that a newer version is available. The user can then view the update change request, and apply the changes to the deployed infrastructure.

Please review the official documentation for more details on this capability.

Implementation guidance

The no-code module feature relies on the private module registry. You must have adopted it in your workflow and have established practices in place to test and release modules in the private registry.

When publishing a no-code module to the private registry or convert an existing private module as no-code, you must explicitly add the it to the no-code provision allow-list. This can be done using the WebUI, the API, the TFE provider (tfe_no_code_module).

Roles and responsibilities

The platform team’s responsibilities are to:

• Create and maintain no-code modules (including publishing module version updates as necessary).
• Update the HCP Terraform configuration to allow users to use no-code modules to deploy infrastructure in a self-service manner.

The no-code consumers' responsibilities are to:

• Create infrastructure in a self-service model with no-code modules
• Review the update request when notified that a no-code workspace they created uses a module that was updated.

Permissions requirements

Consumers of no-code modules must have the Maintain permission set on the project(s) where the no-code modules are deployed.

Credentials for provisioning

Because no-code modules are used to provision infrastructure, you will need credentials with an appropriately scoped role (and permissions).

Configuring at scale

Project

The no-code feature depends on a properly configured project where the user can create no-code workspaces. The platform team must set up this project with the appropriate permissions for the users (Maintain permission set).

Project-scoped variable sets

The project must be assigned a variable set with the properly scoped credentials necessary to configure the infrastructure.

Workspace Settings

When used, no-code modules will result in a workspace which will inherit settings that are established for the org/project including execution mode, default policies and run-tasks. These can be updated after the workspace is created by the admin (platform or project admin) team.

Day 2 operations

Managing and upgrading no-code provisioned infrastructure involves several key processes to ensure smooth operations and minimal disruption. When a new module version becomes available, admins and module publishers must change the designated no-code version for the module in its no-code configuration settings. When a new version is available, no-code users will receive an upgrade notification in their workspace. We recommend that no-code module users upgrade to the latest version of the module as soon as it is feasible after thorough testing in their lower environments.

During the upgrade process, users may encounter new variables that require inputs or current variables that require different inputs. They will be guided through a provisional plan, and if the plan doesn’t have an error it will auto-apply, which updates the module version used in the workspace. Currently, Terraform does not support rolling back to a previous module version if an upgrade does not go as planned.