nginx BYOI template

CubeSandbox’s cubesandbox-base-nginx example is the smallest useful “bring your own image” proof: boot a sandbox, run a listener on port 80 inside it, and reach that listener through the same <port>-<id>.<domain> shape user web apps use.

What ships

The receipt is benchmarks/rigs/nginx-byoi-smoke.sh. It builds a FreeBSD-native jail template named cubesandbox-base-nginx by cloning zroot/jails/_template@base-dns-20260422, installing www/nginx with pkg in a temporary VNET setup jail, writing a marker index.html, and snapshotting zroot/jails/cubesandbox-base-nginx-template@base.

The same rig then:

  1. Reloads the gateway template registry.
  2. Creates a sandbox with templateID=cubesandbox-base-nginx.
  3. Starts /usr/local/sbin/nginx inside the jail.
  4. Curls http://<sandboxIP>/ directly.
  5. Builds tools/coppiceproxy and curls the CubeProxy-style route with Host: 80-<short>.coppice.lan.

Latest receipt path: benchmarks/results/nginx-byoi/latest.txt.

Run it on honor:

mise run nginx-byoi:smoke-honor

Or directly from the repo checkout on honor:

sudo sh benchmarks/rigs/nginx-byoi-smoke.sh

Why this matters

Coppice already had the substrate pieces separately: VNET jails provide per-sandbox IPs, and tools/coppiceproxy implements the <port>-<id>.<domain> host-header split for arbitrary in-jail listeners. This rig ties them together as a single demo-shaped artifact, which is what the Cube example actually exercises.

This is intentionally a FreeBSD package template, not a Linux OCI image. The generic OCI import path is covered in OCI templates; the nginx demo is about “can a user bring a template with a web listener and reach it through routing?” The answer is now measured.