mise, Nix und devcontainers lösen alle das "Works on my machine"-Problem – sie sind sich nur uneinig, wie

Der Satz "Works on my machine" verfolgt Softwareteams seit Jahrzehnten. Ein neuer Mitarbeiter kommt, verbringt zwei Tage damit, seine Umgebung zum Laufen zu bringen. Ein Senior-Entwickler aktualisiert Python und zerstört drei Projekte. CI schlägt fehl wegen einer Bibliotheksversion, an die niemand beim Pinnen gedacht hat. Die Ursache ist immer dieselbe: Entwicklerumgebungen sind zustandsbehaftet, implizit und manuell zusammengebaut.

Im Jahr 2026 ist dieses Problem tatsächlich gelöst – aber "gelöst" bedeutet drei konkurrierende Tools mit radikal unterschiedlichen Philosophien. Die Kompromisse zu verstehen, ist die eigentliche Fähigkeit.

Tier 1 – mise: Der pragmatische Einstiegspunkt

mise (ehemals rtx) ist ein polyglotter Versionsmanager, geschrieben in Rust. Es ersetzt asdf und ist aufgrund seines kompilierten Kerns und der parallelen Plugin-Auflösung 10- bis 20-mal schneller. Es verwaltet Node.js, Python, Go, Ruby, Java und Dutzende anderer Laufzeiten aus einem einzigen Tool.

Der zentrale Mechanismus ist .mise.toml im Projektstammverzeichnis:

[tools]
node = "22.3.0"
python = "3.12.4"
go = "1.22.5"

[env]
DATABASE_URL = "postgres://localhost/myapp_dev"

Führen Sie mise install aus und es liest die Konfiguration, lädt die gepinnten Versionen in einen inhaltsadressierten lokalen Cache (~/.local/share/mise/installs/) herunter und aktiviert sie für das aktuelle Verzeichnis. Kein Symlink-Gefummel, keine Shell-Hacks außer dem Hinzufügen von mise activate zu Ihrem Profil.

Der Leistungsunterschied zu asdf ist nicht subtil. Eine Node.js-Version zu installieren, für die asdf 45 Sekunden zum Auflösen und Installieren benötigt, erledigt mise in unter 4 Sekunden. Für Teams, die ständig zwischen Projekten mit unterschiedlichen Laufzeitanforderungen wechseln, summiert sich das zu echter Zeitersparnis.

Was mise nicht tut: Es verwaltet Sprachlaufzeiten, nicht Systembibliotheken. Wenn Ihr Projekt eine bestimmte Version von libpq, openssl oder ffmpeg benötigt, kann mise nicht helfen. Es kann auch nicht die exakte glibc-Version unter Linux oder die exakte Xcode-Toolchain unter macOS reproduzieren. Für die meisten Anwendungsentwickler spielen diese Lücken keine Rolle. Für alle anderen: lesen Sie weiter.

Tier 2 – Nix und Nix Flakes: Vollständige Reproduzierbarkeit

Nix ist ein funktionaler Paketmanager, der auf einer Idee basiert: Jedes Paket ist eine reine Funktion seiner Eingaben. Bei gleichen Eingaben erhält man immer die gleiche Ausgabe. Pakete leben unter /nix/store/ in inhaltsadressierten Pfaden wie /nix/store/ybmrfz0-nodejs-22.3.0/. Zwei Pakete können ohne Konflikte von verschiedenen Versionen derselben Bibliothek abhängen, da sie buchstäblich an verschiedenen Pfaden existieren.

nixpkgs ist das Paket-Repository: über 90.000 Pakete, alle reproduzierbar gebaut, die jedes große Sprachökosystem sowie Systemtools, Schriften, Datenbanken und Compiler abdecken. Es ist die größte Single-Source-Paketsammlung aller Linux-Distributionen.

Nix Flakes (stabilisiert in NixOS 23.11) fügen Nix ein Lockfile-gesteuertes Abhängigkeitsmodell hinzu. Ein flake.nix im Projektstammverzeichnis pinnt den exakten nixpkgs-Commit und definiert eine devShell:

