OpenClaw Mac Mini Bereitstellung 2026: Nativ oder Docker?

Der unscheinbare Neustart ist oft der erste echte Test

Ein AI Agent wirkt stabil, solange Sie ihn manuell starten, das Terminal geöffnet lassen und alle Zugangsdaten griffbereit haben. Der kritische Moment kommt häufig später: macOS installiert ein Update, Docker startet verzögert, ein Volume zeigt auf den falschen Ordner oder der Mac Mini bootet nach einem Stromausfall neu. Dann entscheidet sich, ob Ihre OpenClaw Mac Mini Bereitstellung wirklich für den Dauerbetrieb geeignet ist.

OpenClaw kann als ständig laufendes Gateway arbeiten, lokale Dateien verwenden und Nachrichtenkanäle oder externe Modellanbieter anbinden. Genau deshalb reicht es nicht, nur den Installationsbefehl auszuführen. Sie müssen auch festlegen, wo Konfigurationen liegen, wie der Prozess automatisch startet, wie der Zugriff geschützt wird und wie Sie nach einem Fehler wieder zu einem bekannten Zustand zurückkehren.

Dieser Leitfaden vergleicht die native Installation mit Docker auf dem Mac Mini. Sie erhalten keine bloße Installationsliste, sondern eine Entscheidungshilfe für langfristige Wartung, Fernzugriff, Backups und eine mögliche Migration auf eine OpenClaw Cloud-Mac-Bereitstellung.

Warum passt ein Mac Mini grundsätzlich zu einem dauerhaft laufenden AI Agent?

Ein Mac Mini eignet sich als Agent-Host, weil er nicht an einen mobilen Arbeitsplatz gebunden ist. Er kann an einem festen Standort laufen, über Ethernet erreichbar sein und lokale Arbeitsverzeichnisse dauerhaft bereitstellen. Für Aufgaben wie Dateiverarbeitung, interne Automatisierung, Nachrichtenweiterleitung oder geplante Abläufe ist diese Konstanz wichtiger als ein kurzfristig hoher Spitzenwert bei der Rechenleistung.

Die eigentliche Modellinferenz muss dabei nicht zwingend vollständig lokal erfolgen. OpenClaw kann einen Modellanbieter über API-Schlüssel verwenden, während der Mac Mini als Gateway, Dateisystem, Automationszentrale und Verbindungspunkt zu weiteren Diensten dient. Das bringt jedoch drei unterschätzte Konsequenzen mit sich:

• Zugangsdaten werden zu Betriebsdaten. API-Schlüssel, Authentifizierungsprofile und Kanalzugänge dürfen nicht in einem flüchtigen Container oder ungeschützten Projektordner liegen.
• Lokale Berechtigungen wirken dauerhaft. Ein Agent mit Zugriff auf Dokumente, Shell-Befehle oder Arbeitsverzeichnisse kann bei einer Fehlkonfiguration mehr verändern als ein gewöhnlicher Chatbot.
• Der Ausfall wird erst spät sichtbar. Wenn niemand den Mac Mini überwacht, kann ein gestoppter Gateway-Prozess stundenlang unbemerkt bleiben.

Die offizielle OpenClaw-Dokumentation nennt für den aktuellen Einstieg Node.js 22.19+, 23.11+ oder 24+, wobei Node.js 24 als empfohlene Standardversion angegeben wird. Nach der Einrichtung lauscht das Gateway standardmäßig auf Port 18789. (docs.openclaw.ai)

OpenClaw native Installation oder Docker: Welche Variante passt zu Ihrem Betrieb?

Die Frage „OpenClaw native Installation oder Docker?“ sollte nicht nur nach persönlicher Vorliebe beantwortet werden. Entscheidend ist, ob Ihr Mac Mini eher ein persönlicher Arbeitsrechner, ein reproduzierbarer Testserver oder ein kleiner Teamdienst sein soll.

Native Installation: weniger Schichten, direkter Zugriff

Bei der nativen Variante läuft OpenClaw direkt in der macOS-Umgebung. Das reduziert die Zahl zusätzlicher Komponenten. Lokale Pfade, macOS-Berechtigungen, SSH-Zugriff und systemweite Dienste sind leichter zu verstehen. Für eine einzelne Person, die den Mac Mini selbst verwaltet, ist das häufig der schnellste Weg zu einem funktionierenden Mac Mini AI Agent.

