iii.lock is a YAML lockfile in the project root. It records the resolved source pins for registry-managed workers so those workers can be replayed across environments with iii worker sync. Binary workers can include artifacts for multiple platform targets in the same lockfile.
Location
Format
Top-level fields:LockedWorker
Binary Source
Binary source entries are platform-neutral at the worker level. Theartifacts map is keyed by target triple, so one lockfile can carry macOS and Linux artifacts for the same resolved worker version. iii worker verify and iii worker sync --frozen fail only when a locked binary worker does not include an artifact for the current target.
BinaryArtifact
Image Source
Example
iii.lock
Commands
iii worker sync replays registry-managed workers recorded in iii.lock. Built-in workers, direct OCI refs, local-path workers, and sandbox rootfs/base images stay on their existing lifecycle flows and are reported as outside the v1 replay contract.Binary replay accepts trusted HTTPS iii registry artifact URLs and verifies the downloaded bytes against the lockfile SHA-256 before activation. A hash proves integrity of the bytes, not that an arbitrary host is trusted, so lockfile replay rejects untrusted artifact hosts by default.
Lockfiles that use the older single-target
target, url, and sha256 binary source fields are still read by the CLI. When the lockfile is rewritten, binary sources are serialized with the artifacts map.For a task-oriented workflow, see Reproduce Worker Installs.