Skip to content

Browser-flavored sandbox image with in-image session tooling - #241

Open
czpython wants to merge 1 commit into
mainfrom
browser-image
Open

Browser-flavored sandbox image with in-image session tooling#241
czpython wants to merge 1 commit into
mainfrom
browser-image

Conversation

@czpython

Copy link
Copy Markdown
Owner

What

First phase of browser sessions as a druks primitive: the sandbox image gains a browser flavor and the session tooling that keeps druks core blind to browser-state formats.

  • Dockerfile: named slim/browser stages. The browser stage adds chromium (via pinned playwright, browsers under /ms-playwright), a pinned checksum-verified pinchtab binary, fonts, Xvfb, and x11vnc. Everything slim has stays present — harnesses run in browser sandboxes too. Untargeted local builds keep producing slim via a final default alias stage.
  • entrypoint: the browser flavor starts Xvfb (:99) and x11vnc bound to 127.0.0.1:5900 with a 0600 password file generated at boot, and fails the boot loudly if either doesn't come up. Slim starts neither. VNC is loopback-only; SSH stays the only ingress.
  • session-launch / session-export: image-owned scripts that interpret session formats so druks core never does. Launch materializes a profile tarball or applies a storage_state JSON to a persistent context (raw Chromium can't consume storage_state) and exposes loopback CDP for playwright and pinchtab alike; export closes the browser first (never tars a live Chrome), archives the profile without caches, validates the archive, and writes tar + meta to /work/session/out/. Both scripts are self-contained under SSH invocation, which carries none of the image ENV.
  • sandbox client: browser=True on ephemeral/acquire/provision resolves the configured image to its browser tag (an explicit image_override still wins). Browser hosts always name their image explicitly, so they bypass the default-image warm pool.
  • publish workflow: builds and pushes both flavors — existing tags for slim, browser/browser-sha-*/browser-<tag> for the browser target.

Testing

  • Unit tests cover browser-tag resolution (default, untagged, tagged, registry-with-port, digest-pinned) and browser=True flowing into create_host(image=...); they run in CI (local runs are blocked by the shared-DB fixture).
  • ruff, ruff format, pyright, bash -n, node --check all clean.
  • Image boot, VNC handshake, both session round trips, and the harness-in-browser-sandbox check are CI/manual docker verification once the image publishes.

The sandbox image grows a browser stage on top of slim: chromium via
playwright (pinned), pinchtab (pinned, checksum-verified), fonts, Xvfb
and loopback-only x11vnc with a boot-generated password file. The
entrypoint starts the display stack only in the browser flavor; slim
boots unchanged, and untargeted local builds keep producing slim.
Two image-owned scripts keep druks core format-blind: session-launch
materializes either session format (profile tarball unpacked, or
storage_state applied to a persistent context) and exposes loopback
CDP; session-export closes the browser first, then archives the
profile without caches and validates the result into /work/session/out.
Both are self-contained under SSH invocation, which carries none of the
image ENV.
The sandbox client gains browser=True on its entry points, resolving
the configured image to its browser tag (explicit override still wins)
so browser hosts name their image explicitly and bypass the
default-image warm pool. The publish workflow pushes both flavors.
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant

@czpython