# Zero to Nix: a free guide to learning Nix and flakes from first principles

> Zero to Nix is an open documentation site created by Determinate Systems that teaches Nix and flakes from the beginning, published at zero-to-nix.com. It is written as MDX on Astro, so every example in the guide is live content rather than a static code block in a PDF.

**DeterminateSystems/zero-to-nix** — Zero to Nix is your guide to learning Nix and flakes. Created by Determinate Systems.

- Repository: https://github.com/DeterminateSystems/zero-to-nix
- Website: https://zero-to-nix.com
- Stars: 1,293 · Forks: 76
- Language: MDX
- License: NOASSERTION
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/determinatesystems-zero-to-nix

## A guide aimed at people who do not know Nix yet

Zero to Nix is described in one line as a guide to learning Nix and flakes, created and maintained by Determinate Systems. The name sets the ambition: the reader starts at zero.

That framing matters because most Nix material online is reference documentation, which assumes you already know what a store path, a derivation or a flake output is. A course has to introduce those in order, and the guide's structure, with a concepts section linked from the README for flakes, reflects that ordering.

Who it is for is a developer or platform engineer who has heard that Nix solves reproducibility and deployment problems and wants to understand the model rather than paste a configuration. The site is public and free to read at zero-to-nix.com.

The commercial connection should be stated plainly rather than glossed. Determinate Systems is a company that sells products built on Nix, and this is their educational material. That does not make the teaching wrong, but it does mean the framing of the problem comes from the maintainers' perspective, and a reader who wants a neutral survey of the Nix ecosystem will not find one here. There is no paid tier mentioned in the repository, and the guide is published from an open repository.

The repository itself is the second reason to look. Everything that produces the site is in the open, including the flake, the content and the deployment configuration, so a reader can see how a Nix-flavoured documentation site is actually built.

## MDX means the examples in the guide are executable

The primary language of the repository is MDX, and the site stack is listed as Astro for content management and site generation, MDX for content, and Tailwind for CSS.

That combination is the interesting part for a Nix course. In a conventional documentation site, a code block is a fenced block of text that a reader copies and hopes works. In MDX, the content file can import and run components, and a documentation site built on it can render live output, tabs, and interactive examples alongside prose.

The package.json shows this is a real Astro application rather than a static export script. There is astro dev, astro check and astro build, an astro sync command for content type generation, and a set of integrations: @astrojs/mdx, @astrojs/react, @astrojs/rss, @astrojs/sitemap, @astrojs/alpinejs, astro-expressive-code with the collapsible sections and line numbers plugins, astro-icon, and astro-seo.

Astro is used here for exactly the reason the guide teaches: the whole toolchain is described in a flake and run with direnv, so a contributor clones the repository, allows the environment, and has a working site without assembling a Node toolchain by hand. The dependencies include Alpine.js with the persist plugin, React, Tailwind, TypeScript, marked, handlebars and posthog-js, plus rehype-external-links and remark plugins including remark-heading-id and remark-emoji.

The editor configuration in the README confirms the workflow is MDX-aware. The recommended VS Code settings turn off format-on-save for mdx files because the extension would otherwise overwrite a one-sentence-per-line policy, and set a word wrap column of 100.

## direnv and a flake, so the toolchain is not your problem

The setup section of the README is short, and its brevity is the point. Make sure you have Nix and direnv installed, then:

```shell
# Activate Nix development environment
direnv allow
```

That is the entire setup. There is no npm install, no lockfile step, no nvm use, no global tool. The .envrc at the repository root and the flake.nix with flake.lock at the root are what make direnv allow sufficient, because direnv evaluates the environment file and the flake pins and builds the toolchain.

For a project whose subject is Nix, this is the strongest possible demonstration. A reader who follows the setup ends up with a working site environment without ever installing a language runtime by hand, which is the exact property the guide is trying to explain.

It also has a cost. Contributors need Nix and direnv installed before they can do anything, and the README does not document what to do if direnv is unavailable. For a documentation project, requiring a full Nix toolchain to fix a typo in a paragraph is a real barrier for the outside contributor who just wanted to correct an example, and it is worth knowing before you file a pull request.

The repository also carries a .browserslistrc, a .prettierignore, a .rumdl.toml for markdown linting, a .vale.ini for prose linting, a lychee.toml for link checking, an .htmltest.yml, a netlify.toml with a netlify/ directory, an ec.config.mjs for expressive code, a prettier.config.cjs and a tsconfig.json.

## Four commands: dev, ci, build and format

The developer workflow is a small set of named commands, and the README explains what each one is for.

```shell
dev
```

That runs the site in development mode with live reload. For a static web server with no live reload, there is preview, and nix run as an alternative.

```shell
preview
```

```shell
nix run
```

The browser then goes to http://localhost:3000.

```shell
ci
```

The ci command runs the whole CI suite locally. The README ties this to the checks that run in GitHub Actions, and names link checking as one of them, pointing at the workflow file .github/workflows/ci.yml. The lychee.toml and .htmltest.yml files at the root are the configuration for that link checking, which for a documentation site is the check that matters most, because a tutorial with dead links is worse than no tutorial.

