Recipe for installing a pinned Deno runtime as a script resource.
deno_install builds the check/run payload, pinned and idempotent, for
either destination:
- system (
privileged: true) — sudo install into a root-owned dir like
/usr/local/bin/deno, readable + executable under a hardened unit's
ProtectSystem=strict and on the default systemd PATH (a subprocess a
service starts per call). - user-home (
user: '<svc>') — install as the service user into a path
under their home (/home/<svc>/.deno/bin/deno), so a bootstrap apply
running as root still lands Deno owned by the service user, not /root (a long-running Deno
backend).
The binary is fetched from the GitHub release zip of the pinned version (no
curl | sh). The zip is not checked against a digest: its bytes are trusted as
the release URL serves them over TLS. The check is the exact version pin, so a
re-apply reinstalls only on a version bump. Warming a module cache (deno cache) is intentionally
left to the caller — it's per-consumer (entrypoint + apply-vs-deploy timing).
Recipes are imported at config eval time inside zap's sandboxed config eval
(fgro eval), which has no network, no writes, and no environment, and where the
clock and randomness throw, so this is a pure function: it only assembles
strings from its arguments. Deterministic output keeps it a reliable
content-addressed plan artifact.
The caller spreads the result into a script resource, e.g.
zap.script({id: 'deno-install', name: '...', ...deno_install({version: '2.8.2', bin_path: '/usr/local/bin/deno', privileged: true}), depends_on: ['curl', 'unzip']}).
The host needs curl + unzip (declare them as pkg deps).