Container machines: um ambiente Linux persistente no Mac

A ferramenta container da Apple chegou à versão 1.0 durante a semana da WWDC, e o recurso de destaque preenche uma lacuna que os desenvolvedores Mac contornam há anos: o container machine, um ambiente Linux persistente que se comporta como parte do macOS.² A sessão da WWDC que o apresenta resume a proposta em uma única frase: “Um Container machine é rápido e leve, como um container, e persistente como uma máquina virtual.”¹ Os seus repositórios e dotfiles ficam disponíveis dos dois lados, o usuário de login corresponde à sua conta do Mac, e a máquina mantém o seu sistema de arquivos entre sessões, de modo que a toolchain Linux que você configurou na terça-feira ainda está lá na sexta.³

Sessão 389, “Discover container machines.”

TL;DR

• O container machine faz parte do container 1.0.0, lançado no GitHub durante a semana da WWDC. Ele oferece “ambientes Linux de longa duração com integração estreita ao host” sobre o framework Containerization que a Apple abriu como código aberto na WWDC 2025.²
• Enquanto os containers são “modelados a partir de uma aplicação”, um container machine é “modelado a partir de um ambiente Linux”: ele executa o próprio sistema de init da imagem, persiste mudanças no sistema de arquivos e é criado a partir de imagens OCI padrão.³
• A integração com o host é o diferencial. O usuário de login do Linux corresponde à sua conta do Mac com sudo sem senha, e o seu diretório home é montado dentro da máquina,⁴ e um shell interativo coloca você no mesmo diretório de trabalho de onde você veio no macOS.¹
• O conjunto completo de subcomandos é create, run, list, inspect, set, set-default, logs, stop e delete, com m como apelido curto.⁴
• O lançamento da 1.0 também traz uma mudança incompatível que vale a pena conhecer antes de atualizar: um arquivo de configuração TOML em ~/.config/container/config.toml substitui as antigas propriedades de sistema baseadas em UserDefaults, e os subcomandos container system property foram removidos.²

Um ambiente Linux, não um sandbox de aplicação

A documentação da Apple traça a linha com precisão: “Os containers normalmente são modelados a partir de uma aplicação. Um container machine é modelado a partir de um ambiente Linux.”³ A distinção aparece em três comportamentos. Um container machine executa o próprio sistema de init da imagem, como systemd ou openrc, de modo que você pode registrar serviços de longa duração e testar a sua aplicação sob um supervisor de processos real: systemctl start postgresql funciona da mesma forma que em uma máquina Linux.³ Ele persiste modificações, então as ferramentas que você instala se acumulam ao longo do tempo em vez de desaparecerem junto com o processo.¹ E ele inicializa a partir das mesmas imagens OCI que os containers usam, de modo que uma imagem que você cria com container build serve também como ponto de partida para uma máquina.¹

O pull request que introduziu o recurso expõe a motivação de forma direta: o container executa cada workload em uma VM efêmera, então, antes da 1.0, não havia uma forma integrada de manter um ambiente Linux persistente no qual você pudesse fazer login e trabalhar.⁴ Por baixo dos panos, cada container machine ainda recebe o tratamento Containerization: a sua própria máquina virtual leve, com isolamento baseado em VM e os tempos de inicialização abaixo de um segundo em torno dos quais o framework foi construído.¹

A sessão enquadra os objetivos de design em termos de fluxo de trabalho: alternar entre macOS e Linux deve ser fácil, os ambientes devem ser rápidos de criar, e “a criação rápida permite que múltiplos projetos tenham o seu próprio ambiente dedicado, sem a preocupação de dependências ou toolchains conflitantes.”¹ Uma máquina por distribuição de destino é um padrão pretendido, e cada máquina enxerga o mesmo diretório home e os mesmos dotfiles do seu Mac.³

O ciclo: editar no Mac, compilar dentro do Linux

A demonstração da sessão é um servidor web Vapor, e o fluxo de trabalho que ela percorre é exatamente o ponto central.¹ O projeto é editado no Xcode no macOS. A compilação e a execução acontecem dentro de um container machine com a toolchain Swift instalada. O Safari no Mac carrega o servidor em execução pelo endereço IP e pela porta. Quando o apresentador reexporta um ícone de app do Icon Composer no Mac e sobrescreve o arquivo, atualizar o navegador mostra o novo asset sem nenhuma etapa de cópia, porque a máquina e o Mac compartilham os mesmos arquivos.¹

