Build features

A feature is a named build module. Its registry entry can declare packages for one or more distribution families and may also include build hooks, aliases, capability metadata, and guest assertions.

Adding a feature expresses intent. It does not, by itself, prove that every package was available, every hook ran, or the resulting behavior works on the target image. Recipe validation, build completion, and guest verification are separate gates.

Find the current feature set

Use the feature selector or feature-catalog API in the deployed OpenFactory release. That output is authoritative for the running version. Static lists become stale quickly, and some registry entries are hidden because they support internal fixtures or incomplete integrations.

Before choosing a feature, check:

• whether it is visible and enabled for your account;
• whether it declares packages for the recipe’s distribution family;
• whether its external sources are pinned and retrievable;
• whether it has assertions that prove the behavior you need; and
• whether it conflicts with another requested module.

Representative categories

The registry currently includes modules in categories such as:

The examples are not a compatibility matrix. A feature name can exist while a particular distribution implementation remains partial.

Feature, package, and service are different

• os.features selects registered build modules.
• os.packages asks the native package manager for specific packages.
• os.services supplies named enablement and configuration intent.

For example:

{
  "os": {
    "features": ["ssh", "firewall"],
    "packages": ["curl", "jq"],
    "services": [
      {
        "name": "ssh",
        "enabled": true,
        "config": {
          "port": 22,
          "disable_password_auth": true
        }
      }
    ]
  }
}

A valid service config can still contain a key the generator does not consume. Inspect the normalized recipe and test the generated guest.

Security and compliance labels

security-hardening installs and configures a general hardening baseline. It is not synonymous with a CIS profile. The recipe’s hardening_level is a configuration label interpreted by target-specific generators; it is not a certification or universal mapping to CIS Level 1 or Level 2.

The cis-benchmarks feature has a more specific Ubuntu 24.04 Level 1 remediation path. Other bases do not receive that same role. See CIS benchmark evidence for the exact boundary.

Likewise, enabling a feature named for GxP, HIPAA, SOC 2, PCI DSS, NIST, or DISA does not establish organizational compliance. It can add packages, configuration, and tests that contribute evidence to a separately governed assessment.

Combining features safely

1. Start with the smallest set that expresses the requested behavior.
2. Validate the recipe and inspect the normalized output for dropped or inferred fields.
3. Review the expanded package and hook plan.
4. Build once and follow its durable build ID.
5. Run feature-specific assertions in a booted guest.
6. Record failures and intentional exceptions explicitly.
7. Add another feature only after the current baseline is understood.

For the canonical JSON shape, see Recipe Schema.