Compute – Instances

Use Terraform to provision and manage Verda compute instances (CPU or GPU) declaratively. Instances are suitable for long-running workloads such as training jobs, interactive development, or services that require dedicated compute capacity.

---

What this page covers

• Creating a compute instance with Terraform

• Common configuration options (instance type, image, disk, access)

• Managing instance lifecycle safely

• Importing existing instances into Terraform state

---

Basic example

terraform {
  required_providers {
    verda = {
      source  = "verda-cloud/verda"
      version = "~> 1.0"
    }
  }
}

provider "verda" {}

resource "verda_instance" "example" {
  name          = "training-01"
  instance_type = "gpu-a100-80gb"   # example
  image         = "ubuntu-22.04"    # example

  # Optional: root disk size (if supported by your instance type)
  # disk_size_gb = 200

  # Optional: attach SSH keys managed by Terraform
  # ssh_key_ids = [verda_ssh_key.main.id]

  # Optional: run a startup script on first boot
  # startup_script = file("${path.module}/startup.sh")
}

output "instance_id" {
  value = verda_instance.example.id
}

output "public_ip" {
  value = verda_instance.example.public_ip
}

---

Key concepts

Instance identity

The name field is a human-readable identifier for the instance. Use the Terraform-managed id output when referencing the instance from other resources such as volumes or firewall rules.

---

Instance types

The instance_type defines the hardware configuration of the instance, including:

• CPU core count

• Memory

• GPU model and VRAM (for GPU instances)

Changing the instance_type usually requires the instance to be recreated. For a complete list of supported instance types, refer to the Verda API documentation.

---

Images

The image field defines the operating system or base image used for the instance.

For reproducible deployments:

• Prefer explicit image versions

• Avoid floating aliases such as “latest” when possible

For a list of supported images, check GET /images endpoint, "image_type" property.

---

SSH access

SSH access is usually managed by attaching one or more SSH keys to the instance.

You can:

• Reference SSH keys created and managed by Terraform

• Reference existing SSH keys already registered in Verda

See Compute – SSH Keys for details.

---

Startup scripts

Startup scripts allow you to run commands when the instance boots for the first time. Common use cases include:

• Installing system packages

• Pulling code repositories

• Configuring services

• Mounting storage volumes

Startup scripts are Script content. Example #!/bin/bash echo hello world

See Compute – Startup Scripts.

---

Common configuration options

Verda compute instances commonly support:

• name – human-readable instance name

• instance_type – CPU/GPU hardware configuration

• image – operating system or base image

• disk_size_gb – root disk size (if configurable)

• ssh_key_ids – SSH keys allowed to access the instance

• startup_script – script executed on first boot

To see the exact schema supported by your provider version, run:

terraform providers schema -json | jq '.provider_schemas'

---

Safe updates and lifecycle controls

Some changes (such as instance type or image) require destroying and recreating the instance.

To protect important instances, you can use lifecycle rules:

resource "verda_instance" "example" {
  # ...

  lifecycle {
    prevent_destroy = true
  }
}

This is strongly recommended for production workloads.

---

Import an existing instance

If an instance already exists in Verda, you can import it into Terraform:

terraform import verda_instance.example <instance-id>

Then run:

terraform plan

Adjust your Terraform configuration until the plan shows no changes.

---

Troubleshooting

• Authentication errors Ensure your Verda credentials are correctly set and accessible to Terraform.

• Unexpected instance recreation Changes to instance_type or image often force replacement. Pin values explicitly.

• SSH connectivity issues Verify the instance has a public IP, the correct SSH key is attached, and inbound SSH access is allowed.