A documentação da Apple generaliza o padrão: o seu repositório fica em $HOME no macOS e é montado dentro da máquina, de modo que as ferramentas nativas do macOS (profilers, navegadores, depuradores gráficos) enxergam os mesmos arquivos que o ambiente Linux enxerga. Como diz a documentação, não há etapa de cópia entre “eu compilei” e “eu estou inspecionando”.³

A integração com o host vai mais fundo do que uma montagem compartilhada. A máquina cria automaticamente um usuário Linux correspondente ao seu nome de usuário do Mac, concede a ele sudo sem senha e espelha o seu diretório de trabalho atual, de modo que whoami e pwd respondem o mesmo dentro e fora.¹ O único comando que muda a sua resposta é uname: Darwin no Mac, Linux na máquina.¹

Há um ponto de atrito no primeiro dia que vale a pena conhecer antes de esbarrar nele: um container machine tem uma rede isolada, e a sessão é explícita ao dizer que um servidor dentro dele precisa escutar na interface externa antes que um navegador no Mac consiga alcançá-lo.¹ A demonstração lida com isso da forma que você fará: container machine list exibe o endereço IP de cada máquina ao lado do seu nome e recursos, a configuração do servidor faz o bind nesse endereço, e o Safari alcança o app pelo IP e pela porta da máquina.¹ Planeje a etapa do endereço IP em qualquer fluxo de trabalho que sirva tráfego a partir da máquina.

Os comandos

O início rápido tem quatro linhas:³

container machine create alpine:latest --name dev
container machine run -n dev whoami       # your host username, not root
container machine run -n dev pwd          # your Mac home directory, mounted in
container machine run -n dev              # interactive shell

O container machine run cumpre uma dupla função: com um comando, ele executa uma vez e sai; sem nenhum, abre um shell interativo; e, se a máquina estiver parada, ele a inicializa primeiro.³ Uma máquina padrão remove a flag -n de cada chamada:

container machine set-default dev
container machine run                     # operates on dev

O gerenciamento usa os verbos familiares: ls, inspect, logs, stop e rm, sendo que excluir uma máquina remove também o seu armazenamento persistente.³ Os recursos são ajustáveis após a criação com container machine set -n dev cpus=4 memory=8G, entrando em vigor na próxima parada e inicialização; a memória tem como padrão metade da memória do host, e a montagem do home pode ser rw (o padrão), ro ou none.³ Todo comando também aceita m como apelido, então m run e m ls funcionam.⁴

Traga a sua própria imagem de máquina

Qualquer imagem Linux que inclua /sbin/init funciona como um container machine.³ A documentação da Apple traz um Dockerfile pronto que transforma ubuntu:24.04 em uma imagem de máquina com systemd, OpenSSH e ferramentas de linha de comando comuns, e então mascara as units do systemd que não fazem sentido dentro de uma VM leve.³ Você a compila com container build e passa a tag para container machine create.

O provisionamento tem uma saída de emergência. Por padrão, o container executa um script de configuração integrado na primeira inicialização para criar o usuário correspondente. Um executável em /etc/machine/create-user.sh na imagem substitui esse script; ele é executado uma vez, como root, na primeira inicialização, com CONTAINER_USER, CONTAINER_UID, CONTAINER_GID, CONTAINER_HOME e CONTAINER_MACHINE_ID definidos, de modo que uma organização pode codificar a sua própria configuração de usuário em uma imagem base compartilhada.³

O restante da 1.0, incluindo a mudança incompatível

O recurso de máquina é o destaque do lançamento, mas a 1.0 traz mudanças que afetam os usuários existentes.²

A incompatível é a de configuração. Um arquivo TOML substitui as propriedades de sistema baseadas em UserDefaults, e os subcomandos container system property get e set foram removidos.² O serviço lê ~/.config/container/config.toml na inicialização, com precedência de primeira correspondência (o seu arquivo de usuário, depois um arquivo opcional incluído na instalação do pacote, depois os padrões fixos no código), e as mudanças exigem uma reinicialização do serviço para entrarem em vigor.⁶

