In my posts, I try my absolute best to always have some unique take, or at least a new perspective. I don’t see a point in writing a rephrased copy of an existing article. If I write, I want to make sure that it’s at least slightly new. I’ve been meaning to write an article about Nix ever since I started my blog, but it’s only now that I’ve finally found something unique to talk about. You see, Nix in itself doesn’t solve enough of a problem to become mainstream, and its clear advantages are hidden behind a steep learning curve and a lack of documentation, making it not even worthwhile to consider. In this article, I will go over a simple way to use the best features offered by Nix while avoiding the learning curve entirely, therefore providing maximum benefit with minimal time dedication.

The point of this article is not to explain everything from absolute 0. There are thousands of articles that can do it better, so I recommend you read them for a proper explanation. Here are some good resources that will explain Nix and NixOS to you, as well as other Nix-related resources that might be useful:

• https://zero-to-nix.com/
• https://nixos.org/
• https://search.nixos.org/
• https://determinate.systems/
• https://michael.stapelberg.ch/posts/tags/nix/
• https://www.youtube.com/@vimjoyer
• https://www.youtube.com/watch?v=nLwbNhSxLd4&pp=ygUPYW1wZXJzZW50IG5peG9z
• https://nixos.org/guides/nix-pills/

Here are my recommendations in 4 simple steps that will prevent you from wasting time and will straight away give you all the benefits of using Nix without actually learning it:

1: Forget About NixOS

As amazing as it sounds, NixOS takes a lot of time to prevent it from getting in your way. While I do personally use it, my relationship with it is not the best. It took countless days to make me as comfortable on the system as I am right now. I do recommend trying it out when you have a few weeks of free time and are willing to experiment, but for the most part, NixOS will only waste your time.

2: Get Determinate Nix

Install Determinate Nix instead of the official Nix installer. This will prevent all of the initial pain that comes with standalone Nix and will enable flakes straight away, unlocking the full potential of the package manager. Follow the tutorial on the Determinate Systems website; it should take you less than a minute to get running.

3: Shells For Tinkering

