Terminal para Docker en Mac: builds junto a tus deploys por SSH

Divide el espacio de trabajo: un panel compila y otro despliega

Pulsa Cmd+D para dividir el panel con foco hacia la derecha, o Cmd+Shift+D para dividirlo hacia abajo. La build de Windows usa Ctrl+D y Ctrl+Shift+D. Ejecuta docker build -t myapp . o docker compose up --build en uno de los paneles.

En el otro, abre o reutiliza una sesión SSH a tu servidor de destino, lista para ejecutar docker pull con la imagen nueva o reiniciar el stack cuando termine la build.

Cuando tengas dos o más paneles, arrastra el encabezado de uno hacia el borde de otro. MXterm Pro resalta la zona bajo el puntero: el centro de un panel es Intercambiar paneles, y el borde más cercano inserta el panel a la izquierda, a la derecha, arriba o abajo. Al soltar, MXterm Pro coloca el panel ahí. Un panel insertado siempre empieza con una división igual, 50/50.

Los divisores también se acoplan al centro: suelta uno a menos de un 3,5 % del centro (aproximadamente) y queda en 50/50. Haz doble clic en un divisor para volver a 50/50. Cmd+Shift+M maximiza el panel con foco de forma temporal, útil para leer un log largo de build a pantalla completa. Púlsalo otra vez para volver a la vista de dos paneles durante el deploy.

Ambos paneles son sesiones de terminal reales sobre un PTY real: el mismo backend portable-pty en Rust que usa cada panel, no un envoltorio sobre otra cosa. Por eso docker logs -f, docker stats y docker exec se ejecutan en un shell real, y no hay nada específico de Docker que configurar.

A quién le sirve de verdad

Este flujo de build con Docker y deploy por SSH encaja con quien construye una imagen en local (o lanza la build por SSH) y luego la sube o la descarga a mano en un VPS o en una máquina pequeña en la nube. Es el caso de desarrolladores independientes, equipos pequeños sin un pipeline completo de CI/CD y cualquiera que use un agente de código con IA para iterar sobre un Dockerfile y quiera repetir la build en el mismo sitio.

Si tu deploy está totalmente automatizado, el segundo panel importa menos. Un pipeline de CI construye, sube y despliega el contenedor en cada merge, así que no hay un momento manual entre "la build terminó" y "el servidor ya lo ejecuta". El truco de los paneles se justifica en ese paso intermedio manual o semimanual.

Ver una build mientras un agente de IA edita el Dockerfile

Pon un agente de código (Claude Code, Codex, Gemini CLI, Copilot) en un panel y un panel de build a su lado. Cuando el agente cambie el Dockerfile o un archivo de compose, repite la build en el panel contiguo sin cambiar de contexto. Las ediciones del agente y la salida de la build quedan juntas en pantalla.

La caja integrada de Command Recipes (Cmd+J) contiene un conjunto fijo de comandos listos para tareas cotidianas. No es un generador de comandos general. Para Docker reconoce dos intenciones: si le pides listar contenedores, te da docker ps -a && docker stats --no-stream; si le pides limpiar, te da docker system prune -af --volumes.

No escribirá un comando docker build, ni inventará overrides de --entrypoint, ni calculará por ti las opciones de bind mount. Esos los escribes tú, como en cualquier terminal.

El aislamiento con worktrees es una casilla opcional en el Composer de la pestaña nueva. Viene desactivada por defecto y solo funciona en repositorios git. Marca Aislar funciones en git worktrees y el agente edita el Dockerfile en su propia copia de trabajo <repo>/.worktrees/<slug>, en una rama nueva swarm/<adjective>-<noun>, por ejemplo swarm/brave-otter. Tu panel de build sigue mirando el árbol de trabajo normal en la raíz del repositorio.

Eso reduce la probabilidad de que el agente edite un archivo que tu build está leyendo en ese momento. Puedes revisar e integrar el cambio del agente en el Dockerfile antes de que tu propia build lo recoja.

Subir un archivo al servidor antes de que arranque el contenedor

Algunos deploys necesitan un archivo en el servidor antes de que el contenedor arranque bien: un archivo .env, un certificado TLS, un montaje de configuración. El navegador SFTP integrado lo resuelve sin un cliente FTP aparte. Abre el servidor desde el administrador SSH para que su pestaña tenga el panel SFTP y arrastra el archivo.

Si el contenedor espera un modo concreto, haz clic derecho en el archivo, elige Permisos de archivo... (chmod) y marca las casillas o uno de los valores predefinidos (755, 644, 777, 600).

Si el archivo ya está en el servidor (un Dockerfile, nginx.conf, .env* o un compose en YAML), haz doble clic sobre él en el panel SFTP. Se abre para editarlo en el host remoto con resaltado de sintaxis, así te ahorras descargarlo, editarlo en local y volver a subirlo.

El diálogo de chmod y la edición remota están disponibles en el plan Free.

Free frente a Pro en este flujo

Por defecto, el plan Free no tiene límite de paneles y permite 5 hosts SSH guardados y 1 MXterm Host guardado. El plan Pro no tiene tope de hosts.

MXterm Pro frente a iTerm2, Warp, Termius y MobaXterm en este caso

iTerm2 es gratis y maduro, y sus paneles divididos junto con la integración con tmux resuelven bien este patrón de build local y deploy remoto. Si solo usas Mac y no necesitas una lista de hosts SSH integrada, un navegador SFTP ni agentes de IA en la misma ventana, un par de divisiones de iTerm2 bastan.

La diferencia de MXterm Pro para este flujo es que el administrador de hosts SSH, un navegador SFTP integrado y la Control Room (antes War Room) multiagente viven en la misma ventana que el panel de build. Con iTerm2 normalmente añadirías un cliente SFTP aparte y tu propia forma de llevar la lista de servidores.

Warp se construye en torno a bloques de comandos e IA integrada, con una interfaz moderna renderizada por GPU. Funciona mejor cuando el flujo es "pregunto a la IA, ejecuto un comando, leo la salida". MXterm Pro se centra en varias terminales reales y agentes en un mismo layout dividido.

Termius es un cliente SSH multiplataforma sólido, con hosts sincronizados y su propio SFTP, sobre todo útil si también administras servidores desde el celular. También tiene vista dividida y terminales locales. Aun así, gira en torno a hosts y sesiones guardados, no en torno a un espacio de trabajo de build y deploy con agentes de IA.

MobaXterm es el más parecido en espíritu: sesiones en pestañas, un navegador SFTP gráfico en la barra lateral y macros que te resultarán familiares si ya lo usas justo para este patrón de Docker más SSH. MXterm Pro es una app Tauri más nueva, construida con la misma idea de "terminal y SFTP en una ventana". Funciona en macOS, con una build de Windows x64 sin firmar, y añade la capa multiagente que MobaXterm no tiene.