|Manuals

Infrastructure as Code (Terraform) Strategic Overview

This article provides a strategic overview of how Thinfinity® Cloud Manager uses Infrastructure as Code (IaC) — specifically HashiCorp Terraform — and where IaC fits in your overall VDI/DaaS deployment strategy. It is intended for architects, IT decision-makers, and platform owners evaluating whether to standardize on built-in blueprints, custom Terraform templates, or a mix of both.

For the technical reference and authoring guide, see the Custom Terraform Templates section.

Why Cloud Manager Is Built on Terraform

Cloud Manager uses Terraform under the hood for all model provisioning, including those built from blueprints. Built-in blueprints are essentially pre-authored, validated Terraform templates that Cloud Manager exposes through a guided wizard. Custom Terraform templates expose the underlying mechanism directly.

This architecture provides three key benefits.

Benefit What It Means in Practice
Consistency Every instance from the same model is provisioned identically, eliminating configuration drift.
Auditability The Terraform state file for each deployment provides a complete record of what was provisioned.
Portability Models can be exported, version-controlled, reviewed, and migrated across environments.

Built-in Blueprint vs. Custom Terraform

The decision between built-in blueprints and custom Terraform templates is a strategic one, not a technical limitation.

Dimension Built-in Blueprint Custom Terraform
Setup complexity Wizard-driven, no code Requires Terraform/HCL expertise
Time to first deployment Minutes Hours to days, depending on template
Provider parameter coverage Common parameters only Full provider API
Customization Limited to wizard fields Unlimited
Maintenance Managed by Cybele Software Owned by your team
Versioning Cloud Manager’s model versioning Model versioning + your Git repository
Best for Standard cloud VMs, fast onboarding, less-skilled teams Complex networking, multi-resource, existing IaC investment
Info

Most production deployments use a mix. Standard, simple VM models are deployed via blueprints for speed. Complex models (custom networking, GPU workloads, integration with existing infrastructure) are deployed via Terraform templates and version-controlled in the same Git repositories as the rest of the team’s IaC.

The Terraform mechanisms described in this article apply only to VDI/DaaS Models. Managed VMs register pre-existing VMs without provisioning them — no Terraform is involved. Kubernetes models use Kubernetes YAML in the K8S Configuration tab, also outside the Terraform path.

When to Choose Custom Terraform

Choose custom Terraform templates when any of the following apply:

  • Your organization already has a Terraform module library you want to reuse
  • You need provider features not exposed in the blueprint wizard
  • Your network topology requires custom VPCs, subnets, security groups, or routing
  • Multiple resources beyond the VM itself must be provisioned per instance (e.g., dedicated EBS volumes, attached IPs, custom IAM roles)
  • Your compliance or security teams require IaC review of all provisioning changes
  • You want to integrate model authoring with your existing CI/CD pipeline

Choose built-in blueprints when:

  • You need to onboard a new provider or environment in minimal time
  • Your team does not have Terraform expertise
  • The default provider parameters meet your requirements
  • The workload is rapid prototyping or proof-of-concept

Terraform in Cloud Manager: A Mental Model

Treat Cloud Manager as a Terraform orchestrator with a UI. The system handles:

  • State management — Each deployment has its own Terraform state, stored and tracked by Cloud Manager
  • Variable injection — Reserved variables (vmname and other vdi_* metadata) are populated automatically based on the model’s configuration and the instance being provisioned
  • Lifecycle hooks — Power, scaling, and destroy events trigger the corresponding Terraform operations
  • UI rendering — schema.json and uischema.json files render the Parameters step of the model creation wizard

You author the templates; Cloud Manager runs the lifecycle. This split is what makes Cloud Manager simpler to operate than running Terraform directly: you don’t have to manage state files, write deployment automation, or build a UI on top of terraform apply.

Governance and Review

For organizations with strong governance requirements, treat Terraform templates as software.

Practice Recommendation
Source control Store all custom templates in Git, alongside the rest of your IaC
Code review Require peer review of template changes before they are imported into Cloud Manager
Versioning Use semantic version tags on Git releases; align with Cloud Manager model versions
Testing Use Cloud Manager’s Testing version to validate template changes before promoting to Production
Backups Use Export Models to back up the active version before promoting changes
Linting Run terraform fmt and terraform validate in your CI pipeline before importing templates

Limitations

Custom Terraform templates in Cloud Manager have the following constraints:

  • The VM resource’s name attribute must reference var.vmname — Cloud Manager injects a per-instance name based on the model’s naming scheme, and a static name would cause collisions across instances
  • Reserved variables (vmname and vdi_* metadata) must not appear in schema.json — see Terraform Overview — Reserved Variables
  • Cloud Manager controls the Terraform execution environment — you cannot inject custom Terraform CLI flags or backend configurations

See Also