[flakes] how do I consume the output of nix flake archive in another store?

Help
1

I have packaged a Rust application using nix flakes and would like to deploy it to another server that has nix installed.

I have successfully created a binary cache from that application by executing nix flake archive --to file:///tmp/nix-binary-cache ./my-flake-directory
per the nix 2.4 alpha / 3 guide: nix flake archive - Nix Reference Manual

Based on the manual’s wording, I thought nix flake archive ./data/nix-binary-cache/ would work. But that errored because the binary cache is not a flake.

I am stuck on how to consume this from another nix store. Without trying any more complex build tools, what nix command should I use to consume this?

Should I even use a binary cache?

I have considered simply copying the flake to the server and simply doing nix run. But I would like to have the project compiled in advance and not on the destination server.

This is a kind of feedback to the Nix 2.4 RC.

1 Like
2

As gar as I understand, this command will not “archive” the outputs, but just the flakes source.

Why don’t you just reference the flake from the other systems config flake as an input?

For getting it precompiled over you can use services like cachix to have a remote binary cache, or you can use nix copy to copy over the closure to the other hosts store.

1 Like
3

Ah, that may be where I misunderstand archive.

Your solution sounds like a better use of the existing tools! I love it and will give it a try.

4

I think a binary cache would help in this instance. Shouldn’t be too hard to setup.

Especially if you’re going to use multiple machines, this will scale much nicer.

If the remote machine is also nixos, then you can push configurations to it from a local machine by doing sudo nixos-rebuild --target-host=remote.host --flake .#<hostname> switch. This will build the configuration locally, push it to the remote machine, then perform a switch.

2 Likes
5

I like this solution for its scalability! Unfortunately I have work within the confines some organizational constraints. These constraints lead me to favor less stateful implementations for deployments. e.g. passing around archives instead of additional nodes in our network.

If I continue bundling multiple packages this approach sounds like a way to reap the benefit of what Jon mentioned without doing the maintenance myself!

I have landed on a simple prototype that fits my current needs. Thanks again for the advice!

I have created a trivial flake.nix that packages the binary.

  1. in continuous integration, build the Rust binary
  2. copy a versioned release-flake/ directory to /tmp/
    • this is needed to avoid the different semantics of working with flakes in a git repository
  3. copy that compiled binary into the directory /tmp/release-flake
  4. run nix flake lock to update the release-flake’s flake.lock
  5. archive the /tmp/release-flake

I then have a release-flake.tar.gz I can pass around and install on the relevant system. I appreciate this newfound flexibility. I remember getting tripped up on this task before nix flakes were a thing.

1 Like