Platform
How a build actually runs.
Ten stages, in order, on every image. Nothing is skipped because it was inconvenient, and nothing publishes until it has passed.
Fetch base
Primcoat pulls the upstream image from a verified source cache — official Ubuntu, Debian, AlmaLinux and Rocky cloud images, Red Hat's portal for RHEL, or the Microsoft Evaluation Center for Windows Server. Every artifact is checked against a known SHA256 before it is used. An upstream monitor watches those sources and queues a fetch when a new release lands.
Provision
Packer boots the base image as a real VM under QEMU/KVM. Your selected catalog packages are installed and your own Ansible hooks run, with access only to the secrets you declared.
Harden
OpenSCAP evaluates the image against the compliance profile you chose — CIS Level 1, CIS Level 2, or DISA STIG — and auto-remediates. The correct SCAP Security Guide content is selected from the image's OS family, so a RHEL 9 image is graded against RHEL 9 rules and an Ubuntu 24.04 image against Ubuntu 24.04 rules.
Validate
A second OpenSCAP pass scores the hardened image, and a CVE scan runs against the installed packages. If the image falls below your compliance threshold, the build fails. It does not publish a non-compliant image and warn you about it later.
Generate SBOM
A full software bill of materials is produced in both CycloneDX and SPDX, so the artifact is consumable by whichever toolchain your organization has standardized on.
Sign & attest
The image is signed with Cosign and SLSA build provenance is attached, giving you a verifiable chain from the upstream base image to the artifact you deploy.
Smoke test
The image is booted and checked for responsiveness before anything is published. A hardened image that will not boot is a failed build, not a released one.
Inject agents
Each destination needs its own guest agent — the ENA driver for AWS, the Azure Linux Agent, the Google guest environment, VMware Tools, the QEMU guest agent for OpenShift. These are added per destination, as a lightweight step on top of the single hardened base.
Convert
The QCOW2 master is converted to the disk format each destination expects: RAW for AWS, a fixed VHD for Azure, a tarballed RAW for Google Cloud, VMDK for VMware.
Promote
The finished artifact is assigned to a channel — dev, staging, or prod — and your webhooks fire. Promotion is how a build becomes the image your fleet actually deploys.
One base image, many variants
The expensive work — provisioning, hardening, scanning, signing — happens exactly once, against a single QCOW2 master. Only the destination-specific parts happen per target: the guest agent, and the disk format.
That matters for more than build time. It means every variant you deploy traces back to the same hardened, scanned, signed base — so the compliance score and the SBOM you show an auditor describe the image running in all of your clouds, not just one of them.
Windows Server, properly
Windows images are built from the installation ISO with an unattended answer file and the virtio driver ISO mounted alongside it. They take longer than Linux builds — typically 60 to 120 minutes — because a Windows installation genuinely takes that long.
Cloudbase-Init is installed and kept in every Windows image. It is what personalizes each instance at boot — hostname, administrator credentials, user data — and stripping it out to make an image look cleaner is how teams end up with a fleet of identically-named machines.
See the pipeline run on your own image.
Bring an OS, a compliance profile, and a cloud account. Primcoat handles the ten stages in between.