Skip to main content

What is Nebi?

Nebi is a multi-user environment management tool. Think of it as git for environments: you can push, pull, diff, and roll back, with access control built in.

The Problem​

If you use pip or uv, you might run into this: your project needs GDAL, CUDA, or another compiled C/C++ library, and pip install fails because the system dependency isn't there.

× Failed to build `gdal==3.12.2`
╰─▶ gdal_config_error: No such file or directory: 'gdal-config'
    Could not find gdal-config. Make sure you have installed
    the GDAL native library and development headers.

These are system-level dependencies that pip and uv cannot install. Fixing this means falling back to your OS package manager, matching exact versions, and repeating the process on every machine.

Pixi solves the dependency problem by managing both Python packages (from PyPI) and compiled system libraries (from conda-forge) in a single lockfile, so pixi add gdal just works across platforms.

But pixi wasn't designed for team environment management:

  • No dedicated version history: Pixi overwrites the lockfile on every change, so tracking, diffing, or rolling back requires a separate version control system like git.
  • No publish and distribution system: Environment specifications and lockfiles live inside project directories, shared only through the project repository. There is no built-in way to publish or distribute environments independently.
  • No governance: Anyone who can edit pixi.toml can change the environment, with no approval workflows or access control beyond the project repository level permissions.

Nebi builds on Pixi to fill these gaps.

Why Nebi?​

Since nebi builds on pixi, you get all of pixi's features plus team collaboration on top.

Install system libraries alongside Python packages (with Pixi)​

Nebi tracks the pixi.toml and lockfile, so you can use pixi directly to install packages. pixi add gdal installs both the Python bindings and the compiled C/C++ library. No separate apt-get or brew steps needed:

pixi add gdal geopandas lightgbm
pixi add --pypi scikit-learn

Reproducible environments with lockfiles (with Pixi)​

Without a lockfile, the same install can produce different environments on different machines or at different times. Pixi solves this by generating a lockfile on every pixi add, pinning every transitive dependency to an exact version and hash:

pixi add geopandas gdal lightgbm

This generates pixi.toml and pixi.lock, which together pin every transitive dependency to an exact version, hash, and download URL.

Once you commit both files to version control, a teammate can pull and recreate the exact same environment:

# Pull the latest pixi.toml and pixi.lock
git pull

# Recreate the exact same environment
pixi install

Built-in task runner (with Pixi)​

Data science projects involve commands that are hard to remember, like python src/train.py --config configs/experiment_3.yaml --epochs 100.

Pixi has a built-in task runner that stores these commands alongside your dependencies, so anyone on the team can run them without memorizing the details:

# Define tasks
pixi task add train "python src/train.py"
pixi task add test "pytest tests/"

# Run by name
pixi run train

Version and roll back environments​

When a dependency update breaks your pipeline, you need to know exactly what changed. Diffing a 500-line lockfile in git history isn't practical.

Nebi lets you push snapshots, compare what changed between versions, and roll back when an update breaks your workflow:

# Push a snapshot of your current environment
nebi push geo-ml:v1.0

# Later, after adding packages...
nebi push geo-ml:v2.0
nebi diff geo-ml:v1.0 geo-ml:v2.0

# Something broke? Roll back.
nebi pull geo-ml:v1.0
pixi install

Share environments across your team​

Instead of sharing environments through git repos, Nebi publishes them to an OCI registry (the same standard behind Docker Hub). Anyone on your team can pull and reproduce your setup from anywhere:

# Publish to an OCI registry
nebi publish my-project --tag v1.0.0

# A colleague on another machine:
nebi import quay.io/nebari/data-science:v1.0 -o ./my-project

Control who can modify production dependencies​

Role-based access control and OIDC authentication let you enforce who can push, pull, or modify shared environments. Every change is tracked, so you always know who modified what and when.

Use workspaces by name from anywhere​

In data science, it's common to reuse the same environment across multiple projects. With both uv and pixi, environments are tied to project directories, so you'd have to cd into the source project each time:

cd ~/projects/geo-ml && pixi shell   # must cd into the source project
cd ~/projects/analysis && pixi shell # must cd back again for a different project

Nebi lets you activate any tracked workspace by name from anywhere:

cd ~/projects/analysis
nebi shell geo-ml       # no need to cd back

cd ~/projects/dashboard
nebi shell geo-ml       # same environment, any directory

How Does It Compare?​

Featureuvcondapixinebi
Compiled system libraries (GDAL, CUDA)NoYesYesYes
Lockfiles with exact versionsYesNoYesYes
Fast dependency resolutionYesNoYesYes
PyPI + conda-forge in one toolNoLimitedYesYes
Environment versioning and diffingNoNoNoYes
Team sharing via registriesNoNoNoYes
Role-based access controlNoNoNoYes

Next Steps​