Host

Deprecated. The whole top-level host: block is deprecated in launch/v1 and is removed in launch/v2 (D-58). Its replacement is the host capability entry form in requires/supports. Files using the block stay valid for the whole of launch/v1 and keep their exact meaning — launchfile validate reports the deprecation and its migration, and never fails on it. Write new files with capability entries; migrate existing ones using the table below.

Declares host-level capabilities the app requires that cannot be satisfied inside a standard container. When a deployer cannot meet these constraints, it should refuse the deployment with a clear error message rather than failing at runtime.

Field	Type	Description
`docker`	`enum`	`required` -- needs Docker daemon access on the host (not Docker-in-Docker). `optional` -- enhanced when available.
`network`	`enum`	`host` -- must share the host network stack. `bridge` (default) -- standard container networking.
`filesystem`	`enum`	`read-write` -- needs persistent host filesystem access. `read-only` -- only reads from host. `none` (default) -- no host filesystem needed.
`privileged`	`boolean`	Requires elevated privileges (e.g. device access). Default `false`.

# App that orchestrates Docker containers on the host (deprecated block form)
host:
  docker: required
  network: host
  filesystem: read-write

When host.docker is required, the deployer must ensure the app runs with access to the Docker daemon socket (e.g. /var/run/docker.sock). If the deployer's execution strategy is container-based, it should either refuse or warn that Docker-in-Docker is unreliable.

Migrating off the `host:` block

Every key of the block is expressible as a host capability entry, and the two spellings are semantically identical — a provider MUST produce the same grant/refuse outcome for either (PROVIDERS.md § Host capabilities). requires carries a capability the app cannot run without; supports carries one it degrades gracefully without. A key set to its default declares no need at all, so it migrates to nothing.

Legacy key/value	Migrates to
`docker: required`	`requires: [ - host: { container_runtime: docker } ]`
`docker: optional`	`supports: [ - host: { container_runtime: docker } ]`
`network: host`	`requires: [ - host: { network: host } ]`
`network: bridge`	(default — drop the key, no entry)
`filesystem: read-write` \| `read-only`	`requires: [ - host: { filesystem: <value> } ]`
`filesystem: none`	(default — drop the key, no entry)
`privileged: true`	`requires: [ - host: { privileged: true } ]`
`privileged: false`	(default — drop the key, no entry)

The entry form also gains what the block cannot express: set_env wiring of the granted coordinates ($socket / $url / $api for container_runtime), and a single home for the app's whole dependency statement instead of two parallel mechanisms.

# The block above, migrated
requires:
  - host: { container_runtime: docker }
    set_env:
      DOCKER_HOST: $url
  - host: { network: host }
  - host: { filesystem: read-write }

How deprecations are declared

Deprecation is machine-readable, never prose-only (D-42). Every deprecated part of the format carries its metadata in the JSON Schema, in two places:

The standard JSON Schema deprecated: true keyword (draft 2020-12), which every $schema-aware editor already understands.
An x-launchfile-deprecation object carrying D-42's four semantic parts, which JSON Schema has no vocabulary for:

"x-launchfile-deprecation": {
  "deprecated_in": "launch/v1",
  "removed_in":    "launch/v2",
  "replacement":   "requires[].host.container_runtime",
  "hint":          "Replace `host: { docker: required }` with `requires: [ - host: { container_runtime: docker } ]`. …"
}

deprecated_in and removed_in are launch/vN format versions — the only version vocabulary the format has (D-17) — and removal is always at a format major (P-14). Both keys carry the same values everywhere a block and its keys are deprecated together; replacement and hint are per-key, because they differ per key.

Tooling reads this metadata and reports it. In the reference SDK, launchfile validate emits a deprecations array — one entry per deprecated field present in the file, with all four parts populated — in --json output, and a deprecated: line per finding in the human output. A deprecation never affects valid and never changes the exit code: deprecation warns, removal migrates, nothing breaks.

Host

Migrating off the host: block

How deprecations are declared

Migrating off the `host:` block