Every package output in IX lives at a unique path underDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/pg83/ix/llms.txt
Use this file to discover all available pages before exploring further.
/ix/store/. That path is immutable once created: its contents never change, and no two different builds share the same location. The store is content-addressed — the path is derived from the exact inputs used to build the package — which is conceptually similar to the stores used by NixOS and Guix, though IX makes its own trade-offs around static linking, build isolation, and template-based recipes.
Store Path Structure
A store path has the form/ix/store/<22-char-hash>-<pkg-name>/. The hash is a 22-character base-62 string (lowercase letters a–z, uppercase letters A–Z, and digits 0–9). The name portion is the package path with slashes replaced by hyphens, preceded by a single hyphen.
For example, the bin/bzip2 package produces:
0GsKotnAh74LIcvO uniquely identifies this particular build of bin/bzip2 with exactly these inputs.
Content Addressing
The 22-character hash is derived from everything that influences the build: the source URL and its checksum, all declared dependencies and their own hashes, all flags and build parameters, and the build script itself. This has important consequences:- Same inputs → same hash → same path. If two machines build the same package from the same recipe, they produce identical store paths.
- Different inputs → different hash → different path. Changing a version number, a flag (e.g.
--mesa_driver=radv), or any dependency produces a new hash and a new, non-overlapping store path. - No version conflicts. Because different builds land at different paths, multiple versions of a package can coexist in the store simultaneously without interfering.
The env File
Every package directory contains an env file. This file is a shell script that exports the paths and flags needed by downstream consumers. When another package declares a dependency on this one, IX sources its env file before the dependent package’s configure and build steps run. A typical env file might look like:
die/std/env_auto.sh during the package’s postinstall phase.
The touch File
Each package directory also contains a touch file. The presence of this file marks the package as fully and successfully built. IX checks for the touch file to determine whether a store entry is complete. A store path whose touch file is absent is considered incomplete and will be rebuilt.
Immutability
Once a store path is created and itstouch file written, the directory is read-only. Nothing in the build system modifies an existing store entry. This immutability is what makes the store safe to share across users and processes: a package in use by one realm cannot be silently mutated by another build.
Old store entries are not removed automatically. Removing unreachable entries requires running the garbage collector explicitly:
ix gc identifies all store paths that are not reachable from any anchor realm in /ix/realm/ and moves them to /ix/trash/ for asynchronous deletion. You can restrict which package prefixes are candidates for collection by passing prefixes as arguments (the defaults are lib, bin, lnk, aux, and rlm).
The store is shared across all users on a stal/IX system. Because store paths are content-addressed, different users can install different versions of the same package without conflict. Each user can also work from a different clone or branch of the IX repository — the
IX_PATH and IX_PKGS_ROOT environment variables control which recipe tree is used.Configuring the Store Root
By default IX uses/ix as the root of its data directory. The store lives at /ix/store/ and the garbage collection staging area at /ix/trash/. You can override the root with the IX_ROOT environment variable:
| Path | Purpose |
|---|---|
$IX_ROOT/store/ | Immutable package outputs |
$IX_ROOT/realm/ | Anchor symlinks pointing to active realm versions |
$IX_ROOT/trash/ | Staging area for GC’d store entries awaiting deletion |