Die Nachteile liegen in der engeren Verbindung zum Host:

• Node.js-Version, globale Pakete und OpenClaw teilen sich die Umgebung mit anderen Projekten.
• Ein Update kann eine bisher funktionierende Abhängigkeit verändern.
• Ein versehentlich zu weit gefasster Dateizugriff betrifft direkt das macOS-Dateisystem.
• Ein Rollback ist schwieriger, wenn Sie keine Versionen und Konfigurationsstände dokumentiert haben.

Docker: reproduzierbarer, aber nicht automatisch einfacher

Docker trennt den Gateway-Prozess stärker vom macOS-System. Sie können ein Image austauschen, eine Compose-Datei versionieren und die Laufzeitumgebung für einen zweiten Mac Mini ähnlicher reproduzieren. Das ist besonders nützlich, wenn Sie zwischen Entwicklungs- und Produktivumgebung wechseln oder mehrere Agent-Instanzen betreiben.

Der Preis dafür ist zusätzliche Komplexität. Sie müssen Docker Desktop, Compose, Volumes, Portweiterleitungen, Containerprotokolle und Dateiberechtigungen verstehen. Außerdem ist 127.0.0.1 innerhalb eines Containers nicht automatisch der Host-Mac. Wenn ein lokaler Dienst wie Ollama oder LM Studio auf dem Mac läuft, kann je nach Setup host.docker.internal erforderlich sein. Die OpenClaw-Dokumentation weist ausdrücklich auf diesen Unterschied hin. (github.com)

Für die Auswahl können Sie folgende Regeln verwenden:

• Native Installation, wenn Sie einen einzelnen Agent auf einem eigenen Mac Mini betreiben, direkt auf lokale macOS-Dateien zugreifen müssen und möglichst wenige Wartungsschichten wünschen.
• Docker, wenn Sie Konfigurationen reproduzieren, mehrere Umgebungen trennen, Images kontrolliert aktualisieren oder einen leichteren Rollback-Mechanismus benötigen.
• Zunächst native, später Docker, wenn Sie das Konzept testen und erst danach eine standardisierte Teamumgebung aufbauen.
• Zunächst Docker, wenn der Agent von Anfang an als isolierter Dienst mit klaren Volumes, dokumentierter Compose-Datei und getrennten Zugangsdaten geplant ist.

Erfahrung aus der Praxis: Docker löst kein Berechtigungsproblem von selbst. Ein Container mit großzügigen Mounts auf Ihr Benutzerverzeichnis kann weiterhin zu viel Zugriff erhalten. Isolation entsteht erst durch bewusst begrenzte Pfade, Benutzerrechte und Netzwerkregeln.

Wie funktioniert die native OpenClaw Mac Mini Bereitstellung?

Für einen persönlichen Mac Mini ist die native Installation meist der übersichtlichere Startpunkt. Verwenden Sie den offiziellen Installationsweg und prüfen Sie nach jedem Abschnitt den tatsächlichen Zustand, statt mehrere Befehle blind hintereinander auszuführen.

Schritt 1: System und Node.js prüfen

Öffnen Sie Terminal und kontrollieren Sie zunächst die Version:

node --version
uname -m

Stellen Sie sicher, dass Ihre Node.js-Version zur aktuellen OpenClaw-Dokumentation passt. Prüfen Sie außerdem, ob der Mac Mini nach einem Neustart automatisch angemeldet beziehungsweise als Diensthost verfügbar ist. Für einen unbeaufsichtigten Betrieb sollten Sie keine Lösung planen, die nur funktioniert, solange eine grafische Sitzung geöffnet ist.

Schritt 2: OpenClaw installieren

Der offizielle macOS-Installationsbefehl lautet:

curl -fsSL https://openclaw.ai/install.sh | bash

Lesen Sie Installationsskripte vor dem Einsatz in einer produktiven Umgebung und führen Sie die Einrichtung möglichst unter einem dedizierten macOS-Benutzerkonto aus. Die offizielle OpenClaw-Installationsdokumentation beschreibt den vorgesehenen Ablauf und die anschließend verfügbaren Befehle. (docs.openclaw.ai)

Schritt 3: Onboarding und Authentifizierung durchführen

Starten Sie das Onboarding mit:

openclaw onboard --install-daemon

