Deploy a Project with Terraform

A project is the top-level grouping for your containers, secrets, registries, and Memcached instances. Every other resource belongs to a project.

Required fields

Field	Type	Description
`handle`	string	A unique, permanent identifier. Cannot be reused after deletion.
`name`	string	A human-readable display name.
`regions`	list	One or more region IDs where the project operates.

Minimal example

resource "bahriya_project" "app" {
  handle  = "my-app"
  name    = "My Application"
  regions = ["falkenstein-1"]
}

Multi-region project

resource "bahriya_project" "app" {
  handle  = "my-app"
  name    = "My Application"
  regions = ["falkenstein-1", "helsinki-1", "virginia-1"]
}

Using a data source to pick regions

data "bahriya_regions" "active" {
  status_filter = "active"
}
 
resource "bahriya_project" "app" {
  handle  = "my-app"
  name    = "My Application"
  regions = [data.bahriya_regions.active.regions[0].id]
}

Outputs

After creation, the project exposes:

Attribute	Description
`id`	The project UUID. Pass this to other resources as their `project` attribute.
`handle`	The handle you set.

output "project_id" {
  value = bahriya_project.app.id
}

Attaching vault items, configs, registries, and secrets

The bahriya_project resource manages only the project's core fields (name, handle, regions). Attachments are managed by a separate per-type resource so each one is a first-class Terraform object you can plan, import, and destroy independently.

Available attachment resources:

Resource	Attaches
`bahriya_project_registry_attachment`	Container registry credentials
`bahriya_project_secret_attachment`	Opaque secret
`bahriya_project_tls_bundle_attachment`	TLS bundle (CA + cert + key)
`bahriya_project_x509_cert_attachment`	X.509 certificate
`bahriya_project_gpg_keypair_attachment`	GPG keypair
`bahriya_project_ssh_keypair_attachment`	SSH keypair
`bahriya_project_encryption_key_attachment`	Symmetric encryption key
`bahriya_project_env_file_attachment`	`.env` file
`bahriya_project_yaml_config_attachment`	YAML config
`bahriya_project_json_config_attachment`	JSON config
`bahriya_project_plain_config_attachment`	Plain-text config

Each resource takes a project_id (UUID) and a handle referring to an existing org-level item. Both attributes force replacement — to change either, Terraform will detach then re-attach.

resource "bahriya_project" "app" {
  handle  = "my-app"
  name    = "My Application"
  regions = ["falkenstein-1"]
}
 
resource "bahriya_tls_bundle" "edge" {
  handle = "edge-cert"
  name   = "Edge TLS"
  ca     = file("ca.pem")
  cert   = file("cert.pem")
  key    = file("key.pem")
}
 
resource "bahriya_project_tls_bundle_attachment" "edge_to_app" {
  project_id = bahriya_project.app.id
  handle     = bahriya_tls_bundle.edge.handle
}

Outputs

Each attachment exposes:

Attribute	Description
`id`	Composite ID — `{project_id}:{handle}`. Use this when importing.
`join_id`	Identifier of the underlying project-attachment join row (returned by the API).

Importing

terraform import bahriya_project_tls_bundle_attachment.edge_to_app <project_uuid>:edge-cert

Wiring attached items into a container

Once an item is project-attached, container resources reference it via their own blocks (e.g. tls_bundles { handle = "edge-cert"; mount_path = "/etc/tls" } on the bahriya_container resource). Use Terraform's depends_on (or natural attribute references) to ensure the attachment lands before the container is created.

Notes

The id (UUID) is what other resources need — always use bahriya_project.x.id, not .handle, when setting the project attribute on containers, Memcached, etc.
Changing the handle forces Terraform to destroy and recreate the project.
Projects are soft-deleted. The handle is permanently consumed once used.