Docker Build Terminal Mac: Builds neben SSH-Deploys

Den Workspace teilen: Ein Pane baut, ein Pane deployt

Mit Cmd+D teilen Sie das fokussierte Pane nach rechts, mit Cmd+Shift+D nach unten. Der Windows-Build belegt diese Aktionen mit Ctrl+D und Ctrl+Shift+D. Führen Sie docker build -t myapp . oder docker compose up --build in einem Pane aus.

Öffnen Sie im anderen Pane eine SSH-Sitzung zu Ihrem Zielserver (oder nutzen Sie eine bestehende). Wenn der Build fertig ist, können Sie das neue Image per docker pull holen oder den Stack neu starten.

Sobald Sie zwei oder mehr Panes haben, ziehen Sie den Kopf eines Panes an den Rand eines anderen. MXterm Pro hebt die Zone unter dem Mauszeiger hervor: Die Mitte eines Panes bedeutet Bereiche tauschen, der nächstgelegene Rand bedeutet Einfügen links, rechts, oberhalb oder unterhalb. Beim Loslassen setzt MXterm Pro das Pane dort ab. Ein eingefügtes Pane beginnt immer mit einer gleichmäßigen Aufteilung von 50/50.

Auch Trennlinien rasten ein: Lassen Sie eine innerhalb von etwa 3,5 % von der Mitte los, und sie springt auf 50/50. Ein Doppelklick auf eine Trennlinie setzt sie auf 50/50 zurück. Cmd+Shift+M maximiert das fokussierte Pane vorübergehend, was beim Lesen eines langen Build-Logs im Vollbild hilft. Schalten Sie es erneut um, um für den Deploy zur Ansicht mit zwei Panes zurückzukehren.

Beide Panes sind echte Terminal-Sitzungen über ein echtes PTY: dasselbe portable-pty-Rust-Backend wie bei jedem Pane, kein Wrapper darum herum. docker logs -f, docker stats und docker exec laufen deshalb in einer echten Shell, und es muss nichts Docker-spezifisches konfiguriert werden.

Wem das tatsächlich hilft

Dieser Aufbau für Docker-Build und SSH-Deploy passt zu Leuten, die ein Image lokal bauen (oder den Build per SSH anstoßen) und es dann von Hand auf einen VPS oder einen kleinen Cloud-Server pushen oder pullen. Dazu zählen Indie-Entwickler, kleine Teams ohne vollständige CI/CD-Pipeline und alle, die mit einem KI-Coding-Agent ein Dockerfile iterieren und den Build an Ort und Stelle erneut starten wollen.

Ist Ihr Deploy vollständig automatisiert, spielt das zweite Pane eine kleinere Rolle. Eine CI-Pipeline baut, pusht und rollt den Container bei jedem Merge aus, es gibt also keinen manuellen Moment zwischen „Build fertig“ und „Server führt es aus“. Der Pane-Kniff lohnt sich im manuellen oder halbmanuellen Mittelschritt.

Einen Build beobachten, während ein KI-Agent das Dockerfile bearbeitet

Setzen Sie einen Coding-Agent (Claude Code, Codex, Gemini CLI, Copilot) in ein Pane und daneben ein Build-Pane. Ändert der Agent das Dockerfile oder eine Compose-Datei, starten Sie den Build im Nachbar-Pane erneut, ohne den Kontext zu wechseln. Die Änderungen des Agents und die Build-Ausgabe bleiben gemeinsam auf dem Bildschirm.

Das integrierte Feld Command Recipes (Cmd+J) enthält einen festen Satz fertiger Befehle für alltägliche Aufgaben. Es ist kein allgemeiner Befehlsgenerator. Für Docker erkennt es zwei Absichten: Bitten Sie es, Container aufzulisten, liefert es docker ps -a && docker stats --no-stream. Bitten Sie es aufzuräumen, liefert es docker system prune -af --volumes.

Einen docker build-Befehl schreibt es nicht, es erfindet keine --entrypoint-Overrides und ermittelt keine Bind-Mount-Flags für Sie. Die tippen Sie selbst, wie in jedem Terminal.