Dabei werden unter anderem Modellanbieter, API-Schlüssel und die Gateway-Konfiguration eingerichtet. Verwenden Sie für einen Dauerbetrieb keine gemeinsam genutzten Team-Schlüssel, wenn sich individuelle Zugänge oder getrennte Profile einrichten lassen. Speichern Sie die endgültigen Schlüssel außerdem nicht in einem öffentlich synchronisierten Repository.

Schritt 4: Gateway und Web UI prüfen

Kontrollieren Sie den Dienst:

openclaw gateway status

Öffnen Sie anschließend die lokale Oberfläche:

http://localhost:18789

Die OpenClaw-Dokumentation verwendet für die lokale Control UI ebenfalls Port 18789 beziehungsweise die Loopback-Adresse 127.0.0.1. (docs.openclaw.ai)

Wenn die Oberfläche lokal funktioniert, testen Sie mindestens eine ungefährliche Aufgabe: etwa das Lesen einer ausdrücklich freigegebenen Testdatei oder eine einfache Nachricht ohne produktive Aktion. So prüfen Sie Gateway, Authentifizierung und Werkzeugzugriff getrennt voneinander.

Schritt 5: Arbeitsverzeichnis und Sicherung festlegen

Definieren Sie vor dem produktiven Einsatz:

• einen klaren Workspace für Agent-Dateien,
• einen getrennten Ordner für Konfiguration und Sicherungen,
• einen Aufbewahrungszeitraum für Protokolle,
• eine Liste erlaubter lokaler Pfade,
• einen manuellen Wiederherstellungstest.

Die wichtigste Frage lautet nicht „Wo liegt OpenClaw?“, sondern „Welche Dateien müssen nach einem Ausfall wieder vorhanden sein?“. Dazu zählen typischerweise Konfigurationsdateien, Authentifizierungsprofile, Workspace-Inhalte, geplante Abläufe und gegebenenfalls Plugin-Daten.

Wie sieht eine saubere OpenClaw Docker Bereitstellung aus?

Eine belastbare OpenClaw Docker-Bereitstellungsanleitung sollte nicht bei docker compose up -d enden. Der Container ist austauschbar; die Daten außerhalb des Containers müssen es nicht sein. Die offizielle Docker-Anleitung setzt Docker Desktop oder Docker Engine mit Docker Compose v2 voraus und nennt mindestens 2 GB Arbeitsspeicher für den Image-Build als Richtwert. Bei nur 1 GB kann die Installation laut Dokumentation mit einem Out-of-Memory-Fehler abbrechen. (docs.openclaw.ai)

Schritt 1: Docker-Grundlagen prüfen

docker --version
docker compose version
docker info

Prüfen Sie, ob Docker Desktop läuft und ausreichend Speicher sowie Festplattenplatz verfügbar sind. Für einen Agent mit Medien, Sitzungsdateien, Logs und Plugins sollten Sie nicht nur die Größe des Images betrachten. Der Speicherbedarf wächst vor allem durch Arbeitsdaten und Protokolle.

Schritt 2: Projektordner anlegen

Erstellen Sie ein eigenes Verzeichnis für die Compose-Konfiguration:

mkdir -p ~/openclaw-docker
cd ~/openclaw-docker

Legen Sie dort keine unverschlüsselten Sicherungen von API-Schlüsseln ab. Die .env-Datei sollte durch Dateirechte geschützt und aus Versionsverwaltung ausgeschlossen werden.

Schritt 3: Offizielles Setup verwenden

Die offizielle Docker-Dokumentation beschreibt ein Setup-Skript, das unter anderem die Umgebung vorbereitet, Onboarding ausführt und den Gateway über Compose startet. Verwenden Sie bevorzugt die offiziellen Images oder bauen Sie das Image nach der dokumentierten Methode selbst. Inoffizielle Spiegelungen erschweren die Prüfung von Version, Herkunft und Aktualität. (docs.openclaw.ai)

Je nach Projektstand kann der Kernablauf beispielsweise so aussehen:

./scripts/docker/setup.sh

Führen Sie diesen Befehl im vorgesehenen OpenClaw-Projektverzeichnis aus und prüfen Sie die erzeugten Dateien, bevor Sie Zugangsdaten produktiv hinterlegen.

Schritt 4: Volumes und Bind-Mounts kontrollieren

