fabro/lib
Bryan Helmkamp 29e7e77c75
Let the Daytona provider cache images as snapshots instead of fabro
Fabro named Daytona snapshots by an HMAC of the image or Dockerfile, the
resources, and the API key, ensured them through the driver's snapshot
service before every create, and threaded that work through a create
plan so the sandbox could learn the snapshot it came from. The driver's
Daytona provider now does this inside create: an image or Dockerfile
spec is built once into a snapshot named by its inputs under the API key
and reused for the same inputs, with the build reported through the
create's events. Fabro's overlay only fixes the working directory,
names the run, sets the timers, and falls back to Daytona's default
snapshot; the sandbox reads the snapshot it came from off the driver's
status after the create. The snapshot identity module, the ensure step,
the create plan, and fabro-sandbox's hashing dependencies go. Snapshot
names change from fabro-<uuid> to the driver's sandbox-driver-<hex>, so
existing snapshots are rebuilt once.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2026-09-11 13:11:16 -06:00
..
apps Put the driver's sandbox status on the API instead of a projection 2026-09-11 13:07:00 -06:00
components Let the Daytona provider cache images as snapshots instead of fabro 2026-09-11 13:11:16 -06:00
foundation Put the driver's sandbox status on the API instead of a projection 2026-09-11 13:07:00 -06:00
packages/fabro-api-client Put the driver's sandbox status on the API instead of a projection 2026-09-11 13:07:00 -06:00