{
  inputs.nixpkgs.url = "github:NixOS/nixpkgs/nixos-24.05";

  outputs = { self, nixpkgs }: {
    devShells.x86_64-linux.default = nixpkgs.legacyPackages.x86_64-linux.mkShell {
      packages = with nixpkgs.legacyPackages.x86_64-linux; [
        nodejs_22
        python312
        go_1_22
        postgresql_16
        ffmpeg
      ];
    };
  };
}

Führen Sie nix develop aus und Sie landen in einer Shell, in der jedes Tool genau wie angegeben ist – bis hinunter zu den C-Bibliotheksversionen. Die Datei flake.lock pinnt den nixpkgs-Commit-SHA. Sechs Monate später, auf einem anderen Rechner, in einem anderen Land, erzeugt nix develop dieselbe Umgebung.

Die ehrliche Lernkurve: Nix hat eine eigene funktionale Sprache (ebenfalls Nix genannt), ein eigenes mentales Modell für Builds und eine Dokumentation, die Vertrautheit mit funktionalen Programmierkonzepten voraussetzt. Die meisten Entwickler brauchen 1–2 Wochen, bevor sie sich sicher fühlen, Flakes von Grund auf zu schreiben. Tools wie devenv.sh und flake-parts reduzieren dies erheblich, aber es gibt keinen Shortcut an den grundlegenden Konzepten vorbei.

Die Auszahlung ist real. Teams, die Nix Flakes verwenden, berichten von null "Environment Drift"-Problemen in Post-Mortems. CI verwendet dieselbe nix develop-Shell wie die lokale Entwicklung. Neue Mitarbeiter führen am ersten Tag nix develop aus und haben innerhalb von Minuten eine funktionierende Umgebung, nicht Tage.

Tier 3 – devcontainers: Onboarding und Cloud-First-Entwicklung

devcontainers ist eine offene Spezifikation (unterstützt von Microsoft und verwendet in VS Code und GitHub Codespaces), die eine Entwicklungsumgebung als Docker-Container definiert. Die Konfiguration befindet sich in .devcontainer/devcontainer.json:

{
  "name": "My Project",
  "image": "mcr.microsoft.com/devcontainers/javascript-node:22",
  "features": {
    "ghcr.io/devcontainers/features/python:1": { "version": "3.12" },
    "ghcr.io/devcontainers/features/go:1": { "version": "1.22" }
  },
  "postCreateCommand": "npm install",
  "customizations": {
    "vscode": {
      "extensions": ["dbaeumer.vscode-eslint", "esbenp.prettier-vscode"]
    }
  }
}

Die Remote - Containers-Erweiterung von VS Code mountet Ihre lokalen Dateien in den Container und führt Ihren gesamten Editor darin aus – Sprachserver, Debugger, Terminals – alles in der Container-Umgebung. GitHub Codespaces geht noch weiter: Klicken Sie auf "Open in Codespaces" und die gesamte Entwicklungsumgebung läuft auf der Cloud-Infrastruktur von GitHub, nicht auf Ihrem Laptop.

Wo devcontainers punkten: Onboarding ist wirklich ein Klick. Die Sicherheitsisolierung ist real – das Container-Dateisystem ist vom Host getrennt. Für rechenintensive Aufgaben (großes Model-Training, Videorendering, Kompilieren massiver C++-Codebasen) ist das Auslagern auf Codespaces mit 32-Core-Cloud-Maschinen legitime Produktivität.

Wo devcontainers kämpfen: Docker-Overhead ist unter macOS real. Die Dateisystemleistung durch die Docker-VM-Schicht kann bei E/A-intensiven Aufgaben wie dem Ausführen einer großen Testsammlung 2- bis 3-mal langsamer sein als nativ. Sie sind außerdem von Netzwerkkonnektivität und einem funktionierenden Docker abhängig – beides ist nicht in allen Entwicklungskontexten garantiert.

