Nicheloom

Market intelligence for builders — see what's gaining traction before it's crowded.

Nucleus

A security-hardened, Nix-native container runtime

Details

External ID
48469039
Source
HN
Company
—
Product
Nucleus
Website domain
github.com
Launched
June 9, 2026
Cohort
—
Upvotes
40
Upvotes percentile
0.8230874316939891
Tags
—
Fetched at
Sept. 7, 2026, 9:26 p.m.
Updated at
Sept. 7, 2026, 9:26 p.m.

Description

Hi HN, I've been building Nucleus, a lightweight Linux container runtime focused on two workloads: ephemeral AI-agent sandboxes and declarative NixOS services. It's a single Rust binary, no daemon.It is not a Docker replacement and not a strict subset of Docker either. I dropped the entire image-and-distribution half (no Dockerfile, no layers, no registry, no pull/push, no persistent storage layer) in exchange for going deeper on isolation and reproducibility. The rootfs is either a directory copied into tmpfs (agent mode) or a Nix-built closure mounted read-only (production mode). If your mental model is "run my image instead of docker run," this won't fit. If it's "run untrusted or ephemeral workloads with stronger, auditable isolation on a single host," that's the target.Things that I think are interesting: - Defense-in-depth defaults. All capabilities dropped, ~100-syscall seccomp allowlist (vs Docker's ~300), up to 8 namespaces including time/cgroup, Landlock LSM path ACLs per service. - Deny-by-default egress. Outbound traffic is denied unless you allow specific CIDRs or DNS-resolved domains. Enforced with namespace-local iptables rules. - Externalized, hash-pinned security policies. seccomp (JSON), capabilities (TOML), and Landlock (TOML) live as separate SHA-256-verified files, decoupled from the rootfs build. There's a nucleus seccomp generate that records syscalls in trace mode and emits a minimal profile. - gVisor as a first-class integrated runtime, not an add-on. Explicit network modes including a gvisor-host mode that's intentionally separate from native host networking. - Nix-native production path. nucleus.lib.mkRootfs builds locked-down closures; rootfs attestation verifies a per-file SHA-256 manifest at startup; first-class NixOS module. - Formal verification. TLA+ specs for the isolation/resource/filesystem/security/gVisor subsystems, checked with Apalache, plus property-based tests that drive the Rust implementation against the specs. Honest tradeoffs: - Linux x86_64 only. No macOS/Windows/BSD, no plans. - No CNI, no overlay networks, no cluster orchestration. nucleus compose is a single-host TOML DAG over systemd, not Swarm/K8s. - Ephemeral-by-default storage. Persistence is opt-in via explicit --volume binds. - Agent mode applies several mechanisms best-effort by design (warn-and-continue on seccomp/Landlock failure). For fail-closed isolation on ephemeral workloads use --service-mode strict-agent; for long-running services use production mode.Cold-start is ~12ms in the native runtime. Postgres 18 pgbench numbers under Nucleus are within noise of bare metal in our harness (full results in benches/).

Enrichment

Theme
self-hosted infrastructure and security tools
Vertical
Horizontal
Function
Dev tools
Audience
Developer
AI stance
Not AI
Project type
Hobby / open-source project
Normalized one-liner
security-hardened nix container runtime
Manually corrected
False

Could you build this?

No Building a custom Linux container runtime requires low-level kernel systems programming (namespaces, cgroups v2, seccomp, landlock, pivot_root) and Nix store architecture knowledge.

What it would actually take: Nucleus requires deep systems programming in Rust interfacing directly with Linux kernel APIs via `libc`/`nix` crates to configure user/mount/PID namespaces, apply seccomp BPF filters, and manage cgroups v2. The system must natively parse and resolve Nix store closure paths without Docker layer overhead and safely orchestrate sandboxed processes without a daemon. Expertise in Linux OS internals, container security primitives, and NixOS declarative packaging is mandatory.

Discussion

13 comments analyzed.

Competitors mentioned: systemd-nspawn, gVisor, Docker, Podman, VSCode devcontainers

Concerns raised: Docker support is missing/deal-breaker, MacOS not supported (no seccomp), Podman and SELinux compatibility issues, Podman Compose doesn't work with Flatpak Zed, Unclear threat model for rootfs attestation

Feature requests: Linux aarch64 support, MacOS support, VSCode devcontainers open sourced, Better Podman/SELinux integration

Competitors

Other products that read as similar to this one — 350 launches clear the similarity bar, closest 8 shown.

Attention rank: #83 of 351 (itself plus its competitors, highest first — normalized so YC and Product Hunt are compared fairly).

Launched 220 days after the earliest competitor.

Other launches for this product

Same idea, different domain

Nobody's really built a dev tools tool for Sales yet.