nlewo

nix2container

Go2022–2025

nlewo / nix2container

nix2container

An archive-less dockerTools.buildImage implementation

Systems & Infrastructure DevOps & Cloud

Explore on GitHub Read Hacker News discussions

7Distinct people

16Mentions

0Explicit recommenders

945GitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

An archive-less dockerTools.buildImage implementation

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 10:49:33 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year16 dated mentions

Observed mentions: 2022-04-19 13:20:40 UTC to 2025-12-25 20:51:35 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
2022	2022-01-01 00:00:00 UTC	2023-01-01 00:00:00 UTC	3	3
2023	2023-01-01 00:00:00 UTC	2024-01-01 00:00:00 UTC	6	6
2024	2024-01-01 00:00:00 UTC	2025-01-01 00:00:00 UTC	2	2
2025	2025-01-01 00:00:00 UTC	2026-01-01 00:00:00 UTC	5	5

What Hacker News says

5 sources

lewo·Dec 25, 2025

I think this is really close to the way nix2container works (https://github.com/nlewo/nix2container). nix2container generates metadata at build time and streams the required data at runtime. At build time, it generates a JSON file describing the image metadata and the layers data location. At runtime, it consumes this JSON file to stream layer data and image configuration to a destination. This is implemented by adding a new transport to Skopeo. Thanks to this implementation, nix2container doesn't need to handle all various destrination since this is managed by Skopeo itself. Recently, we introduced a mechanism to also produce such kind of JSON file for the base image (see https://github.com/nlewo/nix2container?tab=readme-ov-file#ni...). I'm pretty sure the added (not usptreamed yet) transport could be useful in some other close contexts,

Read the rest

such as Bazel or Guix. I'm the nix2container author and i will be glad to discuss with you if you think this Skopeo transport could be useful for you! (btw, your blog post is pretty well written!)

In A faster path to container images in Bazel

pxc·Aug 23, 2025

> Many people disagree with that claim and think that TheLinuxModel is good actually. However I point that these people almost definitely make extensive use of Docker You've got the wrong audience here. Nix people are neither big fans of "the Linux model" (because Nix is founded in part on a critique of the FHS, a core part and source of major problems with "the Linux model") nor rely heavily on Docker to ship dependencies. But if by "the Linux model" you just mean not promising a stable kernel ABI, pulling an OS together from disparate open-source projects, and key libraries not promising eternal API stability, it might have some relevance to Nixers... > I also dont think that deploying a program should be much more complicated than sharing an uncompressed zip file. Docker adds a lot of crusting. Packaging images/zips/deployments should

Read the rest

be near instantaneous. Your sense of "packaging" conflates two different things. One aspect of packaging is specifying dependencies and how software gets built in the first place in a very general way. This is the hard part of packaging for cohesive software distributions such as have package managers. (This is generally not really done on platforms like Windows, at least not in a unified or easily interrogable format.) This is what an RPM spec does, what the definition of a Nix package does, etc. The other part is getting built artifacts, in whatever format you have them, into a deployable format. I would call this something like "packing" (like packing an archive) rather than "packaging" (which involves writing some kind of code specifying dependencies and build steps). If you've done the first step well— by, for instance, writing and building a Nix package— the second step is indeed trivial and "damn near instantaneous". This is true whether you're deploying with `nix-copy-closure`/`nix copy`, which literally just copy files[1][2], or creating a Docker image, where you can just stream the same files to an archive in seconds[3]. And the same packaging model which enables hermetic deployments, like Docker but without requiring the use of containers at all, does still allow keeping only a single copy of common dependencies and patching them in place.[4] -- 1: https://nix.dev/manual/nix/2.30/command-ref/nix-copy-closure... 2: https://nix.dev/manual/nix/2.30/command-ref/new-cli/nix3-cop... 3: https://github.com/nlewo/nix2container 4: https://guix.gnu.org/blog/2020/grafts-continued/

In Closing the Nix gap: From environments to packaged applications for rust

lewo·Jun 7, 2025

> With no way of splitting up the Nix dependencies into separate layers nix2container [1] is actually able to do that: you can explicitly build layers containing a subset of the dependencies required by your image. An example is provided in this section: https://github.com/nlewo/nix2container?tab=readme-ov-file#is... For instance, if your images use bash, you can explicitly create a layer containing the bash closure. This layer can then be used across all your images and is only rebuild and repushed if this bash closure is modified. > > pull in dependencies often results in massive image sizes with a single /nix/store layer This is the case for the basic nixpkgs.dockerTools.buildImage function but this is not true with nix2container, nor with nixpkgs.dockerTools.streamLayeredImage. Instead of writing the layers in the Nix store, these too

Read the rest

ls build a script to actually push the image by using existing store paths (which are Nix runtime dependencies of this script). Regarding the nix2container implementation, it builds a JSON file describing the Nix store paths for all layers and uses Skopeo to push the image (to a Docker deamon, a registry, podman, ...), by consuming this JSON file. (disclaimer: i'm the nix2container author) [1] https://github.com/nlewo/nix2container

In Why We're Moving on from Nix

mikepurvis·Jun 3, 2025

The Nix world is not a huge place. I was largely self taught for about a year and then heavily influenced by working with Numtide, so a bunch of my tools experience comes from them. And I actually landed a minor contribution to nix2container, which was nice to do: https://github.com/nlewo/nix2container/pull/77

In How I like to install NixOS (declaratively)

mikepurvis·Mar 27, 2025

I mean if we're going full pie in the sky, fully declarative containers exist today: https://github.com/nlewo/nix2container#nix2container Dagger looks nifty, but it's too bad that it's still basically an imperative "start from thing, do stuff to it, publish" kind of model, rather than just expressing a desired end state and letting an underlying engine find its way there.

In Dagger: A shell for the container age