Wie echte Teams diese Tools kombinieren

Die falsche Entscheidung ist, eines auszuwählen und voll darauf zu setzen. Teams, die dies herausgefunden haben, schichten typischerweise:

• mise für den täglichen Sprachwechsel. Jeder Entwickler hat es. Es beantwortet 90 % der Fragen "Welche Version von Node/Python/Go?" mit minimalem Reibungsverlust. Die .mise.toml wird ins Repository eingecheckt.
• Nix Flakes für Teams mit Systemanforderungen. Wenn Sie bestimmte Versionen nativer Bibliotheken benötigen oder sowohl unter Linux als auch macOS bauen und identische Umgebungen brauchen, lohnt sich die Investition in flake.nix. Einige Teams verwenden Nix nur für CI und sichern sich so Reproduzierbarkeit dort, wo sie am wichtigsten ist.
• devcontainers für Onboarding und CI-Parität. Die Konfiguration .devcontainer/ wird für den ersten Tag neuer Mitarbeiter und für den GitHub Codespaces-Zugriff vorgehalten. Sie ersetzt nicht die lokalen Entwicklungstools, bietet aber einen garantierten Fallback.

Ein konkretes Beispiel: Ein Team von 12 Entwicklern verwendet mise lokal für schnelles Version-Switching, Nix Flakes in CI (GitHub Actions führt nix develop --command make test aus) und einen devcontainer für den Codespaces-Zugriff, wenn Teammitglieder reisen oder auf restriktiven Firmenrechnern arbeiten.

Die ehrlichen Kompromisse

• mise: Installation in 30 Sekunden, funktioniert überall, löst 90 % der echten Probleme, kann jedoch keine Systembibliotheken verwalten oder binäre Reproduzierbarkeit unterhalb der Sprachlaufzeitebene garantieren.
• Nix: die leistungsfähigste verfügbare Option, erzeugt wirklich bit-reproduzierbare Umgebungen, deckt jede Ebene des Stacks ab, erfordert jedoch eine echte Investition zum Lernen und kann einfache Aufgaben (Hinzufügen einer neuen Paketabhängigkeit) schwergewichtig erscheinen lassen, bis die Konzepte klicken.
• devcontainers: niedrigste Einstiegshürde für Onboarding, cloud-nativ, VS-Code-nativ, trägt jedoch Docker-Overhead, erfordert Konnektivität und kann Umgebungsdetails verschleiern, was das Debuggen erschwert.

Wo anfangen

Wenn Ihr Team weniger als 5 Entwickler hat und der Schmerz ist "jeder hat andere Node-/Python-Versionen": Installieren Sie noch heute mise, committen Sie eine .mise.toml, fertig. Sie beheben 90 % der Umgebungsbeschwerden an einem Nachmittag.

Wenn Ihr Team 10+ Entwickler hat, Sie auf Linux ausliefern, native Bibliotheksabhängigkeiten haben und Umgebungsdrift bereits zu ernsthaften Produktionsvorfällen geführt hat: Investieren Sie in Nix Flakes. Planen Sie 2–3 Wochen ein, damit ein Entwickler zum Nix-Experten des Teams wird. Die Rendite ist echt.

Wenn Ihr Hauptproblem die Onboarding-Zeit ist, Sie stark mit GitHub arbeiten oder eine sichere Isolierung für Auftragnehmer benötigen: devcontainers sind der richtige Hebel. Sie lassen sich gut mit mise und Nix kombinieren – Sie können mise in einem devcontainer ausführen oder Ihr devcontainer-Image aus einer Nix-Ableitung bauen.

Das "Works on my machine"-Problem ist gelöst. Die verbleibende Frage ist, welche Lösung zu den tatsächlichen Einschränkungen Ihres Teams passt – und ob Sie bereit sind, die Lernkosten zu zahlen, die die leistungsfähigeren Optionen erfordern.