OpenFactory application test results used to verify systems before fleet release

For platform teams

Linux Image Workflows for Platform Teams

Give application and infrastructure teams a reviewable path from OS requirements to versioned recipes, bootable artifacts, and scoped VM test evidence.

Discuss your platformExplore fleet readiness
Versioned recipe and build recordsChecks against the produced VMExplicit pilot and owner boundaries

Availability boundary: Self-service currently covers eligible image builds and selected VM tests. BYOC, fleet rollout, rollback, runtime verification, and regulated controls are scoped pilot work with customer-owned infrastructure and approval.

Separate image evidence from deployment ownership

OpenFactory can connect an eligible recipe, build record, artifact checksum, and the results of checks that actually ran. Customer approval, target-infrastructure validation, rollout, runtime operation, and rollback remain separate responsibilities evaluated in a pilot.

A paved path for Linux

Turn customer-reviewed bases, packages, services, and checks into versioned recipes that teams can inspect and rebuild.

Evidence with the artifact

Build records and available boot, functional, and visual test results identify the artifact and scope they cover.

Controlled change

Make image changes reviewable and rerun named checks. A rollback path is counted only after the customer tests a compatible retained artifact and data procedure.

Choose the deployment boundary

Use hosted build and VM capacity where eligible. Customer-cloud, on-premises, disconnected, and fleet operations require a scoped technical pilot.

A platform loop teams can repeat

The current product creates an artifact and scoped evidence; the surrounding control process must assign owners and approval criteria.

  1. 01

    Define the baseline

    Record the intended distribution, packages, services, identities, checks, and the reviewer who can approve the result.

  2. 02

    Build and inspect

    Create the image, boot the produced artifact as a VM, and review the exact checks, logs, failures, and omissions.

  3. 03

    Handoff with evidence

    Hand off the artifact checksum, recipe, build record, and scoped test results. Promotion and deployment happen in the customer-owned control boundary.

Choose the path that matches the constraint

Compliance and infrastructure ownership create different pilot questions. Start with the boundary and acceptance evidence your team needs to evaluate.

Compliance and controlled change

Pilot how versioned artifacts, customer approvals, scoped test evidence, runtime responsibilities, and retention would fit a regulated workflow.

Discuss compliance

Bring your own cloud fleet

Evaluate a representative artifact handoff, deployment target, rollout step, failure signal, and rollback procedure in customer-owned infrastructure.

Discuss BYOC fleet

Platform team questions

Does every workload have to run in OpenFactory's cloud?

No. Eligible builds and test VMs can run on the hosted service. Customer-cloud, on-premises, disconnected, and fleet operations are not represented as self-service; they require a scoped pilot.

What evidence stays with an image?

Current records can connect supported build inputs, recipe history, artifact identity, boot status, and test outcomes. Deployment events and runtime evidence are evaluated as pilot integrations.

Can teams begin without a fleet migration?

Yes. Start with one eligible image, define acceptance checks, inspect the built VM, and document what passed, failed, or remained untested before evaluating any fleet change.

Start with the constraint that matters

Bring one representative baseline, workload, deployment boundary, and failure criterion. The pilot can then produce a written fit, gap, and owner decision instead of an open-ended fleet promise.

Book a focused demo