Terminal para docker build no Mac: builds ao lado de deploys por SSH
Deixe seu terminal para docker build no Mac e a sessão SSH de deploy lado a lado: docker build (ou docker compose up --build) em um painel, o servidor no painel ao lado. No MXterm Pro, a divisão é um atalho (Cmd+D). Os dois são shells reais sobre um PTY real, então docker logs -f e a sessão SSH se comportam como na linha de comando, sem nenhuma integração com o Docker para aprender.
Divida o espaço de trabalho: um painel faz o build, outro faz o deploy
Pressione Cmd+D para dividir o painel em foco à direita, ou Cmd+Shift+D para dividir para baixo. A versão para Windows usa Ctrl+D e Ctrl+Shift+D, . Rode docker build -t myapp . ou docker compose up --build em um dos painéis.
No outro, abra ou reaproveite uma sessão SSH com o servidor de destino, pronta para docker pull na nova imagem ou para reiniciar a stack quando o build terminar.
Com dois ou mais painéis, arraste o cabeçalho de um painel até a borda de outro. O MXterm Pro destaca a zona sob o ponteiro: o meio do painel é Trocar painéis, e a borda mais próxima é Inserir à esquerda, à direita, acima ou abaixo. Ao soltar, ele encaixa o painel ali. Um painel inserido sempre começa numa divisão igual de 50/50.
Os divisores também encaixam: se você soltar um divisor a cerca de 3,5% do centro ou menos, ele fica em 50/50. Clique duas vezes num divisor para voltar a 50/50. Cmd+Shift+M maximiza temporariamente o painel em foco, o que ajuda a ler um log de build longo em tela cheia. Use de novo para voltar aos dois painéis do deploy.
Os dois painéis são sessões de terminal reais sobre um PTY real: o mesmo backend portable-pty em Rust que todo painel usa, não um wrapper em cima dele. Por isso docker logs -f, docker stats e docker exec rodam num shell de verdade, e nada específico do Docker precisa de configuração.
Para quem isso realmente serve
Este esquema de build com Docker e deploy por SSH serve para quem monta uma imagem localmente (ou dispara o build por SSH) e depois envia ou puxa a imagem para uma VPS ou uma máquina pequena na nuvem, à mão. Isso inclui devs independentes, equipes pequenas sem pipeline completo de CI/CD e quem usa um agente de código com IA para iterar num Dockerfile e quer rodar o build de novo ali mesmo.
Se o seu deploy é totalmente automatizado, o segundo painel importa menos. Um pipeline de CI faz o build, envia e atualiza o container a cada merge, então não há um momento manual entre "o build terminou" e "o servidor está rodando". O truque dos painéis vale no passo manual ou semimanual do meio.
Guia relacionadoComo rodar Claude Code e Codex em paralelo em painéis de terminal divididosAcompanhar um build enquanto um agente de IA edita o Dockerfile
Coloque um agente de código (Claude Code, Codex, Gemini CLI, Copilot) em um painel e um painel de build ao lado. Quando o agente muda o Dockerfile ou um arquivo compose, rode o build de novo no painel vizinho sem trocar de contexto. As edições do agente e a saída do build ficam juntas na tela.
A caixa Command Recipes embutida (Cmd+J) guarda um conjunto fixo de comandos prontos para tarefas do dia a dia. Ela não é um gerador de comandos geral. Para Docker, reconhece duas intenções: peça para listar containers e ela entrega docker ps -a && docker stats --no-stream; peça para limpar e ela entrega docker system prune -af --volumes.
Ela não escreve um comando docker build, não inventa overrides de --entrypoint nem monta as flags de bind mount por você. Esses você digita, como em qualquer terminal.
O isolamento com worktree é uma caixa opcional na tela de nova aba (Composer). Vem desativada por padrão e só funciona em repositórios git. Marque Isolar funcionalidades em git worktrees e o agente edita o Dockerfile no próprio checkout <repo>/.worktrees/<slug>, em uma nova branch swarm/<adjective>-<noun>, por exemplo swarm/brave-otter. Seu painel de build continua olhando a árvore de trabalho normal, na raiz do repositório.
Isso reduz a chance de o agente editar um arquivo que o seu build está lendo. Você pode revisar e fazer o merge da mudança do agente no Dockerfile antes de o seu próprio build usá-la.
Levar um arquivo ao servidor antes de o container subir
Alguns deploys precisam de um arquivo no servidor antes de o container subir direito: um arquivo .env, um certificado TLS, um mount de configuração. O navegador SFTP embutido resolve isso sem um cliente FTP separado. Abra o servidor pelo gerenciador SSH para que a aba dele tenha o painel SFTP e arraste o arquivo.
Se o container espera uma permissão específica, clique com o botão direito no arquivo, escolha Alterar permissões (Chmod) e marque as caixas ou um dos presets (755, 644, 777, 600).
Se o arquivo já está no servidor (um Dockerfile, nginx.conf, .env* ou um compose em YAML), clique duas vezes nele no painel SFTP. Ele abre para edição no host remoto, com destaque de sintaxe, e você pula o download, a edição local e o novo envio.
O diálogo de permissões e a edição remota estão disponíveis no plano Free.
Free x Pro neste fluxo
Por padrão, o plano Free não tem limite de painéis e permite 5 hosts SSH salvos e 1 Máquina salva. O plano Pro não tem limite de hosts.
MXterm Pro x iTerm2, Warp, Termius e MobaXterm neste caso
O iTerm2 é gratuito e maduro, e seus painéis divididos mais a integração com tmux resolvem bem esse padrão de build local e deploy remoto. Se você só usa Mac e não precisa de lista de hosts SSH, navegador SFTP ou agentes de IA na mesma janela, algumas divisões do iTerm2 dão conta.
A diferença do MXterm Pro neste fluxo é que o gerenciador de hosts SSH, um navegador SFTP embutido e a Control Room (antes War Room) multiagente ficam na mesma janela do painel de build. No iTerm2 você normalmente adicionaria um cliente SFTP separado e seu próprio jeito de controlar a lista de servidores.
O Warp gira em torno de blocos de comando e IA embutida, com uma interface moderna renderizada na GPU. Ele é forte quando o fluxo é "pergunte à IA, rode um comando, leia a saída". O MXterm Pro se concentra em vários terminais reais e agentes numa só divisão.
O Termius é um bom cliente SSH multiplataforma, com hosts sincronizados e SFTP próprio, útil principalmente se você também gerencia servidores pelo celular. Ele também tem visão dividida e terminais locais. Mas é construído em torno de hosts e sessões salvos, não de um espaço de build e deploy com agentes de IA.
O MobaXterm é o mais parecido em espírito: sessões em abas, um navegador SFTP gráfico na barra lateral e macros que parecem familiares se você já o usa justamente para esse padrão de Docker mais SSH. O MXterm Pro é um app Tauri mais novo, feito no mesmo estilo de "terminal e SFTP numa janela só". Roda no macOS, com uma versão Windows x64 sem assinatura, e acrescenta a camada multiagente que o MobaXterm não tem.
SSH com vários painéis, Command Recipes (Cmd+J) e uma Control Room (antes War Room) multiagente: comece grátis.
Já tem o MXterm Pro? Leia o guia de configuração →
Novo no MXterm Pro? Veja os preços →
Perguntas frequentes
Não. O MXterm Pro não substitui o Docker Desktop nem oferece um gerenciador gráfico de containers. É um app de terminal, então os comandos do Docker rodam em um painel como qualquer outro comando.
Sim. Se você entra por SSH em um servidor com Docker instalado, docker build roda lá exatamente como rodaria em qualquer outra conexão SSH.
Só dois. Peça para listar os containers em execução e ele devolve docker ps -a && docker stats --no-stream. Peça para limpar e ele devolve docker system prune -af --volumes. Ele não roda docker build e não inventa flags personalizadas como bind mounts ou overrides de --entrypoint. Esses você digita à mão, como em qualquer outro lugar.
Pressione Cmd+D para dividir o painel em foco à direita, ou Cmd+Shift+D para dividir para baixo. A versão para Windows usa Ctrl+D e Ctrl+Shift+D. Com dois painéis, você também pode arrastar o cabeçalho de um painel até a borda de outro para reencaixá-lo ali.