Objlab
← News
Linguaggi e compilatori

Show HN: Nucleus – Un runtime per container nativo per Nix con funzionalità di sicurezza avanzate

Sintesi redazionale: Ciao HN, sto sviluppando Nucleus, un runtime leggero per container Linux incentrato su due tipi di carico di lavoro: sandbox effimere per agenti di intelligenza artificiale e servizi NixOS dichiarativi. Si tratta di un unico binario Rust, senza daemon.. Fonte originale: https://github.com/sig-id/nucleus

<p>**Extremely lightweight, security-hardened, declarative container runtime for agents and production services**</p><p>Nucleus is a minimalist container runtime for Linux. It provides isolated execution environments using Linux kernel primitives without the overhead of traditional container runtimes. For production services, it is designed around a fully declarative model: Nix builds the root filesystem or image, the NixOS module declares the service, and Nucleus mounts pinned, reproducible runtime inputs.</p><p>Nucleus supports three operating modes:</p><p>**Agent mode**(default) – ephemeral, fast-startup sandboxes for AI agent workloads**Strict agent mode**– fail-closed isolation for ephemeral agent workloads without requiring production rootfs, health checks, sd_notify, or NixOS service semantics**Production mode**– strict isolation for long-running, network-bound NixOS services with declarative configuration, reproducible Nix-built root filesystems/images, egress policy enforcement, health checks, and systemd integration</p><p>Production deployments are built to be:</p><p>**Fully declarative**– service topology, runtime settings, mounted rootfs, and optional images are defined up front instead of assembled imperatively at deploy time**Nix-native**– first-class NixOS module support plus`nucleus.lib.mkRootfs`</p><p>and`nucleus.lib.mkImage`</p><p>for minimal service closures**Reproducible**– flake-based builds, pinned store paths, rootfs attestation, and image signatures keep runtime inputs stable and auditable</p><p>| Runtime | Startup Time |<br>|---|---|<br>Nucleus |<br>12 ms |<br>| Docker | ~500 ms |</p><p>The native runtime stays within run-to-run noise of bare metal, while the gVisor runtime pays a consistent ~62% tax from the Sentry&#x27;s per-syscall user-space emulation. Occasional wins over bare metal should be treated as benchmark noise rather than a guaranteed speedup.</p><p>**SELECT-only (read-heavy)**</p><p>| Environment | I/O Method | Avg TPS | Avg Latency | vs Baremetal |<br>|---|---|---|---|---|<br>| Baremetal | worker | 170,411 | 0.047 ms | baseline |<br>| Baremetal | io_uring | 174,026 | 0.046 ms | +2.1% |<br>Nucleus |<br>worker |<br>169,577 |<br>0.047 ms |<br>−0.5% |<br>Nucleus |<br>io_uring |<br>172,482 |<br>0.046 ms |<br>+1.2% |<br>| gVisor | worker | 65,683 | 0.122 ms | −61.5% |</p><p>**TPC-B (mixed read/write)**</p><p>| Environment | I/O Method | Avg TPS | Avg Latency | vs Baremetal |<br>|---|---|---|---|---|<br>| Baremetal | worker | 4,341 | 1.845 ms | baseline |<br>| Baremetal | io_uring | 4,516 | 1.772 ms | +4.0% |<br>Nucleus |<br>worker |<br>4,583 |<br>1.746 ms |<br>+5.6% |<br>Nucleus |<br>io_uring |<br>4,607 |<br>1.736 ms |<br>+6.1% |<br>| gVisor | worker | 1,655 | 4.834 ms | −61.9% |</p><p>Measured on Linux 6.18 x86_64 with PostgreSQL 18.4. All three environments run</p><p>fully unprivileged(Nucleus rootless with`--userns keep-id`</p><p>, no`sudo`</p><p>); the harness bind-mounts a host`pgdata`</p><p>and uses host networking, so it measures the steady-state cost of each isolation layer rather than image unpacking or cold start. gVisor&#x27;s Sentry does not implement`io_uring`</p><p>, so it is measured with`io_method=worker`</p><p>only. Full results:`benches/pg18_io/results/`</p><p>Run it yourself (rootless):</p><p>nix shell nixpkgs#postgresql_18 -c \ env ROOTLESS=1 SCALE=50 CLIENTS=8 DURATION=30 RUNS=3 \ bash benches/pg18_io/bench.shAdd</p><p>`GVISOR_PLATFORM=systrap`</p><p>if`/dev/kvm`</p><p>is unavailable, or`SKIP_GVISOR=1`</p><p>to measure baremetal + native only.</p><p>**Declarative by default for services**– Production deployments are defined in NixOS and TOML rather than stitched together with ad hoc runtime scripting**Deep Nix integration**– First-class NixOS module,`mkRootfs`</p><p>,`mkImage`</p><p>, and Nix store closures for minimal, locked-down service roots**Reproducible service builds**– Flake-based packaging, pinned inputs, rootfs attestation, and image signatures make runtime state auditable and repeatable**Zero-overhead isolation**– Direct use of cgroups, namespaces, pivot_root, capabilities, seccomp, and Landlock**Memory-backed filesystems**– Container disk mapped to tmpfs, pre-populated with agent context**gVisor integration**– Optional application kernel for enhanced security, including networked service mode**OCI runtime-spec subset for gVisor**– Generates OCI bundle/config data for`runsc`</p><p>, including process identity, mounts, namespaces, seccomp, hooks, and cgroup path wiring**Detached mode**– Run containers in the background as systemd transient services with`--detach`</p><p>, managed via`nucleus stop`</p><p>/`logs`</p><p>/`attach`</p><p>**Production service support**– Declarative NixOS module, egress policies, credential-broker egress, health checks, secrets mounting, sd_notify, and journald integration**Explicit workload identity**– Native and gVisor runtimes can drop to a configured`uid`</p><p>/`gid`</p><p>plus supplementary groups after privileged setup**Minimal rootfs**– Replace host bind mounts with a purpose-built Nix store closure or Nix-built image for production services**Local image snapshots**– Commit native overlay-backed containers to signed, thin image directories, then verify, inspect, and run them later**External security policies**– Per-service seccomp profiles (JSON), capability policies (TOML), and Landlock rules (TOML) with SHA-256 pinning**Seccomp profile generation**– Trace mode records syscalls, then`nucleus seccomp generate`</p><p>creates a minimal allowlist profile**Multi-container topologies**– Compose-equivalent TOML format with dependency DAG, reconciliation, and NixOS systemd integration**Integrity &amp; audit controls**– Structured audit log, machine-readable lifecycle event streams, context hashing, rootfs attestation, image signatures, seccomp deny logging, mount flag verification, and kernel lockdown assertions**Structured telemetry**– Optional OpenTelemetry export for container lifecycle tracing**Linux-native**– Runs on standard Linux and NixOS</p><p>Nucleus is **not** a drop-in Docker replacement, nor a strict subset of Docker.<br>The feature sets overlap, but each tool does things the other does not. Nucleus is<br>a hardened sandbox runtime (closer in spirit to `runc`</p><p>/`gVisor`</p><p>) that also does<br>lightweight, declarative single-host orchestration. It drops Docker&#x27;s build DSL,<br>registry, and distribution workflow in exchange for deeper isolation, policy,<br>and reproducibility. Local signed image snapshots are available, but they are<br>not Docker/OCI images.</p><p>| Capability | Docker | Nucleus |<br>|---|---|---|<br>| Root filesystem | Layered image (union mount) | tmpfs directory (agent), Nix closure (production), or overlay-backed Nix closure for snapshots |<br>| Images / Dockerfile / registry | Yes | Signed local thin snapshots and Nix-built image manifests; no Dockerfile, registry, `pull` /`push` , or OCI image spec |<br>| Persistent storage | Named volumes + storage drivers | Ephemeral tmpfs; persistence only via explicit `--volume` binds |<br>| Architecture | `dockerd` daemon + socket API |<br>Single binary, direct fork/exec; detached = systemd transient unit |<br>| Networking | CNI plugins, overlay networks | `none` / `host` / `bridge` only |<br>| Orchestration | Compose, Swarm | `nucleus compose` (single-host TOML DAG over systemd) |<br>| Default egress | Allow-all outbound | Deny-by-default; allow per CIDR/domain via namespace iptables |<br>| Filesystem ACLs | AppArmor/SELinux profiles | Landlock LSM, per-service, irreversible |<br>| gVisor | Optional add-on runtime | First-class integrated runtime with explicit network modes |<br>| Security policies | Bundled defaults | Externalized seccomp/caps/Landlock, SHA-256 pinned + trace-generated |<br>| Reproducibility | Image digests | Nix closures, rootfs attestation, image signatures, first-class NixOS module |<br>| Verification | — | TLA+ specs + model-based tests across subsystems |<br>| Default hardening | ~300 syscalls, some caps kept | All caps dropped, small seccomp allowlist, up to 8 namespaces |</p><p>If your mental model is &quot;run my Docker image instead of `docker run`</p><p>,&quot; it will<br>not fit: there is no Dockerfile, registry, pull/push lifecycle, or implicit<br>persistent state. Nucleus images are local signed snapshots or Nix-built<br>manifests over Nix rootfs closures. If your model is &quot;run untrusted or ephemeral<br>workloads with stronger, auditable isolation,&quot; that is the target.</p><p>Nucleus leverages Linux kernel isolation primitives:</p><p>**Namespaces**– PID, mount, network, UTS, IPC, user, cgroup, and optional time isolation**cgroups v2**– Resource limits (CPU, memory, PIDs, I/O)**pivot_root**– Filesystem isolation (chroot fallback available in agent mode only)**Capabilities**– All capabilities dropped by default, or configured via TOML policy file (irreversible)**seccomp**– Syscall whitelist filtering with per-service JSON profiles and trace-based generation (irreversible)**Landlock**– Path-based filesystem access control via hardcoded defaults or TOML policy file (Linux 5.13+)**gVisor**– Optional application kernel (runsc) with none, bridge handoff, and explicit gvisor-host network modes**OCI bundle generation**– Emits OCI`config.json`</p><p>plus bundle layout for gVisor, including`process.user`</p><p>, lifecycle hooks, seccomp, resource limits, and namespace mappings**Image snapshots**– Local signed manifests with optional overlay diffs rooted in attested Nix rootfs closures**PID 1 init**– Mini-init supervisor in production mode for zombie reaping and signal forwarding**In-memory secrets**– Dedicated tmpfs at`/run/secrets`</p><p>with volatile zeroing of source buffers**Mount audit**– Post-setup verification of mount flags in production mode</p><p>Container filesystem is backed by tmpfs and either populated with context files (agent mode) or mounted from a pre-built Nix rootfs closure (production mode). Snapshot workflows can mount that Nix rootfs with a writable native overlay and commit the overlay upperdir as a signed local image. That lets services run from declaratively built, reproducible filesystem inputs instead of inheriting mutable host state.</p><p>- Linux (kernel 6.x+) on<br>`x86_64`</p><p>- NixOS (first-class NixOS module support)<br>**Not supported**: macOS, Windows, BSDs, 32-bit Linux</p><p>`cargo install nucleus-container`</p><p>Or via Nix (recommended for reproducible builds and NixOS integration):</p><p>`nix run github:wiggum-cc/nucleus`</p><p>The Cargo package name is `nucleus-container`</p><p>; it installs the `nucleus`</p><p>binary. The repository itself is packaged as a Nix flake, so `nix run`</p><p>, `nix build`</p><p>, and the NixOS module all share the same pinned inputs.</p><p>**GPU passthrough**–`--gpu auto|nvidia|amd|intel|all`</p><p>binds host GPU device nodes into`/dev`</p><p>, installs a cgroup v2 device allowlist (`BPF_PROG_TYPE_CGROUP_DEVICE`</p><p>), relaxes the seccomp`ioctl`</p><p>filter for vendor driver ioctls, and bind-mounts driver support files. Explicit device selection, NVIDIA env vars, and a programmatic`gpu`</p><p>config document field are supported. See spec/gpu-passthrough.md.**Local signed image snapshots**– Native overlay-backed containers can be committed, verified, inspected, loaded, and run as thin image directories over a Nix rootfs base.**Privilege drop for services**–`--user`</p><p>,`--group`</p><p>, and`--additional-group`</p><p>now apply a real post-setup workload identity in both the native runtime and gVisor.**Ownership-aware secrets and writable paths**– Production secret staging and NixOS`createHostPath = true`</p><p>defaults now align file ownership with the configured workload user/group.**OCI bundle identity support**– Generated gVisor OCI configs now carry`process.user`</p><p>including supplementary groups, alongside namespaces, mounts, resource limits, seccomp, hooks, and`cgroupsPath`</p><p>.**Probe execution under workload identity**– Exec-based health and readiness probes now run as the configured service account instead of implicitly as root.**Systemd/NixOS service integration improvements**– The module exposes`user`</p><p>,`group`</p><p>, and`supplementaryGroups`</p><p>, and packaged Nix usage includes`gvisor`</p><p>in the flake/dev shell path.</p><p>```<br># Run agent in isolated container with pre-populated context<br>nucleus run --context ./agent-context/ -- /usr/bin/agent<br># Specify resource limits<br>nucleus run --memory 512M --cpus 2 --context ./ctx/ -- ./agent</p><p>_(testo troncato)_</p>