But It Builds on My Machine!: Building Deterministic OCI Images With Nix
summary
Explains how Nix turns image builds into deterministic artifacts by hashing full dependency closures, sandboxing builds (no network) and storing outputs in a global store so different library versions can coexist; shows three practical paths: call Nix from a Docker multi‑stage build, replace Dockerfile with Nix and produce per‑dependency layers to improve caching, or use nix-to-docker for fine layer control; promises bitwise reproducibility, warns of storage tradeoffs and that the Nix store not FHS-compliant.
AI-written summary · about
chapters (22)
- 0:00Reproducible container builds
- 2:04Why reproducibility matters
- 4:15Docker’s reproducibility limits
- 6:00Pitfalls of Docker builds
- 7:02Challenges with best practices
- 8:47Nix for reproducibility
- 10:34Nix core principles
- 13:43Nix in Docker workflows
- 16:07Advanced Nix-to-Docker builds
- 17:11Is Nix right for your project?
- 18:14Nix adoption path
- 18:55Nix gotchas
- 20:17Q&A: Nix vs Docker
- 23:36Q&A: Transitive dependencies
- 24:20Q&A: Storage overhead
- 26:56Q&A: Updating dependencies
- 28:43Q&A: Micro VM storage
- 31:30Q&A: Nix sandboxing
- 33:16Q&A: Nix external deps
- 35:07Q&A: Sandboxing builds
- 37:16Q&A: Compiled deps handling
- 39:05Q&A: Custom Nix packages
related talks
59mReproducable environments using nix
34mNix for developers and ops
36mFunctional programming and Nix for reproducible, immutable infrastructure
06mNix: The declarative package manager
55mSane System Management with NixOS - I Do Declare!
41mCloud Native Nix!
01h 03mNixOS
15mBuilding Developer-Friendly Spaces: Nix in a Nutshell