Build Custom Linux ISO's and Deployments

Build, test, and deploy custom Linux ISOs with OpenFactory. Create VMs, run compliance tests, manage recipes.

Security Scan

The SKILL.md describes exactly the build-and-deploy functionality advertised, but the registry metadata omits the API-key/session-token requirement and the instructions will send user-supplied recipes (potentially containing passwords/keys) to an external service—review credential handling before use.

Purpose & Capability

The name, description, and toolset in SKILL.md are coherent: they describe building ISOs, running tests, and managing VMs. However, SKILL.md requires authenticating to https://build.openfactory.tech (API key or session token), while the registry metadata declares no required environment variables or primary credential—this mismatch is unexpected and should be clarified.

Instruction Scope

Instructions stay within the stated purpose (API calls to the OpenFactory MCP, creating builds, running tests, fetching ISOs, VNC console URLs, screenshots). They do NOT instruct reading local files or arbitrary system paths. However, recipes include fields for user passwords and other sensitive configuration; those values will be transmitted to the external service and may be stored there. The SKILL.md also instructs agents to persist and reuse a session_token between calls, which implies the agent will hold session state across requests.

Install Mechanism

Instruction-only skill with no install spec and no code files — lowest install risk. The skill will cause network calls at runtime but writes nothing to disk itself.

Credentials

SKILL.md requires authentication (API key or session_token) but the skill metadata lists no required env vars or primary credential. That's an inconsistency: a user will need to supply credentials for the endpoint even though the registry doesn't declare them. Also, the recipe schema encourages embedding credentials (password fields) which is legitimate for provisioning but increases risk if users include secrets or private keys without safeguards.

Persistence & Privilege

always is false and there is no indication the skill modifies other skills or agent-wide settings. The instruction to persist session_token is normal for remote sessions, but combined with the credential omission above it merits caution.

What to consider before installing

This skill appears to implement the advertised OpenFactory workflows, but before installing: - Confirm how you will supply credentials: the SKILL.md requires an API key or session token, yet the skill metadata doesn't declare required env vars—ask the publisher how credentials are expected to be provided and stored. - Never include secrets (passwords, private SSH keys, API tokens) directly in recipes unless you understand how the OpenFactory service stores and protects them; prefer ephemeral, least-privilege keys or secret injection mechanisms. - Ask the maintainer or vendor for a privacy/data-retention statement: where are ISOs, screenshots, and recipe contents stored, for how long, and who can access them? - If possible, test with non-sensitive example recipes and a scoped API key to confirm behavior before uploading production data. If the publisher cannot clarify credential handling and storage, treat the skill as higher risk.

OpenFactory Skill

Build custom Linux ISOs, deploy VMs, run compliance tests, and manage infrastructure — all through natural language.

Connection

OpenFactory exposes an MCP (Model Context Protocol) server over SSE.

Endpoint: https://build.openfactory.tech/api/mcp/sse

Authentication (pick one):

• API Key (recommended): Generate at the OpenFactory console under Settings > MCP Keys. Pass as api_key parameter on every tool call, or as Authorization: Bearer of_mcp_<key> HTTP header.
• Session Token: The first tool call returns a session_token in its response. Pass it to all subsequent calls for session continuity.

Session token is critical — cloud MCP clients rotate IPs between requests. Without passing session_token back, each call looks like a new anonymous user.

Tools

Builds

Tool	What it does
list_builds(status_filter?, limit?)	List your builds. Filter by queued, building, built, failed, completed.
get_build(build_id)	Get full build details including recipe, ISO path, test results.
get_build_status(build_id)	Get current status, stage, and progress percentage.
create_build(recipe)	Create a new build from a recipe (see Recipe Schema below).
retry_build(build_id)	Retry a failed build with the same recipe.
get_iso_download_url(build_id)	Get a download URL for the completed ISO.
deploy_from_git(repo_url, base_image?, branch?)	Build an ISO that auto-deploys a git repo as a service.

Recipes

Tool	What it does
list_recipes(category?, search?)	Browse pre-built recipe templates. Categories: healthcare, industrial, education, municipal, research, ai-development.
list_recipe_categories()	List all available categories with descriptions.
get_recipe(recipe_id)	Get full recipe details.
validate_recipe(recipe)	Validate a recipe without starting a build.
create_recipe_from_template(template_id, name, modifications)	Fork a template and customize it.

Tests

