XOAP Image Management has been rebuilt from the ground up. The previous generation wrapped an external, third-party build binary orchestrated from the XOAP cloud. The new generation is powered by a purpose-built, native .NET build engine that runs inside your own environment via the XOAP Connector.
The result: more platforms, richer provisioning, built-in security tooling, and builds that execute right next to the infrastructure they target — with the same XOAP console experience you already know.
Old vs. new at a glance #
| Previous generation | New generation | |
|---|---|---|
| Build engine | External third-party binary, launched as a subprocess | Native .NET engine — no third-party binary to install, patch, or version-pin |
| Where builds run | In the XOAP cloud | On your XOAP Connector device — inside your network, next to your hypervisors and clouds |
| Platforms | 5 — AWS, Azure, Google Cloud, vSphere, Nutanix | 15 target types — adds Proxmox, Hyper-V, XenServer, Oracle OCI, Docker, existing remote hosts, and bare-metal PXE |
| Provisioning steps | 5 provisioner types (PowerShell, Linux shell, DSC, Windows Update, Windows Restart) | 33 typed actions — package managers (apt/yum/dnf/chocolatey/winget), Ansible/Chef/Puppet/Salt, registry, firewall, systemd, file ops, validation & Pester tests, and more |
| Template format | Per-platform JSON/HCL templates | One YAML template for every platform, with inheritance (extends), snippet imports, and reusable action bundles |
| After the build | Image is stored — post-processing is your problem | 18 post-conversion steps, chainable: SBOM generation, vulnerability scanning (Trivy/Grype/Snyk), checksums, disk conversion, cross-cloud replication, uploads, notifications |
| Secrets in logs | Depends on script discipline | sensitive_variables — declared secrets are masked in every log line, by contract |
| Image versioning | Manual naming conventions | Built-in versioning with automatic retention (keep the last N, prune the rest) |
| Failure behavior | Orphaned build VMs were a known operational cost | Automatic resource cleanup on failure and cancellation, plus enforced build timeouts |
| Extensibility | Fixed plugin set, pinned to the bundled engine version | Signed plugin registry — SHA-256-verified, semver-versioned plugins, installed on demand |
Five things the new generation does that the old one couldn’t #
1. Builds run where your infrastructure lives #
The old pipeline built from the XOAP cloud — which meant firewall exceptions for on-prem hypervisors and credentials leaving your perimeter. The new engine ships inside the XOAP Connector: builds execute on a device you control, on your network. Your vSphere, Proxmox, Hyper-V, and Nutanix endpoints stay private. Your cloud credentials stay local.
2. One template, every platform — including bare metal #
Write the image definition once. The same YAML produces an Azure image, an AWS AMI, a vSphere template, a Proxmox template, a Hyper-V VHD, a Docker image — and can even provision physical machines over PXE, something the previous generation could not do. Identical hardening, identical agents, identical result, everywhere.
3. Security is a pipeline step, not an afterthought #
Every build can end with a compliance chain: generate an SPDX/CycloneDX SBOM, run a Trivy, Grype, or Snyk scan (and fail the build on severity), emit checksums and a signed manifest. What used to be a separate tooling project is now three lines of YAML.
4. Real configuration management, first-class #
Beyond scripts: native Ansible, Chef, Puppet, Salt, and Windows DSC actions, plus typed steps for package managers, Windows features and services, registry, firewall rules, and in-guest validation (including Pester test gates). Builds fail loudly on the step that broke — no more grepping one giant script log.
5. Clean failure semantics #
Cancelled a build? Timed out? Something broke mid-provision? The engine cleans up the cloud resources it created — instances, temporary firewall rules, key pairs — instead of leaving billable orphans behind. Timeouts are enforced per build, automatically.
What stays the same #
- Your console. Image management remains in the XOAP portal — dashboards, build history, live build progress.
- Your image definitions. Existing definitions are translated automatically; the migration path converts previous-generation builders and provisioners to their new-generation equivalents.
- Your pace. The new generation is enabled per workspace via a feature flag you control. Nothing changes until you flip it, and the previous generation remains available during the transition window.
By the numbers #
| Previous generation | New generation | |
|---|---|---|
| Platform targets | 5 | 15 |
| Provisioning step types | 5 | 33 |
| Post-build processing steps | 0 | 18 |
| Bare-metal support | — | PXE, first-class |
| Template reuse | copy & paste | extends / imports / bundles |
| External build dependencies | engine binary + plugins | none |
The complete capability reference #
Everything the new generation ships, by category.
Platform targets (15) #
Where your images get built.
Cloud #
| Target | What it does |
|---|---|
azure-arm | Builds Azure Managed Images and Compute Gallery images via ARM, including Trusted Launch VMs |
amazon-ebs | Builds AWS AMIs from EBS-backed EC2 instances |
googlecompute | Builds Google Compute Engine images, with IAP tunneling for private VMs |
oracle-oci | Builds Oracle Cloud Infrastructure custom images |
Virtualization #
| Target | What it does |
|---|---|
vsphere-iso | Installs a VM from ISO on VMware vSphere and captures it as a template |
vsphere-clone | Clones an existing vSphere template, customizes it, and re-captures |
proxmox-iso | Installs a VM from ISO on Proxmox VE and converts it to a template |
proxmox-clone | Clones an existing Proxmox VM/template, provisions, and re-templates |
hyperv-iso | Builds a Hyper-V VM from ISO — including fully unattended Windows installs |
hyperv-vmcx | Builds from an existing exported Hyper-V VM (VMCX) |
nutanix | Builds images on Nutanix AHV via the Prism v3 API |
xenserver | Builds VM templates on Citrix Hypervisor / XenServer |
Containers, bare metal, and existing hosts #
| Target | What it does |
|---|---|
docker | Builds container images — pull-provision-commit or straight from a Dockerfile |
pxe | Provisions physical machines over network boot (PXE) — OS install, drivers, post-install actions |
remote | Runs the full action pipeline against any existing host you can reach over SSH/WinRM — no image artifact, just configuration |
Actions (33) #
The provisioning steps you compose into a build.
Configuration management #
| Action | What it does |
|---|---|
ansible | Runs Ansible playbooks — inline or from disk, with inventory and extra-vars |
chef | Runs Chef cookbooks in solo or zero mode with a run-list |
puppet | Applies Puppet manifests with Hiera data; supports dry-run (noop) |
salt | Applies Salt states with pillar data |
windows-dsc | Applies PowerShell DSC configurations from inline code or files |
Shell and script execution #
| Action | What it does |
|---|---|
shell | Runs Linux shell commands or script files, with env vars and sudo wrapping |
powershell | Runs PowerShell inline or from script files, with optional elevation |
windows-shell | Runs classic CMD batch commands on Windows |
shell-local | Runs a command on the build host instead of the target — for glue steps |
Package management #
| Action | What it does |
|---|---|
apt | Installs, removes, and updates packages on Debian/Ubuntu, incl. custom repos |
yum | Installs packages and package groups on RHEL/CentOS 7 |
dnf | Installs packages, groups, and module streams on RHEL/Rocky 8+/Fedora |
chocolatey | Installs and upgrades Windows software via Chocolatey |
winget | Installs Windows apps by ID via the built-in Windows Package Manager |
msi-installer | Performs silent MSI installs with custom properties |
Windows administration #
| Action | What it does |
|---|---|
windows-update | Installs Windows Updates, filterable by category or KB number |
windows-feature | Adds or removes Windows features and roles, incl. management tools |
windows-service | Configures services — state, start type, recovery options |
registry | Sets or deletes registry values |
pester | Runs Pester test suites so the image is validated before capture |
windows-restart | Restarts Windows and waits until the machine is reachable again |
Linux administration #
| Action | What it does |
|---|---|
systemd | Enables, starts, stops, or masks systemd units |
firewall | Configures firewalld, iptables, or ufw rules |
linux-restart | Restarts Linux and waits until the machine is reachable again |
Cross-platform utilities #
| Action | What it does |
|---|---|
file | Uploads files or whole directories, with permissions |
git | Clones repositories onto the target |
http-request | Issues HTTP/HTTPS requests — health checks, API calls, downloads |
docker-exec | Runs commands inside a Docker container during a container build |
extract | Unpacks zip / tar / tar.gz / tar.bz2 archives |
wait | Pauses for a duration or until a condition is met |
validate | Runs any command and fails the build on a non-zero exit |
reboot | OS-agnostic restart with reconnect handling |
breakpoint | Pauses the build for interactive debugging — inspect the machine mid-build |
Connectors (3) #
How the engine talks to the machine being built.
| Connector | What it does |
|---|---|
ssh | Connects to Linux/Unix/macOS targets — password or private key, host-key pinning, keep-alives |
winrm | Connects to Windows targets — HTTP or HTTPS, basic/NTLM/Kerberos authentication |
docker | Talks straight to the local Docker socket for container builds — zero configuration |
Connector settings can be defined once and reused across targets via connector_profiles.
Post-conversions (18) #
Chainable steps that run after the image is built.
Image replication and distribution #
| Step | What it does |
|---|---|
azure-gallery-replicate | Publishes the image to an Azure Compute Gallery and replicates it across regions |
azure-local-replicate | Distributes the image to Azure Local (Stack HCI) endpoints |
aws-ami-copy | Copies the AMI to additional AWS regions, optionally re-encrypted |
aws-workspaces | Registers the image as an Amazon WorkSpaces bundle |
gcp-image-copy | Copies the image across Google Cloud projects |
Cloud storage upload #
| Step | What it does |
|---|---|
s3-upload | Uploads build artifacts to AWS S3 |
azure-blob-upload | Uploads build artifacts to Azure Blob Storage |
gcs-upload | Uploads build artifacts to Google Cloud Storage |
container-push | Pushes container images to any OCI registry — Docker Hub, GHCR, ACR, ECR, GCR |
Format conversion and packaging #
| Step | What it does |
|---|---|
convert-disk | Converts disks between VMDK, VHD, VHDX, QCOW2, and RAW |
ova-export | Exports the image as OVA/OVF with metadata — portable across hypervisors |
compress | Compresses artifacts with gzip, bzip2, xz, or zip |
manifest | Emits a JSON manifest describing exactly what was built, from what, and when |
Security and compliance #
| Step | What it does |
|---|---|
checksum | Generates MD5 / SHA-256 / SHA-512 hashes for artifact integrity |
sbom | Generates a software bill of materials in SPDX or CycloneDX format |
vulnerability-scan | Scans the image with Trivy, Grype, or Snyk — and can fail the build above a chosen severity |
Notifications #
| Step | What it does |
|---|---|
webhook | POSTs the build result as JSON to any URL — CI systems, ITSM, custom integrations |
teams-notification | Sends the build result to a Microsoft Teams channel |
The new build engine is developed by XOAP and is also available standalone as a CLI and REST API.