Deployment Environment Variables

This is the complete set of environment variables involved in deploying Nirvana Cloud resources with Terraform and then configuring them over SSH. Each entry below was read from the source that consumes it, and the “Read by” column names exactly which tools honour it — a variable set for one tool is not necessarily picked up by another.

Nirvana Variables

Variable	Required	Read by	What it does
NIRVANA_LABS_API_KEY	Yes	Terraform provider, Go SDK, TypeScript SDK, CLI	Bearer token for every API call. The provider fails configuration with Missing api_key value if neither this nor the api_key argument is set.
NIRVANA_LABS_BASE_URL	No	Terraform provider, Go SDK, TypeScript SDK, CLI	Overrides the API base URL. Defaults to https://api.nirvanalabs.io. Only needed to target a non-production endpoint.
NIRVANA_LABS_CUSTOM_HEADERS	No	Terraform provider, Go SDK, TypeScript SDK, CLI	Extra headers added to every request. Newline-separated Name: value lines; lines without a colon are ignored.
NIRVANA_LABS_LOG	No	TypeScript SDK	Client log level. One of off, error, warn, info, debug. Defaults to warn. Not read by the Terraform provider, Go SDK, or CLI — for Terraform, use TF_LOG instead.

NIRVANA_LABS_CUSTOM_HEADERS reaches the Terraform provider and the CLI even though neither mentions it: both build their client with nirvana.NewClient from the Go SDK, which always applies the SDK’s environment defaults. It is therefore an environment-only setting for those two — the provider has no HCL attribute for custom headers, and the CLI has no flag.

Example Values

# The only variable you must set.
export NIRVANA_LABS_API_KEY="REPLACE_WITH_YOUR_API_KEY"

# Optional.
export NIRVANA_LABS_BASE_URL="https://api.nirvanalabs.io"
export NIRVANA_LABS_CUSTOM_HEADERS="X-Trace-Id: local-dev
X-Team: platform"
export NIRVANA_LABS_LOG="debug"

API keys are opaque strings with no fixed prefix, so there is no format to pattern-match against. A key is also scoped to one or more projects when it is created, which means the key you export has to include the project you set in TF_VAR_project_id — otherwise calls fail with 403 Forbidden rather than a validation error.

Caution

Never commit an API key. Keep it in an untracked .env file or a secret manager, and use an obvious placeholder in anything you check in.

How the Provider Resolves Credentials

The provider checks the explicit argument first and the environment second, per attribute:

provider "nirvana" {
  # Wins over NIRVANA_LABS_API_KEY when set.
  api_key = var.nirvana_api_key

  # Wins over NIRVANA_LABS_BASE_URL when set.
  # base_url = "https://api.nirvanalabs.io"
}

An empty provider "nirvana" {} block is the usual form — it takes both values from the environment:

provider "nirvana" {}

api_key and base_url are the provider’s only configuration attributes. There is no region, project, or profile attribute at the provider level; region and project are set per resource.

Terraform Input Variables

Terraform reads any variable named TF_VAR_<name> into the input variable <name>. Nirvana resources need a project ID and, for VMs you intend to reach over SSH, a public key — so these two show up in every deployment:

Variable	Required	Maps to	Example
TF_VAR_project_id	Yes	variable "project_id"	TF_VAR_project_id=123e4567-e89b-12d3-a456-426614174000
TF_VAR_ssh_public_key	For SSH access	variable "ssh_public_key"	TF_VAR_ssh_public_key="ssh-ed25519 AAAAC3Nza... [email protected]"

These names are a convention, not a provider feature: they work only because the configuration declares matching variable blocks. The terraform-nirvana-nks module and the deployment examples in nirvana-labs-examples both use exactly these two names, so the declarations look like this:

variable "project_id" {
  description = "Nirvana Labs project ID"
  type        = string
}

variable "ssh_public_key" {
  description = "SSH public key for VM access"
  type        = string
}

If you would rather use a terraform.tfvars file than the environment, the equivalent is:

project_id     = "123e4567-e89b-12d3-a456-426614174000"
ssh_public_key = "ssh-ed25519 AAAAC3Nza... [email protected]"

project_id is not optional anywhere. nirvana_compute_vm, nirvana_compute_volume, nirvana_networking_vpc, and nirvana_nks_cluster all require it, and the API’s list endpoints require it as a query parameter.

Terraform’s own diagnostic variable is worth knowing too, since the Nirvana provider has no logging setting of its own:

Variable	Required	What it does
TF_LOG	No	Terraform log level: TRACE, DEBUG, INFO, WARN, ERROR, OFF. TF_LOG=DEBUG shows the provider’s API requests, which is the way to debug a failing apply. An unrecognised value falls back to TRACE.

What SSH Needs

There is no Nirvana-specific SSH environment variable. Access is configured through the VM resource and then used with your normal SSH client:

1. Public key on the VM. nirvana_compute_vm takes a single ssh_key.public_key string, injected at creation time:

   resource "nirvana_compute_vm" "app" {
     # ...
     ssh_key = {
       public_key = var.ssh_public_key
     }
   }

2. A public IP, unless you are connecting from inside the VPC. Set public_ip_enabled = true and read the assigned address from the public_ip attribute.

3. A firewall rule allowing port 22. Nothing is reachable by default. Restrict the source to the networks you administer from rather than opening port 22 to the internet:

   variable "admin_cidr" {
     description = "Network-aligned CIDR allowed to reach SSH, e.g. your VPN or office range."
     type        = string
   }
   
   resource "nirvana_networking_firewall_rule" "ssh" {
     vpc_id              = nirvana_networking_vpc.main.id
     name                = "allow-ssh"
     protocol            = "tcp"
     source_address      = var.admin_cidr
     destination_address = nirvana_networking_vpc.main.subnet.cidr
     destination_ports   = ["22"]
   }

   Caution

   source_address = "0.0.0.0/0" on port 22 exposes the VM to the whole internet and to continuous SSH brute-force traffic. Use a VPN, office, or bastion CIDR instead. If you genuinely need a wide-open rule for a short-lived test, delete it afterwards rather than leaving it in a long-running configuration.

4. The right login user. On the Ubuntu images, it is ubuntu:

   ssh -i ~/.ssh/id_ed25519 ubuntu@"$(terraform output -raw vm_public_ip)"

For Ansible, the same three values become inventory settings rather than environment variables — ansible_host from the public_ip output, ansible_user=ubuntu, and ansible_ssh_private_key_file pointing at the private half of the key you passed in:

[app]
app-1 ansible_host=203.0.113.10 ansible_user=ubuntu ansible_ssh_private_key_file=~/.ssh/id_ed25519

A Complete Deployment Setup

# .env — keep this file untracked.
NIRVANA_LABS_API_KEY=REPLACE_WITH_YOUR_API_KEY
TF_VAR_project_id=123e4567-e89b-12d3-a456-426614174000
TF_VAR_ssh_public_key="ssh-ed25519 AAAAC3Nza... [email protected]"
TF_VAR_admin_cidr=203.0.113.0/24

set -a; source .env; set +a

terraform init
terraform apply

ssh -i ~/.ssh/id_ed25519 ubuntu@"$(terraform output -raw vm_public_ip)"

To confirm the credentials resolve before running an apply, list your projects with the CLI or a plain HTTP call:

curl -sS https://api.nirvanalabs.io/v1/projects \
  -H "Authorization: Bearer $NIRVANA_LABS_API_KEY"

Related

• SDKs & Tools
• VMs
• Firewall Rules
• Terraform Registry — nirvana-labs/nirvana