The Terraform Provider for Qrator allows you to manage Qrator resources through Terraform configurations instead of manually configuring them in the interface. The provider is published in the Terraform Registry as QratorLabs/qrator, supports Terraform 1.0+, and works with domains, services, CDN configurations, and client certificates.

Prepare the Terraform configurationPrepare the Terraform configuration

Add the provider to the required_providers block:

terraform {
  required_providers {
    qrator = {
      source = "qratorlabs/qrator"
        version = "~> 0.2"
    }
  }
}

Configure authenticationConfigure authentication

The provider requires an API key to access the Qrator API. Authentication can be set either in the provider block or via environment variables. The README provides both options: api_key and endpoint in the configuration, or QRATOR_API_KEY and QRATOR_ENDPOINT in the environment.

Example using a provider block:

provider "qrator" {
  api_key = var.api_key
  endpoint = "https://api.qrator.net"
}

Example using environment variables:

• export QRATOR_API_KEY="your-api-key"
• export QRATOR_ENDPOINT="https://api.qrator.net"

Initialize TerraformInitialize Terraform

After adding the provider, perform standard initialization: terraform init.

Then, the provider follows the usual Terraform cycle: plan to check for changes and apply to apply the configuration.

What can be managed through the providerWhat can be managed through the provider

The provider supports the following resource groups:

DomainsDomains

• qrator_domain
• qrator_domain_services
• qrator_domain_sni
• qrator_domain_whitelist
• qrator_domain_blacklist

ServicesServices

• qrator_service
• qrator_service_services
• qrator_service_sni
• qrator_service_whitelist
• qrator_service_blacklist

CDN and CertificatesCDN and Certificates

• qrator_cdn
• qrator_cdn_sni
• qrator_client_certificate

Operation ScenariosOperation Scenarios

Two main scenarios are supported.

Scenario 1: Create a new configurationScenario 1: Create a new configuration

If the domain, service, or CDN configuration has not yet been created, describe them in .tf files and run:

1. terraform plan
2. terraform apply

The process is described in detail in the documentation.

Scenario 2: Connecting existing resourcesScenario 2: Connecting existing resources

If resources already exist in Qrator, they can be managed by Terraform without recreating them.

The basic workflow is:

1. Describe the resource in .tf;
2. Run terraform import;
3. Verify the terraform plan;
4. Match the .tf configuration to the actual state;
5. Run terraform apply.

The process is described in detail in the documentation.

Recommended WorkflowRecommended Workflow

For practical use, the following workflow is recommended:

New resourceNew resource

1. terraform init
2. terraform plan
3. terraform apply

Existing resourceExisting resource

1. terraform init
2. terraform import
3. terraform plan
4. terraform apply

This workflow is required to first synchronize the Terraform state with the current state in Qrator and then transfer the resource to a managed configuration.

Important considerations during operationImportant considerations during operation

• The provider operates through the Qrator API, so a valid API key is required for connection.
• For local provider development, you can use dev_overrides in ~/.terraformrc.
• The repository contains an examples/ directory with ready-made configuration examples,
• which can be used as a starting point.

Useful linksUseful links

Official provider repository: README, requirements, authentication, resource list.