Not every application needs Kubernetes. But in VCF 9.1, “not Kubernetes” does not automatically mean “Nomad.”
VMware Cloud Foundation (VCF) 9.1 gives infrastructure teams several ways to run modern applications. VMware vSphere Kubernetes Service (VKS) is the natural choice when the application and its operators expect Kubernetes. But what if your estate consists of a few containerized services, Java processes, scheduled batch jobs and perhaps a GPU-backed inference service? Running a Kubernetes platform for every one of those workloads may be unnecessary.
HashiCorp Nomad is worth examining here. Its control plane schedules work onto existing machines; task drivers can run containers as well as non-containerized applications. It does not need an external database to maintain its own cluster state. The important question is not whether Nomad can run on VCF—it can run in Linux VMs like other software—but whether adding a separately operated scheduler brings enough value to justify its integration and support costs.
First, the comparison has three options—not two
VKS is VCF’s Kubernetes path. It provides declarative lifecycle management for Kubernetes clusters through the vSphere Supervisor, with platform integration for VM-based nodes, networking and persistent storage. VCF 9.1 also improves VKS deployment and scale. If your teams depend on Kubernetes APIs, Helm charts, operators and the broader cloud-native ecosystem, this is the obvious starting point.
VCF Container Service is the option an honest Nomad comparison cannot ignore. It lets users deploy container workloads as VM-backed vSphere Pods without managing a separate workload Kubernetes cluster. It is exposed through VCF consumption interfaces, but it still uses the Supervisor under the hood: “no cluster to manage” does not mean “no Kubernetes-derived platform components.” For a small number of OCI container applications, evaluate this built-in service before adding another orchestrator.
Nomad on VCF is a different architectural choice: install Nomad servers and clients in guest VMs, then own that workload platform yourself. Its strongest argument is not that it runs containers—both VMware options do—but that one scheduler can also handle non-containerized services and batch jobs. You gain a flexible application scheduler while taking on its upgrades, access control, recovery, integrations and support model.
A sensible reference design
Start in a VCF workload domain, not on ESX directly. Provision three Nomad server VMs across separate vSphere host/failure domains, following HashiCorp’s production reference architecture for an odd-numbered Raft quorum. Add a pool of Linux client VMs for ordinary jobs; create a separate client pool only if workloads need distinct hardware, security boundaries or GPUs. Place these VMs on appropriate vSphere storage and networks, and design vSphere DRS/HA placement alongside Nomad’s own allocation placement. vSphere HA restarts VMs; Nomad reschedules application allocations when capacity is available. Neither replaces an application-level data-recovery design.
The control boundary is clean:
- VCF/vSphere/VCF Automation or an appropriate Terraform provider: provision and lifecycle-manage VM capacity, storage policy and networks.
- Nomad: register clients, place jobs, enforce resource requests and constraints, run updates, and reschedule failed allocations when capacity exists.
- Optional services: use Nomad’s basic native discovery for a small pilot; assess Consul for more demanding service discovery, and Vault if your secrets requirements justify it. Neither is required for Nomad’s own Raft state.
This is a reference design, not a claim of a supported, out-of-the-box Nomad integration with VCF 9.1.
Where the integration gets interesting—and uncertain
VM lifecycle. VCF Automation and vSphere tooling can provision Linux VMs; guest-init tooling can install and configure Nomad. The join-and-drain workflow, safe removal of clients, image patching, and capacity feedback must be designed and tested by your team. Drain a Nomad client and verify allocation migration before deleting its VM. Do not assume VCF Automation natively autoscales Nomad clients, or that a particular Terraform provider supports generic VM provisioning on your exact VCF build.
Networking and security. Put Nomad VMs on appropriately segmented NSX-backed networks and enforce VM-level policy with NSX/vDefend where licensed and configured. Nomad supports its own CNI-based bridge networking, but that fact alone does not make NSX a validated Nomad CNI, nor does VM-level distributed firewalling automatically produce per-allocation microsegmentation. Decide how ingress, service discovery, east-west policy and DNS will actually work.
Storage. A client VM’s virtual disks can live on vSAN as ordinary VM storage. That is a different proposition from dynamic application volumes. Nomad supports CSI, but the VMware vSphere CSI driver is designed and documented for Kubernetes. Do not promise Nomad-to-vSphere CSI compatibility or official vendor support without an end-to-end test and a confirmed support statement. Start a pilot with stateless services; add stateful placement and backup requirements only when the storage path is clear.
GPUs and private AI. Nomad has a device-plugin framework and an NVIDIA device plugin, tested by HashiCorp with its Docker driver. That makes GPU-aware scheduling an interesting experiment for inference or batch jobs in GPU-enabled guest VMs. The guest must actually see usable GPU devices, with a supported VCF 9.1 GPU access mode, NVIDIA hardware, guest driver and container-runtime combination. Verify that matrix and measure GPU utilization; a Nomad job requesting a GPU does not validate the underlying virtualization stack.
Operations. VCF Operations can observe the infrastructure, while Nomad exposes its own workload telemetry. Bringing the two views together is an observability project, not a built-in Nomad management pack. Budget for ACLs, TLS, audit, upgrades, backups of Nomad state, monitoring and incident ownership. A small scheduler binary does not eliminate the platform work around it.
A focused proof of concept
I would not begin with CSI or production AI. I would run a short pilot in this order:
- Provision three Nomad server VMs and at least three Linux clients; document placement, quorum, networking and VM backup/restore assumptions.
- Deploy one stateless container service and one non-containerized or batch job; compare the deployment workflow with VKS and VCF Container Service for the same use case.
- Fail a client VM and then one Nomad server. Measure application recovery, surviving quorum, vSphere HA behavior and the operational steps—not just whether a green dashboard returns.
- Apply NSX policy at the VM boundary, test reachability and service discovery, and document any gaps in per-workload segmentation.
- Only then test persistent storage and GPU clients as separate experiments, recording exact versions and vendor support positions before drawing conclusions.
Use observable criteria: deployment effort, day-2 patching, failure recovery, storage and network behavior, policy fit, team skills and total platform ownership. “Nomad uses fewer control-plane components” is a design fact; “therefore it is cheaper or better on VCF” is a hypothesis until measured.
My take
If your applications are already Kubernetes-native, use VKS. If you simply need to run a limited set of containers without operating workload clusters, examine VCF Container Service first. If you have a genuine mix of containers, native applications and batch work—and need a continuously running scheduler across a pool of VMs—Nomad is a credible alternative workload layer on VCF 9.1.
That is the right claim: an alternative workload layer, not a VKS replacement and not a VMware-supported native integration by default. VCF supplies the virtual infrastructure; Nomad can schedule applications on top of it. The value of the combination will be decided by the PoC, particularly at the networking, persistent-storage and GPU boundaries.
