Core Entities in Thinfinity Cloud Manager

Cloud Manager organizes its functionality around a set of well-defined entities. Understanding how these entities relate to each other is essential before configuring providers, building models, or deploying instances. This article describes each core entity, its role, and how it fits into the broader Cloud Manager workflow.

Throughout this manual, the word model refers specifically to VDI/DaaS Models — the entity type that wraps a template and provisions instances through Cloud Manager. Managed VMs and Pods are peer entities, not kinds of model. The Choosing a Compute Path article covers the operational differences between these three paths; this article covers how they fit into the entity hierarchy.

Entity Relationship Overview

The diagram below shows the relationships between the main entities in Cloud Manager:

Reading the diagram:

• Credentials feed all three peer entities — Managed VMs, VDI/DaaS Models, and Pods all require credentials to authenticate against their target provider, hypervisor, or cluster.
• Templates, Model Versions, and Deployments belong only to VDI/DaaS Models (shown in the same color) — Templates feed a model, while Model Versions and Deployments derive from it. Managed VMs and Pods use none of them: Managed VMs point at pre-existing infrastructure, and the YAML configuration that defines Pods is stored in Cloud Manager, in the model’s K8S Configuration.
• Model Versions hang off VDI/DaaS Models as a sub-entity rather than participating in the rightward flow toward Instances.
• The solid VDI/DaaS Models → Deployments → Instances path represents the provisioning chain: a model deployment is a Terraform run that creates Instances.
• The dotted Managed VMs → Instances arrow represents the linking path: Managed VMs register existing infrastructure as Instances without a Deployment record.
• Access Profiles are defined in Thinfinity® Workspace, not in Cloud Manager, but they are shown here as the final step in the user-access flow.

Credentials

Credentials store the authentication information that Cloud Manager uses to communicate with a cloud provider, on-premises hypervisor, or Kubernetes cluster. Each credential set is scoped to a single provider type (for example, AWS, Azure, Proxmox VE, or Kubernetes).

Cloud Manager uses credentials to:

• Provision, start, stop, and destroy resources on behalf of the platform.
• Retrieve real-time status and metrics for managed resources.
• Validate that the configured target is reachable when a model or Managed VMs entry is created or edited.

Credentials are created and managed in the Credentials tab of Cloud Manager. Each credential record includes the provider type, connection parameters, and an optional friendly name for identification.

For provider-specific field requirements, see the Credentials section.

Managed VMs

A Managed VMs entry is a registration record that points Cloud Manager at an existing virtual machine — provisioned outside Cloud Manager on a cloud provider or on-premises hypervisor — so that it can be brokered to users through Thinfinity® Workspace. Unlike VDI/DaaS Models, Managed VMs do not provision, resize, or destroy infrastructure; they only link to it.

A Managed VMs entry stores:

• The credential set used to reach the target VM.
• Connection details: Public IP, Private IP, or Agent Id.
• A friendly name and provider context for identification in the Cloud Manager UI.

Managed VMs do not have templates, Deployments, Model Versions, pooling, power, or destroy policies. They are a thin connection layer that makes existing infrastructure addressable through the same session-brokering surface as VDI/DaaS-provisioned instances.

For the operational differences between Managed VMs and VDI/DaaS Models, see Choosing a Compute Path.

Templates

A template in Cloud Manager is the infrastructure definition that a VDI/DaaS Model uses to provision compute resources. There are two template categories:

Templates are not a separate top-level UI entity — they are uploaded or selected during VDI/DaaS Model creation and edited through the model editor. Managed VMs do not use templates; the Kubernetes YAML that defines Pods is stored in Cloud Manager, in the model’s K8S Configuration.

VDI/DaaS Models

A VDI/DaaS Model — referred to throughout this manual simply as a model — is the configuration entity that wraps a template with all the settings needed to provision and manage a class of compute resources at scale:

• Provisioning parameters: template inputs, resource sizing, location, network selection.
• Pooling and connectivity: pool mode, connection mode, instance counts.
• Power and destroy policies: scheduled or on-demand power, automatic destruction.
• Versioning: Testing, Staging, and Production version states.
• Golden Image reference (on-premises hypervisors only): the base VM image used to clone new instances. See Golden Images: Concept and Role.

For a full breakdown of model settings, see Model Settings Reference.

Model Versions

Model Versions allow administrators to track and manage changes to a VDI/DaaS Model over time. Each version carries a state — Testing, Staging, or Production — and the active Production version is what end users connect to. Test changes in Testing or Staging before promoting them.

Existing instances continue running on the version they were deployed with until they are detached and re-provisioned.

For the version update workflow, see Update a Model’s Version.

Deployments

A deployment represents one Terraform run initiated against a VDI/DaaS Model — either an Apply (creating new resources) or a Destroy (tearing them down). Deployments live in the per-model Deployments tab and are visible only on VDI/DaaS Models.

Deployments can be:

• Automatic — triggered by the model’s scheduled provisioning or destroy events.
• Manual — initiated by an administrator from the model’s Deployments tab using the Deploy action.

Instances

An instance is an individual VM under Cloud Manager’s management. Instances can originate in two ways:

Each instance has an operational status (for example, Active, Inactive, Provisioning, Activating, Inactivating, Deleting) and a record state (Reset, Enabled, Disabled, Error, Deleting, Deleted). For the complete state model and transitions, see Instance States and Lifecycle.

Pods

For Kubernetes integrations, the unit of compute is a pod. The pod definition is stored in Cloud Manager, in the model’s K8S Configuration. When a user connects, Cloud Manager creates a pod on demand, monitors its state, and brokers the user’s session to it; it removes the pod after the model’s Destroy after idle period elapses. The Kubernetes cluster schedules and runs the pod.

In the Cloud Manager UI, Kubernetes models are listed under the VDI/DaaS Models node in the left tree, distinguished by a Kubernetes icon. Selecting a K8S model in the tree replaces the Instances tab with a Pods tab on the right, whose columns and actions are Kubernetes-specific (Pod Name, Username, Created At). The primary use case for Kubernetes models is Remote Browser Isolation.

Access Profiles

Access Profiles are the Thinfinity® Workspace mechanism that grants end users access to Cloud Manager’s instances or pods. Cloud Manager does not own Access Profiles, but it integrates with them: an Access Profile points at a specific VDI/DaaS Model, Managed VMs entry, or Pod source, and Cloud Manager routes user sessions to a matching resource when the user connects.

Access Profiles also drive manual user-to-instance pinning for VDI/DaaS Models without Allow Dynamic Assignment — see Manually Assign an Instance to a User.

For the Access Profile creation workflow, see Connecting Users to Instances.

Entity Lifecycle Summary

The table below summarizes how the core entities are created and removed.

See Also

• Choosing a Compute Path
• Pooling Strategies
• Golden Images: Concept and Role
• Model Settings Reference
• Instance States and Lifecycle