Die Worktree-Isolierung ist ein optionales Kontrollkästchen im Workspace-Composer. Standardmäßig ist sie ausgeschaltet und funktioniert nur in git-Repositories. Aktivieren Sie Features in git worktrees isolieren, dann bearbeitet der Agent das Dockerfile in seinem eigenen Checkout unter <repo>/.worktrees/<slug> auf einem neuen Branch swarm/<adjective>-<noun>, zum Beispiel swarm/brave-otter. Ihr Build-Pane beobachtet weiterhin den normalen Arbeitsbaum im Repo-Root.

Das verringert die Wahrscheinlichkeit, dass der Agent eine Datei ändert, die Ihr Build gerade liest. Sie können die Dockerfile-Änderung des Agents prüfen und mergen, bevor Ihr eigener Build sie übernimmt.

Eine Datei auf den Server bringen, bevor der Container startet

Manche Deploys brauchen vor dem sauberen Containerstart eine Datei auf dem Server: eine .env-Datei, ein TLS-Zertifikat, einen Config-Mount. Der integrierte SFTP-Browser erledigt das ohne separaten FTP-Client. Öffnen Sie den Server über die SSH-Verwaltung, damit sein Tab das SFTP-Panel hat, und ziehen Sie die Datei hinüber.

Erwartet der Container einen bestimmten Modus, klicken Sie mit der rechten Maustaste auf die Datei, wählen Sie Dateiberechtigungen (Chmod) und setzen Sie die Kontrollkästchen oder eine der Voreinstellungen (755, 644, 777, 600).

Liegt die Datei schon auf dem Server (ein Dockerfile, nginx.conf, .env* oder eine YAML-Compose-Datei), doppelklicken Sie sie im SFTP-Panel. Sie öffnet sich zum Bearbeiten auf dem Remote-Host mit Syntaxhervorhebung, und Sie sparen sich Download, lokale Bearbeitung und erneuten Upload.

Der Chmod-Dialog und das Bearbeiten auf dem Server sind beide im Free-Tarif verfügbar.

Free-Tarif und Pro-Tarif für diesen Ablauf

Der Free-Tarif hat standardmäßig kein Pane-Limit und erlaubt 5 gespeicherte SSH-Hosts und 1 gespeicherten Rechner. Der Pro-Tarif hat keine Obergrenze für Hosts.

MXterm Pro im Vergleich zu iTerm2, Warp, Termius und MobaXterm

iTerm2 ist kostenlos und ausgereift, und seine Split Panes samt tmux-Integration beherrschen dieses Muster aus lokalem Build und Remote-Deploy gut. Wenn Sie nur den Mac nutzen und weder eine integrierte SSH-Host-Liste noch einen SFTP-Browser oder KI-Agents im selben Fenster brauchen, genügen ein paar iTerm2-Splits.

Der Unterschied von MXterm Pro für diesen Ablauf: Die SSH-Host-Verwaltung, ein integrierter SFTP-Browser und der Control Room (früher War Room) für mehrere Agents liegen im selben Fenster wie das Build-Pane. Bei iTerm2 ergänzen Sie in der Regel einen separaten SFTP-Client und eine eigene Lösung, um Ihre Serverliste zu führen.

Warp ist auf Befehlsblöcke und integrierte KI ausgelegt, mit moderner, GPU-gerenderter Oberfläche. Es ist stark, wenn der Ablauf „die KI fragen, einen Befehl ausführen, die Ausgabe lesen“ lautet. MXterm Pro dreht sich um mehrere echte Terminals und Agents in einem geteilten Layout.

Termius ist ein starker plattformübergreifender SSH-Client mit synchronisierten Hosts und eigenem SFTP, besonders nützlich, wenn Sie Server auch vom Smartphone aus verwalten. Er hat außerdem eine geteilte Ansicht und lokale Terminals. Er ist aber auf gespeicherte Hosts und Sitzungen ausgelegt, nicht auf einen Workspace für Build und Deploy mit KI-Agents.

MobaXterm ist MXterm Pro im Ansatz am ähnlichsten: Tab-Sitzungen, ein grafischer SFTP-Browser in der Seitenleiste und Makros, die vertraut wirken, wenn Sie es schon für genau dieses Docker-plus-SSH-Muster nutzen. MXterm Pro ist eine neuere Tauri-App, die nach demselben Prinzip „Terminal und SFTP in einem Fenster“ gebaut ist. Sie läuft auf macOS, mit einem nicht signierten Windows-x64-Build, und ergänzt die Multi-Agent-Ebene, die MobaXterm nicht hat.