Terraform Provider

The official Bahriya Terraform provider lets you manage your entire Bahriya infrastructure as code — projects, containers, registries, secrets, Memcached, vault items (TLS bundles, X.509 certs, GPG and SSH keypairs, encryption keys), and config items (env files, YAML / JSON / plain text). It is published on the HashiCorp Terraform Registry.

Why Terraform

• Declarative — describe the desired state, Terraform figures out the changes.
• Version-controlled — commit your .tf files and review changes like any other code.
• Repeatable — spin up identical environments for staging and production from the same config.
• Composable — combine Bahriya resources with other providers (DNS, monitoring, CI/CD) in a single plan.

Installation and authentication

See the Installation guide for full details on installing Terraform, adding the provider, authenticating with a personal access token, version pinning, upgrading, and CI/CD usage.

Quick start:

terraform {
  required_providers {
    bahriya = {
      source  = "bahriya-cloud/bahriya"
      version = "~> 0.1"
    }
  }
}
 
provider "bahriya" {}

export BAHRIYA_TOKEN="pat_..."
export BAHRIYA_ORGANISATION_ID="your-org-uuid"
terraform init

Available resources

Each vault and config item can be attached to a project (bahriya_project_<type>_attachment) to make it available in the project's regions, then referenced from a bahriya_container to mount it inside the container (as a file, or as env vars for env files).

Data sources

Field naming

The Terraform provider uses the same flat field names as the Bahriya API. These are not snake_case — they are lowercase with no separators:

Quickstart

Deploy an HTTP container in under 30 lines:

terraform {
  required_providers {
    bahriya = { source = "bahriya-cloud/bahriya" }
  }
}
 
provider "bahriya" {}
 
resource "bahriya_project" "web" {
  handle  = "web-prod"
  name    = "Web Production"
  regions = ["falkenstein-1"]
}
 
resource "bahriya_container" "api" {
  handle          = "api"
  name            = "API Server"
  image           = "nginx:alpine"
  containerport   = "80"
  healthcheckpath = "/"
  mincpu          = "100"
  minmemory       = "128"
 
  autoscalingminreplicas = "1"
  activeregions          = ["falkenstein-1"]
  project                = bahriya_project.web.id
}

terraform init
terraform plan
terraform apply

Important behaviours

Handles are permanent

For projects, containers, and Memcached instances, handles cannot be reused after the resource is deleted. Treat them as permanent identifiers and use distinct handles per environment (e.g. api-prod, api-staging).

Registry and secret handles are released on delete and can be reused.

Project references use UUIDs

When a resource needs a project attribute, pass the project UUID — not the handle:

project = bahriya_project.web.id    # correct
project = bahriya_project.web.handle # wrong — will fail

Async creation

Container and Memcached creation can take several minutes. The provider polls the API until the resource reaches running status (default timeout: 10 minutes).

Importing existing resources

terraform import bahriya_container.api <uuid>

Per-resource guides

Each resource has a dedicated article with a complete working example:

• Installation
• Projects
• HTTP Containers
• Worker Containers
• Cron Jobs
• Registries
• Secrets
• Memcached
• TLS Bundles
• X.509 Certificates
• GPG Keypairs
• SSH Keypairs
• Encryption Keys
• Env Files
• YAML Configs
• JSON Configs
• Plain Configs
• Complete Example — all resources together in one config