OpenFactory demonstrates that AI-driven pipelines can assemble bootable Linux ISOs from a prompt, but enterprises will insist on reproducibility, signing, and supply-chain controls before they deploy it at scale.
A ZDNet hands‑on test shows how that works in practice. A tester used OpenFactory, a pre‑alpha service from developer Erik Ziegenbald (openfactory.tech), to generate a custom KDE Plasma desktop image. The resulting ZIP contained an ISO reported as larger than 9 GB that took roughly two hours to download on the tester’s connection (no bandwidth figure was provided). The same test also surfaced runtime errors and under‑provisioned builds that required developer intervention, which shows both the power and the growing pains of automating OS image assembly with AI agents.
What OpenFactory says it does
The platform’s website describes the offering like this: “Build bootable Linux images, multi‑node labs, and fleet deployments from a prompt, Git repo, or reusable recipe. Boot and test them in VMs, apply CIS controls, deploy web apps, and record visual app tests.” Behind that claim is an AI-orchestrated pipeline made up of agents named Git Agent, Planning Agent, Config Agent, Apps Agent, Package Agent, Build Agent, Test Agent and an Orchestrator. OpenFactory accepts conversational prompts, Git recipes, or menu selections, then plans, fetches packages, assembles an image, runs tests and produces downloadable artifacts (ZIPs containing ISOs).
From prompt to ISO, the exact request the tester used
“Build a desktop distribution geared specifically for creative types that uses the KDE Plasma desktop, customized to look like macOS, and includes several tools for writing, sound recording, video editing, podcasting, streaming, image editing, and desktop publishing. Include the KDE utilities, Ollama (and the Alpaca GUI), and make sure the distribution is installable with the Calamares installer.”
The pipeline parsed that prompt, generated package lists, resolved dependencies, and assembled a bootable ISO that ran in the platform’s hosted VM environment. During the hands‑on session, Ziegenbald added an automated install‑to‑disk testing loop on Aug. 12 to validate Calamares‑based installs, a practical fix for teams that need deployable images rather than live‑USB demos.
Build behavior, performance and common failure modes
The tester saw builds that took tens of minutes to run. One status message read, “the current build has been going strong for about 30 minutes, and it’s 58% done.” At least one completed ZIP contained an ISO larger than 9 GB and required about two hours to download on the tester’s connection. Other attempts produced meager results, one returned only LibreOffice preinstalled, showing the orchestration can still misinterpret intent or fail to resolve required packages.
{“detail”:”Failed to create download package”}
That JSON error appeared during the session and required developer debugging. These failures fit a pre‑alpha product: active development, intermittent errors and rapid fixes. Ziegenbald told the tester that “it should take at least 3 more months before the service is ready for general use, ” which is a developer estimate and should be treated as tentative.
Pricing tiers (shared by the developer)
- Free: 15 ISO builds/month; 1 ISO download/month; 90 hosted VM minutes/month; 3 concurrent VMs; 2 vCPU, 4 GB RAM; 20 GB disk; 24‑hour artifact window.
- Builder, $15/month: 50 ISO builds/month; 5 hosted VM hours/month; 3 concurrent hosted VMs; 2 vCPU, 4 GB RAM; 30 GB space; 7‑day artifact retention; downloadable ISOs.
- Team, $59/seat/month: 200 ISO builds/month; 20 hosted VM hours/seat/month (pooled); 3 concurrent VMs on the first seat; 4 vCPU, 8 GB RAM; 50 GB storage; SSH, snapshots, SBOMs; 14‑day artifacts; BYOK or self‑hosted LLM ready.
- Compliance (contact sales): CycloneDX SBOM and verification evidence; GxP and CIS workflow mapping; identity requirements scoped in pilot; ServiceNow drift workflow pilot; customer‑controlled deployment pilot.
- BYOC Fleet (contact sales): customer cloud or on‑prem boundary review; bring‑your‑own compute/GPU/LLM; air‑gap readiness assessment; pilot image and validation plan; dedicated technical review.
These figures were provided to the tester by Erik Ziegenbald and reflect a pre‑alpha offering; prices, quotas and retention windows may change before general availability.
Why SBOMs, CycloneDX and provenance matter for enterprises
OpenFactory advertises SBOM output (CycloneDX) and verification evidence in its Compliance and Team tiers. For security teams, an SBOM is the baseline artifact that lists components, versions, licenses and dependency graphs. Ox.Security explains that SBOMs (CycloneDX or SPDX) are used for vulnerability triage, license checks and faster incident response.
An SBOM by itself is not enough for enterprise deployment. Operations and security teams will expect at minimum:
- cryptographic signing of artifacts and build logs,
- deterministic or reproducible builds, or a documented reproducibility report (pinned sources, fixed timestamps, deterministic package builds),
- a documented secrets‑handling policy (ephemeral creds, vault integration, audit trails and deletion guarantees),
- proof that any included LLM runtimes or model weights (e.g., Ollama or Alpaca‑family models) are handled according to license and security policies (are weights embedded in the ISO or fetched at runtime?),
- architectural options and certificates for air‑gapped or on‑prem deployments when required by compliance regimes.
Ask for the SBOM format and spec version (CycloneDX vX.Y, SPDX vX.Y), the SBOM generation method, and how SBOMs integrate with your existing SCA/CVE tooling. Also require a clear attestation process so teams can verify an ISO matches the signed artifact provided by the builder.
Where OpenFactory is useful today, and the practical asks for pilots
For developers, distro maintainers and small teams building custom images or device targets, OpenFactory’s model is freeing: iterate with a prompt or recipe instead of debugging long Packer or Ansible workflows. The tester reported a catalog of approximately 1, 356 distributions and variants and device targets that range from mainstream Debian/Ubuntu families to niche hardware like the PinePhone, which shows wide ambition.
Enterprise buyers should treat OpenFactory like any third‑party build system: experiment with the free tier, but require concrete deliverables before a production pilot. Specifically, demand:
- SBOM + version and integration plan, CycloneDX (and ideally SPDX) exports and evidence they plug into your SCA/SOC pipelines.
- Signed artifacts + verification steps, public key fingerprints, signing process, and instructions for CI verification.
- Reproducible‑build report, pinned sources, build logs, timestamps and a method to reproduce the image bit‑for‑bit or a documented “reproducibility gap.”
- Secrets handling and audit policy, how ephemeral credentials, SSH keys and BYOK materials are injected and erased; audit logs and retention policies.
- Air‑gap/BYOC architecture and SLA, documentation of on‑prem or isolated deployment readiness, expected throughput, and pilot pricing/SLAs.
My take
AI agents that orchestrate package resolution, configuration and testing lower the barrier to building niche or customized Linux images. OpenFactory’s pre‑alpha demo shows that a prompt can produce a bootable ISO and that the platform is iterating quickly, as install‑to‑disk testing was added during the test cycle. The convenience and speed are real.
But the cases where this matters most, fleets, regulated devices and enterprise images, are also the places that demand the non‑glamorous controls: signed artifacts, SBOMs that integrate with scanners, reproducible builds or verifiable attestations, robust secrets handling and clear air‑gap/BYOK workflows. If OpenFactory hardens those guardrails without slowing iteration, it will become a valuable tool for engineering and IT teams. Until then, it’s an impressive experiment that enterprises should evaluate cautiously and methodically.
Questions you might ask, and honest short answers
-
Can I create a bootable Linux ISO with a simple prompt?
Yes. The ZDNet hands‑on test used a conversational prompt to produce a bootable ISO that ran in the platform’s hosted VM environment.
-
Is the service production‑ready for enterprise fleet rollouts?
No. It’s pre‑alpha. Developer Erik Ziegenbald estimated “at least 3 more months” until general readiness, and the hands‑on test exposed bugs, intermittent failures and inconsistent package results that should be resolved before production use.
-
Does OpenFactory provide SBOMs and compliance evidence?
OpenFactory’s Team and Compliance tiers advertise SBOMs (CycloneDX) and verification evidence. That’s a good baseline, security teams should confirm the SBOM spec/version and how it plugs into existing tooling.
-
How large and slow are these images to build and download?
It depends on the image. The tester saw a build report at ~30 minutes (58% complete) and an ISO larger than 9 GB that required about two hours to download on the tester’s connection (bandwidth not provided). Including LLM runtimes or many multimedia packages will increase build time and artifact size.
-
What enterprise features exist for on‑prem or air‑gapped deployments?
OpenFactory lists BYOC Fleet and Compliance options, including air‑gap readiness assessments and customer‑controlled deployment pilots, but specifics and pricing were “contact sales.” Ask for an architecture diagram, security whitepaper and pilot terms before committing.
Actionable next step for leaders: try the free tier to validate the workflow, but require the five deliverables listed above (SBOM + version, signed artifacts, reproducible‑build report, secrets policy + audit, air‑gap/BYOK architecture and SLA) before approving any pilot that touches production fleets.