Konfiguration, Workspace und Authentifizierungsdaten müssen außerhalb des flüchtigen Container-Dateisystems liegen. Die OpenClaw-Dokumentation beschreibt Bind-Mounts unter anderem für das OpenClaw-Konfigurationsverzeichnis, den Workspace und das Verzeichnis für Authentifizierungsgeheimnisse. (github.com)

Kontrollieren Sie deshalb:

docker compose config
docker volume ls
docker compose ps

Wenn Sie einen Container löschen und neu erstellen, dürfen Workspace und Konfiguration nicht verschwinden. Testen Sie diese Eigenschaft einmal bewusst mit einer ungefährlichen Testdatei, bevor Sie den Agent mit wichtigen Daten verbinden.

Schritt 5: Start, Logs und Web UI prüfen

docker compose up -d
docker compose ps
docker compose logs --tail=100

Danach öffnen Sie die lokale Oberfläche unter:

http://127.0.0.1:18789/

Docker Compose erstellt und startet Container mit up; bei Änderungen an Image oder Konfiguration können Container neu erstellt werden, während gemountete Volumes erhalten bleiben. (docs.docker.com)

Was ist beim Autostart wirklich wichtig?

Ein OpenClaw-Autostart besteht aus mehreren Ebenen. Der Prozess muss starten, Docker Desktop muss verfügbar sein, die Netzwerkverbindung muss stehen und die Zugangsdaten müssen lesbar sein. Deshalb sollten Sie nicht nur „Autostart aktiviert“ abhaken, sondern einen vollständigen Neustart simulieren.

Native Variante: launchd oder OpenClaw-Dienst

Bei einer nativen Installation ist der von OpenClaw eingerichtete Daemon der naheliegende Weg. macOS verwendet für Hintergrunddienste launchd. Apple dokumentiert launchd als Bestandteil der macOS-Dienstverwaltung. (developer.apple.com)

Prüfen Sie nach einem Neustart:

openclaw gateway status
launchctl list | grep -i openclaw

Vermeiden Sie es, mehrere konkurrierende Startmechanismen gleichzeitig einzurichten. Ein OpenClaw-Daemon plus PM2 plus ein eigenes Launch-Agent-Job kann zu doppelten Prozessen und Portkonflikten führen.

Docker-Variante: Restart-Richtlinie

In Compose kann eine Restart-Richtlinie wie folgt aussehen:

restart: unless-stopped

Diese Richtlinie startet den Container nach einem Prozessfehler erneut, beendet die Neustarts aber, wenn der Dienst ausdrücklich gestoppt oder entfernt wurde. (docs.docker.com)

Zusätzlich muss Docker Desktop nach dem Systemstart verfügbar sein. Prüfen Sie deshalb nicht nur den Containerstatus, sondern auch:

docker compose ps
docker compose logs --since=10m

PM2: nur mit klarer Zuständigkeit

PM2 kann für Node.js-Prozesse nützlich sein, ist aber nicht automatisch die beste Wahl für jeden Mac Mini. Wenn OpenClaw bereits einen eigenen Daemon unterstützt, sollten Sie PM2 nur einsetzen, wenn Sie die Prozessüberwachung bewusst zentralisieren. Entscheidend ist, dass genau ein Supervisor für Start, Stop und Neustart zuständig ist.

Wie sichern Sie den OpenClaw-Fernzugriff ab?

Die lokale Adresse localhost ist ein sinnvoller Anfang, weil die Web UI dadurch nicht automatisch im gesamten Netzwerk erreichbar ist. Für Fernzugriff sollten Sie nicht einfach Port 18789 an die öffentliche Internetadresse des Routers weiterleiten.

Ein sichererer Ablauf besteht aus vier Stufen:

1. Gateway zunächst ausschließlich lokal binden.
2. Authentifizierung mit Token oder Passwort aktivieren.
3. Fernzugriff über ein privates Netzwerk wie Tailscale ermöglichen.
4. Zugriff im Team auf notwendige Geräte und Benutzer begrenzen.

Tailscale unterstützt macOS ab Monterey 12.0 oder neuer, wie die aktuelle Installationsdokumentation ausweist. (tailscale.com) Für SSH-Zugriff gelten zusätzlich eigene Zugriffsregeln und Voraussetzungen. (tailscale.com)

