Put the toolchain next to the code.

Pin a Nixpkgs revision instead of silently following whatever happens to be current. Review dependency changes when you update that revision.

Pinned inputs help you repeat a setup. They do not guarantee identical results across different operating systems, architectures or nondeterministic upstream builds.

Keep the build definition in the repository and call it from your CI runner. A binary cache can share previously built outputs rather than asking every runner to build them again.

The runner still needs the right platform, permissions and resources. The cache needs a trust policy. Secrets and external services do not become reproducible by putting a build in Nix.

Nix can build Docker-compatible images from package definitions. You can use that for an application that will run in an existing container deployment.

The resulting image is not automatically a booted NixOS system, and Nix is not a replacement for the container runtime.

You will see projects use flake.nix and flake.lock to describe outputs and record inputs. Flakes and the newer Nix command interface still require experimental features in the upstream documentation checked for this guide.

Follow the project’s setup instructions. You do not have to learn flakes before trying the basic Nix tutorials.