As adições de qualidade de vida: um comando container cp para copiar arquivos, uma opção --stop-signal no container run, e uma saída estruturada (JSON, YAML, TOML) reorganizada para os comandos ls e inspect em containers, imagens, redes e volumes.² A rede ganha uma correção de exatidão que usa conexões XPC como leases para impedir vazamentos de endereço IP.² A compatibilidade com as APIs XPC da versão 0 foi removida, com uma API versionada prometida em um lançamento futuro.²

Os requisitos se mantêm estáveis em relação à linha 0.x: um Mac com Apple silicon, executando macOS 26. Os mantenedores afirmam que normalmente não tratarão problemas que não possam ser reproduzidos no macOS 26.⁵

Por que os fluxos de trabalho com agentes deveriam se importar

Uma leitura a partir de onde eu estou, não uma afirmação da Apple: um container machine é o formato de ambiente que os agentes de código querem. Agentes rodando em um Mac precisam de algum lugar para executar builds, rodar servidores e instalar dependências sem tocar no host: rápido de criar, isolado por uma fronteira de VM real, persistente o suficiente para que uma toolchain instalada em uma sessão sobreviva até a próxima. Até agora, as respostas no Mac eram VMs no estilo Docker Desktop (pesadas, um único grande ambiente compartilhado) ou containers efêmeros (isolados, mas sem memória). Uma máquina por projeto, criada a partir de uma imagem OCI versionada, com o repositório montado dentro e sudo sem senha por dentro, corresponde à forma como os sandboxes de agentes já funcionam em hosts Linux.

A mesma propriedade serve ao trabalho multiplataforma comum. O Swift no lado do servidor é o beneficiário óbvio: a demonstração da sessão é o Vapor, e o framework Foundation Models vira código aberto neste verão com suporte a Linux, então o ambiente de teste para “o meu código Swift roda no Ubuntu?” está agora a um container machine create de distância. A comparação que ocorrerá a qualquer um que tenha usado o Windows é com o WSL, e a direção da integração é a mesma: um kernel Linux real a um shell de distância, com os seus arquivos visíveis dos dois lados. A versão da Apple chega com um fluxo de trabalho baseado em imagens já incorporado.

FAQ

O que é um container machine?

Um container machine é um ambiente Linux persistente no macOS, oferecido como recurso da ferramenta de código aberto container da Apple a partir da versão 1.0.0.² Ele roda na sua própria máquina virtual leve por meio do framework Containerization, inicializa a partir de imagens OCI padrão, executa o sistema de init da imagem e persiste mudanças no sistema de arquivos entre sessões.¹ As integrações com o host montam o seu diretório home por dentro, fazem o usuário Linux corresponder à sua conta do Mac com sudo sem senha e mantêm o seu diretório de trabalho consistente através da fronteira.⁴

Como ele é diferente de um container comum?

A documentação da Apple resume em uma linha: os containers são “modelados a partir de uma aplicação”, e um container machine é “modelado a partir de um ambiente Linux”.³ Um workload comum de container run é efêmero e centrado em processos. Uma máquina é stateful, executa systemd ou openrc e foi feita para ser revisitada ao longo do tempo, como uma VM com a velocidade de criação de um container.¹

O que ele exige?

Um Mac com Apple silicon executando macOS 26, os mesmos requisitos da ferramenta container em geral.⁵ A ferramenta é de código aberto no GitHub, escrita em Swift.⁵

Atualizar para a 1.0 quebra alguma coisa?

Uma coisa: a configuração do sistema migra das propriedades baseadas em UserDefaults para um arquivo TOML em ~/.config/container/config.toml, e os subcomandos container system property get/set foram removidos.² As notas de lançamento da 1.0 incluem um link para um tutorial sobre a migração.² A compatibilidade com a API XPC da versão 0 também foi removida, o que importa caso você tenha criado clientes contra a API.²

Os container machines se encaixam na mesma história que esta WWDC não parou de contar: o Mac como um lar sério para o desenvolvimento multiplataforma e com agentes. Executando IA com agentes no Mac com MLX cobre a parte de servir modelos dessa história, e O que há de novo no Swift (2026) cobre o trabalho de linguagem que torna o Swift no Linux um destino de primeira classe. O hub completo da série é a Série Apple Ecosystem.

Referências