Installieren Sie Tailscale auf dem Mac Mini und dem zugreifenden Gerät, authentifizieren Sie beide im selben privaten Netzwerk und verwenden Sie anschließend die interne Tailscale-Adresse beziehungsweise den entsprechenden Hostnamen. Öffnen Sie den OpenClaw-Port nur innerhalb dieses privaten Pfads, nicht über eine ungeschützte Portweiterleitung.

Sicherheitsprüfung vor dem Fernzugriff: Prüfen Sie mit einem Gerät außerhalb Ihres lokalen WLANs, ob Port 18789 öffentlich erreichbar ist. Wenn ja, entfernen Sie die Weiterleitung und wechseln Sie auf einen privaten Zugangsweg.

Beachten Sie außerdem die DSGVO: API-Schlüssel, Nachrichteninhalte, lokale Dokumente und Protokolle können personenbezogene oder vertrauliche Daten enthalten. Legen Sie fest, welche Daten der Agent lesen darf, wie lange Logs gespeichert werden und wer Zugriff auf das Gerät erhält. Eine Datenschutzerklärung von SpinMac kann Ihnen bei der Prüfung externer Dienstleister als Ausgangspunkt dienen; sie ersetzt jedoch keine eigene Datenschutzbewertung Ihres OpenClaw-Workflows.

Welche Fehler treten nach der Bereitstellung am häufigsten auf?

Die Web UI öffnet sich nicht

Prüfen Sie zuerst, ob der Gateway läuft:

openclaw gateway status

Bei Docker folgen:

docker compose ps
docker compose logs --tail=200

Danach kontrollieren Sie, ob Port 18789 bereits durch einen anderen Prozess belegt ist:

lsof -nP -iTCP:18789 -sTCP:LISTEN

Der Container startet, aber Daten fehlen

Das deutet meist auf einen falschen Mount-Pfad, ein neues Volume oder eine nicht geladene .env-Datei hin. Prüfen Sie mit docker compose config, welche Pfade tatsächlich verwendet werden. Achten Sie besonders darauf, ob eine Variable auf /tmp oder einen unerwarteten Benutzerordner zurückfällt.

Der Agent ist nach einem Neustart offline

Kontrollieren Sie in dieser Reihenfolge:

1. Ist der Mac Mini online?
2. Läuft Docker Desktop oder der native Daemon?
3. Ist der Prozess auf Port 18789 aktiv?
4. Sind die Konfigurations- und Authentifizierungsdateien lesbar?
5. Sind API-Schlüssel noch gültig?
6. Ist der Zugriff über Tailscale oder das lokale Netzwerk erlaubt?

Lokale Dienste sind aus Docker nicht erreichbar

Wenn OpenClaw in Docker läuft und ein Modellserver nativ auf dem Mac Mini arbeitet, zeigt 127.0.0.1 aus Sicht des Containers auf den Container selbst. Verwenden Sie je nach Dienst und Konfiguration host.docker.internal und prüfen Sie, ob der Host-Dienst Verbindungen aus dem Docker-Netzwerk akzeptiert. (github.com)

Welche Variante sollten Sie für Ihren konkreten Fall wählen?

Wählen Sie die native Installation, wenn Sie allein arbeiten, einen Mac Mini dauerhaft für OpenClaw reservieren und direkten Zugriff auf macOS-Dateien benötigen. Dokumentieren Sie dann Node.js-Version, OpenClaw-Version, Konfigurationspfad, Startdienst und Sicherungsablauf.

Wählen Sie Docker, wenn Sie eine klar getrennte Laufzeit, reproduzierbare Deployments oder mehrere Umgebungen benötigen. Planen Sie von Anfang an persistente Volumes, Versionstags, Backup-Tests und eine dokumentierte Rückkehr auf das vorherige Image ein. Verwenden Sie nicht automatisch latest, wenn ein produktiver Agent zuverlässig arbeiten muss; ein bewusst festgelegter Versionsstand erleichtert die Ursachenanalyse.

Für kleine Teams ist häufig eine Zwischenlösung sinnvoll: native Installation für den ersten Proof of Concept, anschließend Docker Compose mit festgelegten Mounts und einem privaten Fernzugriff. So vermeiden Sie, dass ein einzelner Entwicklerrechner zur undokumentierten Produktionsumgebung wird.

Wann ist eine OpenClaw Cloud-Mac-Bereitstellung sinnvoll?

