VMware

Primcoat converts the hardened QCOW2 master to VMDK, generates the OVF descriptor that goes with it, and uploads both through the vSphere API as a Content Library item.

Primcoat installs VMware Tools during the build, so the guest has a clean shutdown path, time synchronization, and usable metrics rather than being a black box to the host.

Why a Content Library item

A Content Library is the native way vSphere distributes a template: items can be published and subscribed between libraries, so an image Primcoat puts into one library can replicate to the sites that subscribe to it without Primcoat needing a credential for each one. Deploying from the item is a normal vSphere operation, which means your existing provisioning path does not change because the image started as a Primcoat build.

VMware on AWS, Azure, and Google Cloud

Managed VMware clouds are full vSphere environments, so Primcoat publishes into them exactly as it does on-premises — point the target at the environment’s vCenter and Content Library. This covers VMware Cloud on AWS, Azure VMware Solution, and Google Cloud VMware Engine: the same hardened image, the same Content Library item, whether your vCenter runs in your datacenter or on a hyperscaler.

What you configure

A publish target holds the vCenter endpoint and credentials, and the Content Library to publish into. You define the image name, and add version information and other details as you like.

vSphere is reached by a build worker inside your own network rather than from Primcoat’s infrastructure — we will not ask you to expose vCenter to the internet, so the product refuses to pair this destination with a hosted worker rather than letting you try. The platform overview covers how the worker is deployed and why your vCenter password is not something Primcoat could hand over even if asked. Security & compliance covers the SBOM, Cosign signature and compliance report that ship with the image.