Manifest Reference

Manifest Reference

Every key the Windows parser reads, with its exact casing. The surface is small: two top-level keys and four required per-item keys, plus five optional ones. Keys not listed here are parsed into the document and never looked at. For what a manifest is and how it is fetched, see Manifests.

Top-level keys

Key	Type	Required	Default	Summary
setupassistant	Array of items	No	none	Phase 1. Processed first
userland	Array of items	No	none	Phase 2. Processed second

setupassistant

• Type: Array of item objects
• Default: none
• Required: No

The first phase. Its items are processed before any userland item. If the key is absent the phase is recorded as Skipped in the registry status and the run continues. An empty array is a present phase with nothing in it, and is recorded as Completed.

userland

• Type: Array of item objects
• Default: none
• Required: No

The second phase, processed immediately after setupassistant finishes, in the same process. Absent behaves the same way as for setupassistant. Note that "userland" here is an ordering label, not a security context — see Stages.

Item keys

Key	Type	Required	Default	Summary
name	String	Yes	none	Display name, used in logs, the dialog and ordering
url	String	Yes	none	Download source
file	String	Yes	none	Filename to write into the cache directory
type	String	Yes	none	msi, exe, ps1, powershell, nupkg or pkg
arguments	Array of strings	No	empty	Extra arguments passed to the installer
condition	String	No	none	Architecture gate; substring match only
target	String	No	/	sbin-installer --target value
expectedPublisher	String	No	falls back to config	Required signer, msi and exe only
allowUnsigned	Boolean	No	falls back to config	Permit an untrusted signature, msi and exe only
hash	String	No	none	No effect. No hash verification exists
displayname	String	No	none	No effect. The code uses name
packageid	String	No	none	No effect. Its only reader is unreachable

name

• Type: String
• Default: none
• Required: Yes

The display name. It appears in every log line about the item, in the progress dialog list, and in the Failed to install package {name} error. It is read with a hard property lookup, so an item without it throws — and because the dialog pre-populates its list from every entry in both phases before any install starts, one entry missing name aborts the whole run before the first package is downloaded.

name also affects ordering and retry policy. A ps1 item whose name contains any of cleanup, clean, wipe, remove, delete, purge, nuclear or maintenance is moved to the end of its phase. An msi item whose name contains System Binary Installer or sbin-installer gets the more aggressive retry policy described in Retries and Timeouts. Both matches are case-insensitive substrings, so name your items with that in mind.

url

• Type: String
• Default: none
• Required: Yes

Where to download the file from. Each item is fetched fresh on every run; any previously cached copy of file is deleted first. A non-success HTTP status fails the item with Download failed: {StatusCode}.

The configured Authorization header is attached to this request only when the URL's host matches the manifest URL's host. See Manifests.

file

• Type: String
• Default: none
• Required: Yes

The filename to write inside C:\ProgramData\ManagedBootstrap\cache. This is the path handed to the installer, so its extension should match type. It is deleted after a successful install and kept after a failed one, which is why a non-empty cache directory means something failed.

Use a distinct file per item. Two items sharing one filename will overwrite each other.

type

• Type: String
• Default: none
• Required: Yes

How to install the downloaded file. Matched case-insensitively against powershell, ps1, msi, exe, nupkg and pkg. Anything else fails the item with Unsupported package type: {type}. Supported types are: msi, exe, ps1, nupkg, pkg.

type is also the primary ordering key within a phase. Full behaviour per type, including which fields apply and how success is judged, is on Item Types.

arguments

• Type: Array of strings
• Default: empty
• Required: No

Extra arguments, appended after the arguments the tool builds itself. Elements that are not strings are skipped, and a value that is not an array is ignored entirely rather than being an error.

The list is joined with single spaces into one command line, so an element containing spaces is not quoted for you. Where the arguments land per type is on Item Types.

condition

• Type: String
• Default: none
• Required: No

An architecture gate, not an expression language. Only two substrings are recognised, architecture_x64 and architecture_arm64, and any other content is ignored. See Conditions and Skipping for the exact test and for what admins do when they need real conditions.

target

• Type: String
• Default: /
• Required: No

Passed straight through as sbin-installer's --target value. It is read only on the code paths that shell out to sbin-installer, so it is meaningful for pkg, for nupkg when sbin-installer is present, and for a Cimian-built msi routed to sbin-installer. It has no effect on msiexec, exe, ps1 or the Chocolatey fallback. An empty or null value leaves the default in place.

expectedPublisher

• Type: String
• Default: falls back to the ExpectedPublisher setting
• Required: No

Per-item override of the required signer. The value is compared case-insensitively as a substring against the signing certificate's CN, falling back to the whole subject when no CN can be extracted. A mismatch is always fatal for the item and allowUnsigned does not override it.

Only consulted for type msi and exe, and only when signature verification is enabled. See Security and Package Verification.

allowUnsigned

• Type: Boolean
• Default: falls back to the AllowUnsigned setting
• Required: No

Per-item override permitting an installer whose Authenticode signature does not verify. The item still logs the failure and the reason. It does not permit a publisher mismatch. Like expectedPublisher, it applies only to msi and exe. Only literal true/false are read; a string "true" is ignored and the configured value stands.

hash

• Type: String
• Default: none
• Required: No

Accepted by the parser and never read. There is no hash verification anywhere in this build, so a hash value gives you nothing — including the "hash": "sha256" entries in the shipped examples/bootstrapmate.json. The macOS build does require and check hash; this one does not. Rely on HTTPS and on the Authenticode gate for msi and exe instead.

displayname

• Type: String
• Default: none
• Required: No

Present in the shipped example manifest and never read. name is the field that is displayed. Setting displayname instead of name produces an item that throws.

packageid

• Type: String
• Default: none
• Required: No

Read by one function that nothing calls. It has no effect on installation, detection or skipping. There is no already-installed check in this build.

Keys from the macOS manifest that this build ignores

The two implementations share the manifest vocabulary but not the schema. A manifest written for macOS parses here, and these keys are silently ignored: preflight (the whole stage), retries, retrywait, skipIf, donotwait, version, followRedirects and expectedTeamID. The macOS build in turn has no condition, target, arguments or expectedPublisher, and its type values are package, rootscript and userscript rather than the five here. Compare https://github.com/bootstrapmate/bootstrapmate-macintosh/wiki/Manifest-Reference before sharing one document between platforms.

See also

• Manifests
• Item Types
• Conditions and Skipping
• Example Manifests
• Security and Package Verification