Comparisons

Zoi is an advanced package manager and environment orchestrator. It has its own package format (.pkg.lua), a versioned package store, project environments, rollback support, registry security features, and integration with many native and language package managers.

The short version:

• Use Zoi when you want one cross-platform workflow for installing tools, defining project environments, packaging software, and mixing Zoi-managed packages with native dependencies.
• Use Nix when maximum reproducibility and fully isolated functional builds are the top priority.
• Use Homebrew, APT, Pacman, Scoop, or Winget when you only need the normal package manager for one operating system.
• Use mise or asdf when you mainly need runtime version switching for languages.
• Use Devbox or Flox when you want a friendlier workflow on top of Nix.

What Zoi Is

Zoi is not only a wrapper around existing package managers. Zoi can install its own packages into a versioned store, create shims, manage project-local environments, resolve package graphs, run package tests, track files, audit advisories, roll back Zoi-native packages, and build packages from Lua definitions.

Zoi also does not pretend native package managers do not exist. A .pkg.lua package can depend on native:openssl, cargo:ripgrep, npm:typescript, brew:cmake, scoop:git, or many other managers. That makes Zoi useful for real machines where some dependencies should come from the host platform.

What Zoi Is Not

Zoi is not a full operating system distribution, and it does not snapshot your entire machine. When Zoi asks APT, Homebrew, Cargo, NPM, or another external manager to install a dependency, that external manager still owns its own state.

Zoi is also not as purely reproducible as Nix. Zoi improves reproducibility with zoi.lock, package hashes, registry metadata, PGP verification, and project-local installs, but external package managers can still change independently.

Main Comparison

Zoi vs. Nix

Nix is the stronger choice if your main requirement is fully reproducible builds and environments. Its store model and functional package language are designed around reproducibility from the ground up.

Zoi is the stronger choice if you want a packaging system that is easier to script with familiar Lua, works across Linux, macOS, and Windows, and can cooperate with existing package managers. A Zoi package can combine a Zoi-managed binary with dependencies from APT on Ubuntu, Homebrew on macOS, Scoop on Windows, Cargo for Rust tools, or NPM for JavaScript tools.

Tradeoff:

• Nix gives stronger isolation and reproducibility.
• Zoi gives a more hybrid, host-aware workflow and a package format that is closer to traditional scripting.

Choose Nix when you want the environment to be independent from the host. Choose Zoi when the host package manager is part of the intended setup.

Zoi vs. Homebrew, APT, Pacman, Scoop, and Winget

Native package managers are excellent at managing software for their own platform. If all you need is apt install, brew install, pacman -S, scoop install, or winget install, use the native manager directly.

Zoi becomes useful when you need a workflow that crosses those platforms:

• one package definition can branch on SYSTEM.OS and SYSTEM.ARCH
• one project can define tools in zoi.yaml
• one command can install Zoi packages plus native dependencies
• one package can expose metadata, tests, rollback behavior, services, and security advisories
• one registry format can be mirrored or self-hosted

Zoi does not replace the native manager in every case. It can call the native manager when that is the right source for a dependency.

Zoi vs. mise and asdf

mise and asdf are focused on language runtime and tool version management. They are a good fit when you mainly need to switch between Node.js, Python, Ruby, Go, or similar runtimes per project.

Zoi is broader. It can manage runtimes, but it also manages packages, package definitions, package tests, binary archives, services, security advisories, project commands, rollback, and registries.

Tradeoff:

• mise and asdf are simpler for runtime-only workflows.
• Zoi is better when runtimes are only one part of a larger environment.

If your project only needs node 20 and python 3.12, a runtime manager may be enough. If your project also needs native libraries, custom tools, services, package metadata, and a reusable package format, Zoi is a better fit.

Zoi vs. Devbox and Flox

Devbox and Flox provide friendlier workflows on top of Nix. They are good options when you want Nix-powered environments without interacting with raw Nix as much.

Zoi takes a different path. It does not use Nix as its engine. Its engine is Zoi's own package resolver, store, registry model, and Lua package format. That means Zoi packages can be written as scripts and can intentionally use host-native package managers.

Tradeoff:

• Devbox and Flox inherit Nix's reproducibility and package ecosystem.
• Zoi gives more direct control over package scripting and native dependency integration.

Zoi vs. Docker

Docker is for containers. It is excellent when you want a process to run in an isolated filesystem image.

Zoi is for provisioning tools and environments on a machine or inside a project. It can be used in CI, containers, workstations, and sysroots, but it does not require every workflow to become a container.

Use Docker when the deployment unit is a container. Use Zoi when the developer or system environment itself needs managed tools.

Where Zoi Fits Best

Zoi is a good fit for:

• developers working across Linux, macOS, and Windows
• projects that need a checked-in zoi.yaml and zoi.lock
• package authors who want a Lua-based package format
• teams that need internal registries or mirrors
• environments where package advisories, PGP verification, policy, audit history, and rollback matter
• workflows that need both isolated Zoi packages and host-native dependencies

Zoi is probably not the best first choice for:

• systems that require Nix-level reproducibility
• users who only need one operating system's default package manager
• projects that only need runtime version switching
• environments where arbitrary package scripts are not allowed unless a strict registry and signature policy is enforced

Reproducibility Expectations

Zoi's reproducibility depends on what kind of dependency is being installed.

For strict project installs, commit zoi.yaml and zoi.lock, then use:

zoi install --local --frozen-lockfile

Security Expectations

Zoi has multiple security features, but they are strongest when used together:

• package archive hashes
• PGP signature verification
• built-in or imported PGP keys
• registry commit authorities
• decentralized .sec.yaml advisories
• zoi audit
• policy controls in system configuration
• offline mode and mirrored registries

The important trust question is: who controls the registry and package definitions you are installing from?

For personal use, the official Zoidberg registry may be enough. For teams or companies, prefer an internal mirror, trusted PGP keys, registry authorities, and policy enforcement. See Security Policy and Security Advisories.

Decision Guide

Summary

Zoi is best understood as a hybrid package manager and environment tool. It gives you a Zoi-native store and package format, but it can still cooperate with the package managers already present on the host.

That hybrid design is the point. Zoi is not trying to beat Nix at pure reproducibility, or beat APT and Pacman at managing their own distributions, or beat mise at being only a runtime manager. Zoi is for the middle ground: cross-platform packages, project environments, native dependency integration, and a package format that is practical to write and review.