This is what you will use Nix the most for and what I would argue is its most useful feature. It allows you to try an app out before committing to it and fully installing it. The syntax is simple and can be grabbed straight from the official website (I would recommend sticking with the flake way of running shells: nix shell nixpkgs#<package name>). A recommended workflow with Nix shells looks like this:

1. Open search.nixos.org
2. Find the package that you want to try out
3. Copy the shell command and run it
4. Wait for it to download, and now you can use the app!

After you close the terminal where you ran the shell, the program will no longer be accessible in your environment. If you then want that package again, just run the shell command — it will get you the app instantly, since the Nix store path for it is still stored on your computer and there is no download required (unless the package was updated, of course).

REMEMBER: this is not for permanently installing packages, but for trying them out only. Shells allow you to tinker with things without thinking twice, as popping a shell is always the same simple process, while installing an app fully is far more of a commitment and might require extra configuration to get working.

If you then want the app to be available on your entire system forever, either download it via your other package manager or follow the method recommended by the package documentation. If, though, you really don’t want to go through the trouble, or the new package will interfere with the rest of your system, you can always install it into your Nix profile with nix profile add nixpkgs#<packageName>. This will install the package fully onto your system and make it available through any terminal on your device. While this will work perfectly, I still recommend sticking to other means of package installation, simply for your own convenience and to avoid maintaining a second package manager.

4: Generate Your Nix Flakes

Think of a flake as a self-contained blueprint for your project. Unlike a standard shell script that hopes you have the right tools installed, a flake uses a flake.lock file to strictly pin every single version of every dependency. This guarantees that if the environment works on your machine today, it is mathematically guaranteed to work on your server, your friend’s laptop, and your future self’s computer five years from now. To learn more about them, check out the Zero to Nix guide.

This allows you to maintain flakes separately from the rest of your system and away from any changes to the Nix channel used by your main system. The best way to use flakes is for very niche tasks that require a very specific set of programs. One good example is using them as development environments. If you work on many different programming projects, you can quickly make a flake with all of the project requirements which, unless updated, will be locked and unaffected by other system updates, therefore preventing anything from accidentally breaking. If you then use Git, you can version your flakes, allowing for seamless rollbacks in case something goes wrong. Flakes use flake.lock files (auto-generated after running the flake) to lock the versions of the apps, so make sure to version that file first and foremost.

As an example, I have flakes for .NET dev, Android dev, as well as a flake for each of my programming projects with the specific software inside it.

So, how do I utilize this great feature without countless hours spent trying to understand it? Just generate your flakes with AI. This is extremely controversial, since AI is likely to mess something up. That’s why I will now provide you with a prompt that will allow for a clean and simple workflow for generating Nix flakes.

# PROMPT FOR GENERATING PERFECT NIX FLAKES

## Role
You are an expert Nix flake generator specializing in creating cross-platform, production-ready flake.nix files that strictly follow Nix language standards and best practices. Your flakes must be readable, maintainable, and precisely configured to user specifications.

## Core Requirements

### 1. Nix Language Standards & Formatting
Follow these conventions strictly in every flake you generate:

**Indentation & Spacing:**
- Use 2 spaces for indentation (never tabs)
- No trailing whitespace
- One blank line between major sections
- Format all code using nixfmt standards

**Naming Conventions:**
- Use lowerCamelCase for variable names
- Use lowercase with dashes for file/directory names (e.g., `my-package.nix`)
- Attribute names should be descriptive and follow nixpkgs conventions

**Code Structure:**
- List function arguments explicitly with pattern matching: `{ stdenv, fetchurl, lib }:` not `args:`
- Use `lib.optional(s)` for conditional lists
- Avoid unnecessary string interpolations: use `rev = version;` not `rev = "${version}";`
- Place package definitions in separate files using callPackage pattern when appropriate
- Use indented strings (`'' ''`) for multi-line strings

**Attribute Ordering in flake.nix:**
1. description
2. inputs
3. outputs (structured as: inputs pattern → let block → attribute set)

**Within outputs:**
1. System-agnostic attributes first (overlays, lib, nixosModules)
2. System-specific attributes via eachDefaultSystem or manual iteration
3. Packages
4. Apps
5. DevShells
6. Checks

### 2. Cross-Platform Support
- Support these platforms by default: x86_64-linux, aarch64-linux, x86_64-darwin, aarch64-darwin
- Use `flake-utils.lib.eachDefaultSystem` or equivalent for system-specific outputs
- Never use impure constructs like `builtins.currentSystem`
- Ensure all package references work across supported platforms

### 3. Package Name Verification
**CRITICAL REQUIREMENT:**
- You MUST attempt to verify package names against search.nixos.org before including them
- If you cannot access search.nixos.org during generation, you MUST include a clearly formatted notice after the flake output

**Post-Generation Notice Format (if package verification unavailable):**

NOTE: if the folder you put the flake in is tracked by git, commit it before running it (git add . git commit -m "nix flake added")

Since the Nix language is actually really simple to read, I assume that you will be able to easily adjust the generated flake to fit your requirements. This should take less than 5 minutes.

In order to then use the flake, copy the code that the AI generated into a flake.nix file and then run it with nix develop .. It will either work straight away or give errors. Do not be scared — just paste the error back into the AI and it will assist you in making sure that it works.

To speed up the workflow and ensure a perfect setup, install direnv on your system, then run echo "use flake" >> .envrc followed by direnv allow. This will make it so that every time you open that folder, the Nix flake will instantly apply.

Things to know - Cleanup

Due to the way Nix stores packages, there will eventually be loads of cache that just sits there and takes up space. Determinate Nix automatically manages said cache, but sometimes (especially after lots of direnv rebuilds) you still need to manually clean your system. You can do this with nix-collect-garbage -d. The -d flag removes all cache that is currently not in use at all. You can also use --delete-older-than 5d, which will delete everything older than 5 days (you can of course adjust the time period as you like).

The advantages of using this setup

Nix allows for clean, reproducible environments that do not interfere with the rest of your system. This prevents clutter. If you are anything like me and constantly pollute your system with loads of packages and extra dependencies that over time turn your laptop into a mess, this setup ensures that this barely ever happens, as it keeps all of your “mess” away from the main system.

By testing before committing (using the nix shell command), you can greatly decrease the number of random packages that pollute your system and cause issues later on.

Final thoughts

Nix has been undervalued for many years at this point due to its complexity. Thanks to the rise of AI and projects revolving around Nix, its clear advantages are more accessible than they have ever been. While it will absolutely take a bit of trial and error to get started, you will not regret it, as all of your projects will have clearly declared cross-platform environments and the ability to fetch any tool you might ever desire into a quick shell will forever change the way you try software out.