Exploring the Kubernetes Ecosystem with Pixi

Managing a Kubernetes cluster means juggling a dozen CLI tools, kubectl, helm, k9s, stern, argocd, and more. Each has its own installation method, its own release cycle, and its own way of breaking when you upgrade your OS. If you've ever spent 20 minutes debugging CI because helm was the wrong version, this post is for you.

At prefix.dev, we've been building out the Kubernetes ecosystem across our channels. Together with Pixi, you can now install, lock, and reproduce your entire cloud-native toolbox in seconds.

The Problem with curl | bash

Most Kubernetes tools ship as static binaries on GitHub. The standard installation looks something like:

curl -LO "https://dl.k8s.io/release/$(curl -L -s \
  https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
chmod +x kubectl
sudo mv kubectl /usr/local/bin/

This works pretty well, there's a reason why nearly every CLI tool promotes that method on their homepage. We do the same with Pixi's installation instructions. However, it stops working when you do this with many tools that even depend on each other. There will be no central update workflow and no way to keep them in sync.

Homebrew

Homebrew is a real step up from curl | bash. You get a single package manager, a consistent installation experience, and easy upgrades:

brew install kubectl helm k9s stern

Pixi

At prefix.dev we develop the Pixi package manager, a cross-platform package manager based on the conda ecosystem. Most people using Pixi get their packages from the conda-forge channel, but that falls short if your binary isn't available there. This is why we created github-releases to automatically repackage binary releases from GitHub into conda packages. The binaries are untouched. The SHA hashes match the original release artifacts exactly. It's the same binary you'd download manually, just wrapped in a package that Pixi can resolve, lock, and cache. Read more about this at Tobias' blog post.

Combined with long-standing packages on conda-forge (like kubernetes-helm and kubernetes-client), you now have a massive Kubernetes toolkit available through Pixi with over 50 kube-related packages alone.

If you just want a quick global install, Pixi works similar to brew but with isolated environments per tool:

pixi global install kubernetes-client
pixi global install --channel https://prefix.dev/github-releases k9s

No conflicts, no pollution of your system path. And unlike Homebrew, it works the same on macOS, Linux, and Windows.

Pixi Workspaces

The real power comes when you define your Kubernetes toolbox as a Pixi project. Here's a pixi.toml that pins your deployment tools and defines reusable tasks:

[workspace]
name = "k8s-deploy"
channels = ["conda-forge", "https://prefix.dev/github-releases"]
platforms = ["linux-64", "osx-arm64"]

[dependencies]
kubernetes-client = ">=1.34"
kubernetes-helm = ">=4.1"
kubeconform = ">=0.7"
kube-linter = ">=0.8"

[tasks]
validate = { cmd = "kubeconform -summary ./manifests/ && kube-linter lint ./manifests/" }
lint = "helm lint ./charts/my-app"
deploy = { cmd = "helm upgrade --install my-app ./charts/my-app --namespace production --values values-prod.yaml", depends-on = ["lint"] }
verify = "kubectl rollout status deployment/my-app --namespace production"

Run pixi install and you get a pixi.lock file that pins the exact version and hash of every tool, across all platforms. Check both pixi.toml and pixi.lock into Git, and every developer on your team whether they're on macOS or Linux, gets the exact same versions.

No more "it works on my machine" for infrastructure tooling.

Reproducible Continuous Integration

This is where it all comes together. Instead of a CI workflow that downloads tools with curl on every run, use the setup-pixi GitHub Action:

name: Deploy to Kubernetes

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6

      - uses: prefix-dev/setup-pixi@v0.9.4
        with:
          cache: true

      - name: Validate manifests
        run: pixi run validate

      - name: Deploy with Helm
        run: pixi run deploy

      - name: Verify deployment
        run: pixi run verify

setup-pixi caches the resolved environment based on the pixi.lock hash. On a cache hit, your tools are ready in seconds. The lockfile guarantees the exact same binary versions in CI as on your laptop, and your lockfile is in Git so you can git blame exactly when helm was upgraded from 4.0.0 to 4.1.1.

What's Available?

Here's a selection of what you can install today:

Core Tools (conda-forge)

GitOps & Deployment (github-releases)

Cluster Operations (github-releases)

Security & Compliance (github-releases)

Debugging & Visibility (github-releases)

Helm Tooling (github-releases)

Terraform and Friends (conda-forge & github-releases)

The github-releases channel has thousands more packages from across the DevOps ecosystem.

Conclusion

Install Pixi, drop a pixi.toml in your repo, run pixi install, and commit the lockfile. That's it. Your Kubernetes toolbox is now versioned, locked, and reproducible across every machine and CI runner your team touches.

If you run into any issues with the packages, please report them on the github-releases repository. Join us on Discord if you have further questions.