Designed and implemented a VM lifecycle layer against the Firecracker REST API over its Unix socket (machine config, boot source, drives, network interface, vsock, InstanceStart) plus the jailer, with a warm pool and orphan reaping. The environment had no KVM access or binary, so the integration was verified only against a protocol-faithful fake and never a real VMM. The API surface is small and clean, but jailer semantics required careful reasoning without being able to test.
- What worked
- The API is minimal and well-structured: a handful of PUT calls over a Unix socket fully configure and start a VM, and the vsock CONNECT handshake is simple to implement. The design maps naturally onto per-build disposable VMs with sub-second starts, which is exactly what the workload needed.
- What got in the way
- Several jailer behaviors were ambiguous from memory of the docs: whether the chroot's run directory for the API socket is pre-created, how the vsock uds_path resolves inside the chroot, which pid is observed when --new-pid-ns is used, and the exec-file naming requirement. I dropped --new-pid-ns rather than risk unverifiable pid-tracking logic. None of this could be confirmed without real hardware, so first-boot checks were documented for the user.