Platform
Configuration in. Hardened, signed images out.
Primcoat owns the entire build pipeline — the base image, the provisioning, the hardening, the scanning, the signing, and the publishing. You own the configuration that describes what you want.
What you configure
Four layers, all editable in the dashboard or through the API. None of them require you to write build code.
Image definitions
The unit of configuration. An OS and version, a hardening policy, a set of software packages, a version-naming template, and a list of publish targets.
Hardening policies
CIS Level 1, CIS Level 2, DISA STIG, or a custom profile. Primcoat selects the correct SCAP Security Guide content for the image's OS family automatically.
Software catalog
Curated, versioned, tested integrations — EDR, vulnerability agents, monitoring, config management, identity, and cloud agents. Each one ships with a compatibility matrix and a post-install validation test.
Your customizations
Variables and encrypted secrets, structured user and SSH-key definitions, file injection, and — for power users — your own Ansible role from your Git repository.
Go deeper
Image pipeline
How a build actually runs: fetching a verified upstream image, provisioning it in a real VM, hardening it, and converting it for each destination.
How builds work →
Security & compliance
CIS and STIG hardening via OpenSCAP, CVE scanning, CycloneDX and SPDX SBOMs, Cosign signatures, and SLSA provenance on every image.
Hardening, SBOM & signing →
API & integrations
A versioned REST API described by an OpenAPI spec, with async builds and idempotency keys. Everything in the dashboard is reachable from CI.
Build it into your pipeline →
Where it runs
Where a build runs is decided by where it has to publish to — not by a plan you pick.
Publishing to a cloud
AWS, Azure and Google Cloud are reachable from our infrastructure, so Primcoat builds and publishes without anything of yours having to be exposed.
The recommended setup for each is federated identity — a cross-account IAM role, Entra workload identity federation, GCP Workload Identity Federation. What we store is a reference to an identity you control, not a credential: there is nothing to rotate, and you revoke us by deleting the role. Static keys are supported where you need them, but a key you give us is a key we have to protect on your behalf, forever.
Publishing to your own hypervisor
Hyper-V, VMware vSphere and OpenShift Virtualization are different, and the difference is not a feature gap. Reaching them from our infrastructure would mean asking you to expose a hypervisor management plane to the internet. We will not ask for that, so we do not offer it — the product refuses to configure one of these destinations against a hosted build worker rather than letting you try.
Reaching them means a build worker inside your network instead. It dials out to us, so your firewall gets no inbound rule, and the credential it uses is sealed to that worker — we hold the public half, which means your vCenter password is not something we could hand over even if we were asked for it.
The customer-hosted worker is in development and is not something you can switch on today. If publishing to your own virtualization is what you are evaluating Primcoat for, say so when you join the waitlist — it decides the order this ships in.
Get started now.
Request access, describe the image you want, and have your first hardened image in about 15 minutes — a typical estimate, before publishing to your clouds. Primcoat builds, hardens, scans, signs, and publishes it, on the operating systems you already run.