Nixpacks 2.0

[coffee-cup]

Hello all 👋

Nixpacks has seen a lot of changes since it was first introduced at Railway just over a year ago. We have an in-progress blog post on the history and motivation behind Nixpacks, but in this discussion, I would like to talk about current pain points and the future direction of Nixpacks. Please comment with anything you would like to see added.

Goals

The main goals of Nixpacks have remained the same since the start.

• Zero-config: Be a zero-config way of creating an OCI-compliant image from source code for the happy path. This means having intuitive defaults and inferring as much as possible from the code.
• Reproducible: Builds should be as reproducible as possible such that the same version of Nixpacks and the same source code will always produce the same image.
• Easily configurable: If our defaults don't work for your use case, it should be straightforward and simple to configure just the thing you need.

While I think the latest version of Nixpacks does a decent job at hitting these goals. I think there is a lot of room for improvement.

Current pain points

• The Nix archive version is pinned to an older version and updating it risks breaking existing builds. This is mostly a Railway deployment problem and we are working on a solution. But it will still be an issue for other platforms that use Nixpacks. If an app relies on the default Node version being 16 and then the default suddenly because 18 and their app breaks, that is a frustrating experience.
• Providers have to live in this repo, which puts the maintenance burden on Nixpacks. For popular language providers like Node or Python, that is okay. But for niche languages, it is not ideal. We want Nixpacks to support as many languages as possible, but we also can't maintain the provider for 100s of languages ourselves (especially with our small team)
• The reason why a build plan is the way it is can be confusing. We need better logging
• Configuration for providers needs to happen through environment variables. Having this as an option is okay. Having it as the only option is no good.
• Build reproducibility can break with a Nixpacks update. Again, this is mostly a Railway problem. But updating Nixpacks shouldn't break your app that has been building perfectly

Future direction

• Support for external providers: Language support and providers should not have to all live in this repo. I would even go as far to say that no providers should live in this repo. Nixpacks core should simply load and run providers as wasm modules. This could also lead to a provider marketplace. Obviously, this has its own challenges (see External providers plugin #876 (comment))
• Specifying exact versions of dependencies: Nix works great for depenedencies. However, for most packages, you can only specify the latest major version of any dependency (e.g. Node 18.x.x instead of Node 18.2.1). Supporting exact package versions is something we would really like to add. We have very briefly explored being able to get the Nix archive version for a specific package and version and it seems promising.
• First-class caching: Users of Nixpacks currently have 2 options for caching. The docker layer cache and the Buildkit mount paths. However, both of these are not very configurable and can be annoying to work with. Especially the fact that the result of mount caches do not appear in the final image. We would like to have a lot more control over the caching and possibly not rely on Docker as heavily for this, which would also make distributed caching much easier/possible. This also opens up the question of moving away from Docker entirely (although we likely won't).
• Clearer configuration format: The way that build plans and configuration work currently is actually pretty nice. A nixpacks.toml/json file is just a build plan. This ensures that all aspects of the plan can be configured in code. The merging system means that you can very easily add commands to the auto-generated ones (see goal no. 3). However, parts of the configuration/plan format is confusing (e.g. phases). I would like to revisit the plan format and improve it with what we have learned.
• Environment variable-less configuration: All config for a provider should also be codifiable in the nixpacks config file. Right now you have to use an environment variable, which is far from ideal. Providers should be able to expose a configuration schema that is type checked against. This would also allow us to add editor support Nixpacks language providers, which would be amazing
• Better Nix support: The fact that Nixpacks does not support Nix projects out of the box is frankly embarassing. Now the main goal with Nixpacks has always been to hide away the complexity of Nix from the end user. You shouldn't have to understand how anything about Nix works to use and benefit from Nixpacks. However, if you are familiar, you should be able to use those skills to enhance Nixpacks. For example, if you already have a flake.nix file in your repo, we should build with that.

These changes will not come all at once and maybe not even soon. However, I hope this gives you an insight into how we are currently thinking of Nixpacks and where we want to take it. It is a long-term project for us and we've learned a lot since its inception a year ago. We hope to take these learnings and improve Nixpacks as much as possible.

Finally, thank you to everyone creating issues, bug reports, and especially those creating PRs 💜

[Milo123459]

Providers have to live in this repo

Where else would they go? How would we pull them in if we want to keep the true "no configuration" idea?

[aleksrutins]

How I read that is that some providers (like Node, Rust, Go, etc. - common languages) would live in this repo (or at least be referenced from this repo), and then people could configure it a bit in order to use their own providers. Alternatively, we could even have a central providers repository that links out to separate repositories for each provider, and then Nixpacks could check that.

[coffee-cup]

They could each live in their own repo with a manifest (name, description, link to wasm module, etc). Nixpacks could ship with a list of “approved” providers that we automatically use and detect with (which would keep zero-config for the main providers and languages). This would also separate the versions of providers from the Nixpacks version. But it would also open the door for more niche or custom providers that could be specified in the nixpacks.toml file under the “providers” field (or in the railway UI). Each provider would still analyze the code and try and provide the best defaults based on the source code.

technical details obviously still tbd and this is not something set in stone. We would still want to ensure the best experience for users deploying with an “it just works” solution.

—-

Edit: I didn’t see the above comment when I wrote this, but very similar idea.

[Milo123459]

I disagree with this. This was one of the biggest flaws of buildpacks. This also means that because we don't control what the provider does, if someone maliciously modifies it, we can't do anything about it, since we don't own the repository, and cannot revert the commits. This also means if someone finds a bug in a provider, they'll make an issue here. I honestly think keeping it in this repo is a better idea, but instead of the current way we do it, finding some better way to make and list them, potentially with derive-macros and simpler APIs.