Manage Semaphore configuration as code

The provider manages supported Semaphore resources through the Semaphore API, such as projects, repositories, templates, and other documented resource families. It configures the platform itself. That differs from using Semaphore to execute Terraform code that manages your cloud infrastructure. Check the resource and argument documentation for the provider version you pin, because a setting available in the web UI is not automatically evidence that the provider supports it.

No. The provider can run wherever you run Terraform, provided that environment can reach the Semaphore API and authenticate with the required access. You can use a workstation or your existing configuration pipeline. Keep the provider's execution environment, API credentials, and state backend explicit. If you later run it through Semaphore itself, evaluate that dependency carefully so platform configuration and the ability to execute it remain recoverable.

The provider uses the Terraform provider protocol, and a local test pinned semaphoreui/semaphore 0.3.9 in OpenTofu against an isolated Semaphore 2.19.12 instance. That test read an existing project, created a disposable project, and found no drift on a subsequent plan. It did not test the Terraform CLI or every provider resource. Pin your own versions and verify the resources and lifecycle operations your team needs before adoption.

Check import support and the required identifier for each resource in the documentation of your pinned provider version. Do not assume every resource has the same import behaviour. Decide how existing configuration will be represented and which system will own subsequent changes before applying a plan. Start with a non-production resource, inspect the resulting state and proposed changes, and avoid accidentally replacing a working shared configuration.

Yes. Keep the Terraform configuration for supported Semaphore resources in a version-controlled repository and review changes through your normal pull request process. The provider applies that configuration through the Semaphore API. Store API credentials separately from the code, and use a state backend appropriate for the configuration your team manages.

Task Templates are among the provider’s documented resource families. Use the registry reference for the exact arguments supported by your pinned provider version. A template change can affect subsequent automation runs, so review the plan and confirm the resulting configuration in Semaphore before letting the team use the updated job.

They serve different purposes. The provider manages Semaphore configuration through its API. A Terraform Task Template runs your infrastructure configuration from Semaphore. You can use either independently: configure the automation platform from your existing Terraform environment, then use its templates to run the infrastructure jobs your team already maintains.

Supply the API token through the supported provider configuration without committing it to Git. Choose a Terraform state backend with access and backup controls appropriate for your team. The environment running the provider needs network access to Semaphore and an identity allowed to manage the resources declared in the configuration.