```shell
build
```

The build command verifies the site can build properly in response to changes, and the README notes that running the whole CI suite is an alternative since it also builds the site.

```shell
format
```

Finally, format ensures everything is properly formatted, which maps to prettier --write . in the package.json scripts, with a prettier-plugin-astro and a sort-imports plugin from trivago in the dev dependencies.

The design here is that a contributor never runs a raw npm script. Everything is wrapped as a flake-provided command, so the local workflow and the CI workflow are the same vocabulary.

## Published on Vercel, with a Netlify configuration also present

The publishing section states that the site is automatically published on Vercel, which also provides deploy previews for pull requests. That last detail is the one that matters to a contributor, because it means opening a pull request produces a working preview URL before anything is merged.

The repository also contains netlify.toml and a netlify/ directory, and the package.json includes @netlify/edge-functions. So there is a second deployment path in the tree. The README only describes Vercel for publishing, which leaves the Netlify configuration unexplained. It may be a leftover, an alternative for a fork, or the mechanism for a different part of the site, and the README does not say which.

For anyone considering running their own copy, that is the first question to ask, and it is a good example of the kind of gap worth checking before assuming a repository is a one-click deploy.

Other operational details are visible in the tree. The FlakeHub badge at the top of the README points at a flake published on FlakeHub, and the site is also announced via an @astrojs/rss integration, so a feed exists for the content. A .github/ directory holds the CI workflow, CONTRIBUTING.md is present at the root, and the licence field is listed as Other, a custom licence GitHub cannot classify, with the terms in the LICENSE file.

The last push was on 2026-10-15, and the repository has no GitHub releases, which is normal for a continuously deployed documentation site where the deployed artefact is the point, not a tagged version.

## Reading it as a course rather than a reference

There is a distinction worth being explicit about, because it determines when to open this and when to look elsewhere.

A course explains why. It can spend three pages on why a store path exists before showing you a derivation, because the concept has to land first. A reference answers what. It lists the flag and moves on. Zero to Nix is the first kind, and its value is highest for someone who has never written a flake and finds the official manual impenetrable.

The corollary is that it is a poor answer to a narrow question. If you know that you want a specific option in a specific function, reading through a teaching sequence to find it is slower than searching a reference. The site does have a concepts section for flakes, linked from the README, and a proper documentation site structure, so the content is browsable, but it is not indexed as a manual.

It is also worth noticing what the repository tells you about editorial standards, since documentation quality is the product here. The .vale.ini file configures Vale for prose linting, .rumdl.toml for markdown linting rules, lychee.toml for link checking, and .htmltest.yml for HTML checking. The VS Code configuration sets a word wrap column of 100 and disables format-on-save for MDX so that the one-sentence-per-line convention survives the editor. Those are the details of a documentation project that treats its prose as code.

The environment is public, the content is in MDX, and the checks are in CI. That combination is why the guide can stay current as the Nix ecosystem moves, at least as long as the maintainers keep it going.

## Conclusion

Zero to Nix is worth reading if you are learning Nix and flakes rather than merely copying a configuration, because the guide is structured as a teaching sequence and it is free to read, which makes it a low cost way to decide whether Nix is the right model for your team. It is the wrong tool if you want a reference for a specific option, since it is a course rather than a manual, and it is not vendor-neutral, because it is created and maintained by Determinate Systems. Before you adopt the ideas it teaches, note that the site itself is a good demonstration of the stack it recommends, and the flake at the repository root plus the dev, ci and build commands give you a working environment to experiment in before touching your own configuration.

## FAQ

### What is Zero to Nix and who maintains it?

It is a guide to learning Nix and flakes, published at zero-to-nix.com, created and maintained by Determinate Systems. The repository is open and the site content is written in MDX.

### How do I set up the Zero to Nix development environment?

Install Nix and direnv, then run direnv allow in the repository root. The .envrc and the flake at the root are what make that the only step needed before running the dev command.

### How do I run the Zero to Nix site locally?

Run dev for development mode with live reload, or preview for a static web server with no live reload, where nix run is an alternative. Then open http://localhost:3000.

### How is the Zero to Nix site published?

The README states the site is automatically published on Vercel, which also provides deploy previews for pull requests. The repository also contains a netlify.toml and a netlify/ directory that the README does not explain.

### What technologies does the Zero to Nix site use?

The README lists Astro for content management and site generation, MDX for content, and Tailwind for CSS. The package.json confirms Astro with the MDX, React, RSS, sitemap, Alpine.js, expressive code, icon and SEO integrations.

## Sources

- [DeterminateSystems/zero-to-nix on GitHub](https://github.com/DeterminateSystems/zero-to-nix)
- [Issues](https://github.com/DeterminateSystems/zero-to-nix/issues)
- [Project website](https://zero-to-nix.com)
- [README](https://github.com/DeterminateSystems/zero-to-nix/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/determinatesystems-zero-to-nix