Tool	What it does
run_tests(build_id, tests?, memory_mb?, vcpus?, timeout_seconds?, keep_environment?)	Spin up a VM from the ISO and run tests. Leave tests empty for defaults (boot, login, packages, network + feature tests).
get_test_results(run_id)	Get test results: passed/failed assertions, screenshots, VM info.
list_test_runs(build_id?, limit?)	List test runs, optionally filtered by build.
stop_test_run(run_id)	Stop a running test and clean up VMs.

VMs

Tool	What it does
list_vms(build_id?)	List running VMs, optionally filtered by build.
create_vm(build_id, name?, memory_mb?, vcpus?)	Create and boot a VM from a built ISO.
start_vm(vm_name)	Start a stopped VM.
stop_vm(vm_name, force?)	Stop a VM. force=true for immediate power-off.
delete_vm(vm_name)	Delete a VM and its disk.
screenshot_vm(vm_name)	Capture a PNG screenshot of the VM display.
get_vm_console_url(vm_name)	Get a VNC console URL for browser access.

Recipe Schema

{
  "name": "My Custom Server",
  "base_image": "ubuntu-24.04",
  "description": "What this variant is for",
  "features": ["ssh", "docker", "monitoring"],
  "packages": ["curl", "htop", "vim"],
  "users": [
    {"username": "admin", "password": "changeme", "groups": ["sudo"]}
  ],
  "services": [
    {"name": "ssh", "config": {"port": 22}}
  ],
  "security": {"hardening_level": "standard"},
  "hardware": {"min_memory_gb": 4, "min_storage_gb": 32},
  "networking": {
    "dns_servers": ["8.8.8.8", "1.1.1.1"]
  }
}

Supported base images: debian-bookworm, debian-trixie, ubuntu-24.04, fedora-40, fedora-43, opensuse-tumbleweed, elster-os

Common features: ssh, docker, desktop, development-tools, python, nodejs, monitoring, security-hardening, audit-logging, gxp, hipaa, ollama, claude-code, openclaw, nspawn-containers, agent-containers

Workflows

Build a custom Linux ISO

1. create_build(recipe)          → returns build_id
2. get_build_status(build_id)    → poll until status is "built"
3. run_tests(build_id)           → returns run_id
4. get_test_results(run_id)      → check passed/failed
5. get_iso_download_url(build_id) → download the ISO

Deploy a git repo as a service

1. deploy_from_git("https://github.com/user/app.git", base_image="ubuntu-24.04")
   → builds ISO with app auto-deployed at boot
2. get_build_status(build_id) → poll until built
3. create_vm(build_id)        → boot a VM running your app

Start from a template

1. list_recipe_categories()
2. list_recipes(category="healthcare")
3. create_recipe_from_template("gxp-medtech-station", "My MedTech", {
     "add_features": ["monitoring"],
     "add_packages": ["prometheus-node-exporter"]
   })
4. create_build(modified_recipe)

Test a build with compliance checks

1. run_tests(build_id, tests=["boot", "login", "network"], keep_environment=true)
2. get_test_results(run_id)
3. screenshot_vm(vm_name)  → visually verify the desktop

Error Handling

• Build failed: Use retry_build(build_id) or check the recipe for issues with validate_recipe(recipe).
• Test failed: Use get_test_results(run_id) to see which assertions failed and why.
• VM won't start: Check that the build completed successfully with get_build_status(build_id).

Rate Limits

• Builds: 1 concurrent per user (queued if busy)
• VMs: Up to 10 per user
• Tests: 1 concurrent per build
• API calls: No hard limit, be reasonable

Examples

"Build me an Ubuntu server with Docker and SSH"

{
  "name": "Docker Server",
  "base_image": "ubuntu-24.04",
  "features": ["ssh", "docker"],
  "users": [{"username": "admin", "password": "admin", "groups": ["sudo", "docker"]}]
}

"Create a Fedora desktop with AI tools"

{
  "name": "AI Workstation",
  "base_image": "fedora-43",
  "features": ["desktop", "ssh", "python", "ollama", "claude-code"],
  "hardware": {"min_memory_gb": 16, "min_storage_gb": 64}
}

"Build a GxP-compliant medical device image"

{
  "name": "MedTech Station",
  "base_image": "debian-bookworm",
  "features": ["ssh", "desktop", "gxp", "hipaa", "audit-logging", "security-hardening"],
  "security": {"hardening_level": "strict"}
}