Ein eigener Mac Mini ist nicht immer sofort verfügbar. Lieferengpässe, ein entfernter Standort, fehlende Wartungsmöglichkeiten oder ein schneller Proof of Concept sprechen dafür, eine OpenClaw Cloud-Mac-Bereitstellung zu prüfen. Dabei sollten Sie nicht nur den monatlichen Mietpreis vergleichen, sondern den gesamten Betriebsweg:

• Wie erhalten Sie administrativen Zugriff?
• Ist der Mac Mini dauerhaft erreichbar?
• Welche macOS-Version und welche Ressourcen sind verfügbar?
• Können Sie Tailscale oder einen vergleichbaren privaten Zugriff einrichten?
• Wie werden Daten, Snapshots und Backups behandelt?
• Wie schnell können Sie bei einem Wechsel die Konfiguration exportieren?
• Wo befinden sich Arbeitsdaten und Protokolle?

Die Migration sollte in einer festen Reihenfolge erfolgen:

1. OpenClaw-Konfiguration und Workspace inventarisieren.
2. API-Schlüssel und Tokens widerrufbar beziehungsweise neu ausstellbar machen.
3. Geheimnisse nicht als Klartext in ein Backup kopieren.
4. Node.js-, Docker- und OpenClaw-Version dokumentieren.
5. Einen nicht produktiven Test-Agent auf dem Zielsystem starten.
6. Mounts, Portbindung, Autostart und Fernzugriff prüfen.
7. Erst danach produktive Kanäle und Arbeitsverzeichnisse verbinden.

Auf der SpinMac-Übersicht für Mac-Lösungen können Sie prüfen, welche aktuelle Bereitstellungsart für Ihren Anwendungsfall angeboten wird. Für die konkreten Auswahl- und Bestellschritte finden Sie weitere Informationen auf der SpinMac-Bestellseite. Verlassen Sie sich bei Verfügbarkeit, Lieferweg oder Ressourcen nicht auf allgemeine Blogangaben, sondern prüfen Sie die zum Zeitpunkt Ihrer Anfrage angezeigten Optionen.

Native Installation oder Cloud-Mac: Wo liegen die langfristigen Nachteile?

Ein lokaler Mac Mini gibt Ihnen die größte Kontrolle, erzeugt aber auch eigene Pflichten: Sie müssen Stromversorgung, Netzwerk, Updates, Backups und Hardwareausfälle selbst absichern. Bei einem entfernten Gerät kommt zusätzlich die Frage hinzu, wie Sie bei einem blockierten Login oder einem nicht erreichbaren Dienst eingreifen.

Ein Cloud-Mac kann hier praktischer sein, wenn Sie keinen physischen Rechner bereitstellen möchten. Gegenüber einer selbst betriebenen lokalen Umgebung entfällt ein Teil der Hardwareverwaltung. Gleichzeitig entstehen aber laufende Mietkosten, eine Abhängigkeit vom Zugangs- und Supportprozess sowie zusätzliche Anforderungen an Datenschutz und Datenmigration.

Für kurze Tests ist ein eigener Kauf oft unverhältnismäßig, wenn das Gerät danach ungenutzt bleibt. Für einen langfristigen Agent mit empfindlichen lokalen Daten kann dagegen die direkte Kontrolle eines eigenen Mac Mini wichtiger sein. Die sinnvollere Entscheidung hängt deshalb weniger vom Installationsbefehl als von Ausfalltoleranz, Zugriffskontrolle und dem erwarteten Wartungsaufwand ab.

Wenn Sie heute auf einem Windows- oder Linux-Server arbeiten, sind zusätzliche Anpassungen bei macOS-spezifischen Berechtigungen und Tools möglich. Eine dauerhaft improvisierte Umgebung mit Portweiterleitungen, manuellen Neustarts und unklarer Datenablage ist langfristig meist die schwächere Lösung. Ein gemieteter Mac über SpinMac kann hier die praktischere Variante sein, wenn Sie OpenClaw remote und dauerhaft testen möchten, ohne zunächst Hardware zu beschaffen, den Standort abzusichern und den kompletten lokalen Betrieb selbst zu organisieren. Prüfen Sie dazu die aktuellen Ressourcen und Bedingungen direkt bei SpinMac und wählen Sie erst danach zwischen nativer Installation und Docker.