Skip to content

SANDY_RUNTIME=runsc|kata — optional stronger-boundary OCI runtime (not hyperlight) #127

Description

@rappdw

Source: POST_1.0_IDEAS.md ("Optional gVisor runtime — SANDY_RUNTIME"), reinforced by the Aug-2026 landscape pass (research/INTEGRATION-OPPORTUNITIES-2026-08.md §2). Filing to make it trackable.

What

A privileged-tier SANDY_RUNTIME=runsc|kata that appends --runtime=<value> to docker run after probing docker info for the runtime's presence (warn-and-continue if absent). Gives an opt-in stronger-than-namespaces boundary — gVisor (userspace kernel) or Kata (real lightweight VMs) — while reusing 100% of sandy's build/mount/proxy pipeline (same images, same flags).

Why NOT hyperlight

The Aug pass confirmed hyperlight isolates typed function calls in a kernel-less VM (FaaS) — no OCI image, no process/filesystem/network model, guests purpose-compiled. SANDY_RUNTIME=hyperlight is not buildable. The realistic stronger-boundary path is the OCI runtime swap (runsc/kata), which is a config flag, not an architecture. This is also the honest answer to "why not a microVM."

The gate (real, must spike before shipping)

Does gVisor's netstack break the egress proxy's DNS / SNI / CONNECT path? Unverified. Needs a soak test on a real gVisor host before this ships. Kata (real VM) is likely fine but heavier (VM boot latency).

Effort: M + the gVisor-netstack spike.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions