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.
- Cygnus · hn · 2026-07-25 · 8 upvotes · similarity 0.52
- Drop · hn · 2026-09-22 · 189 upvotes · similarity 0.52
- Keystone · hn · 2026-02-18 · 12 upvotes · similarity 0.51
- Grsh · hn · 2026-01-14 · 50 upvotes · similarity 0.50
- Minimal container-like sandbox built from scratch in C · hn · 2025-12-07 · 5 upvotes · similarity 0.49
- Kern · hn · 2026-08-24 · 70 upvotes · similarity 0.48
- I made a dual-bootable NixBSD (NixOS and FreeBSD) image · hn · 2026-01-29 · 9 upvotes · similarity 0.47
- CambiOS · hn · 2026-06-11 · 8 upvotes · similarity 0.47
Other launches for this product
- No other launches for this product.
Same idea, different domain
Nobody's really built a dev tools tool for Sales yet.