Davit - UI nativa para macOS do Apple Containers

(davit.app)

15 pontos por GN⁺ 7 일 전 | 2 comentários | Compartilhar no WhatsApp

App nativo para macOS que executa e gerencia contêineres Linux na plataforma de contêineres da Apple em Macs com Apple silicon, podendo ser usado sem Docker Desktop
Comunica-se diretamente via XPC com o daemon container de código aberto da Apple, usando o mesmo caminho da CLI, sem Electron, webviews ou agente de segundo plano próprio
Faz tudo em um só app: iniciar e parar contêineres, streaming de logs, acesso ao terminal, exploração de arquivos, build de Dockerfile e importação de Compose
Disponível como app gratuito e open source sob licença MIT, assinado com Apple Developer ID e notarizado, exigindo macOS 15 ou superior em Mac com Apple silicon
Diferente do Docker Desktop, usa uma VM leve por contêiner, e quando não há contêineres em execução os serviços de segundo plano da plataforma ficam ociosos em cerca de 25MB

Objetivo do Davit e ambiente de execução

Davit é um app totalmente nativo para macOS voltado à plataforma container da Apple
Executa contêineres Linux em Apple silicon, sem precisar do Docker Desktop
É gratuito, open source e distribuído sob licença MIT
O app é assinado com Apple Developer ID e notarizado
Os requisitos são um Mac com Apple silicon rodando macOS 15 ou superior
A instalação pode ser feita pelos releases ou via Homebrew
- brew install wouterdebie/tap/davit

Comunicação direta com o daemon `container` da Apple

O Davit se comunica diretamente via XPC com o daemon de código aberto container da Apple
Esse é o mesmo caminho de comunicação usado pela CLI container
Não usa Electron, webviews nem agente de segundo plano próprio

Recursos de gerenciamento de contêineres

O dashboard mostra serviços de todos os contêineres em execução, uso de disco e CPU em tempo real
Na lista de contêineres, é possível ver o status e agir diretamente em cada linha
- iniciar, parar, reiniciar, excluir
- CPU em tempo real
- memória
- IP
A tela de cada contêiner também oferece recursos para entender o estado de execução
- logs em streaming com modos follow e boot
- gráficos de estado em tempo real
- visualização da configuração bruta
Em contêineres em execução, é possível abrir um terminal diretamente via APIs nativas
- shell interativo no Terminal ou iTerm
- sem necessidade de CLI

Edição de contêineres imutáveis e acesso a arquivos

Como os contêineres são imutáveis, o Davit permite recriá-los com um novo contêiner já pré-preenchido com base na configuração existente
A nova configuração de contêiner reflete a configuração anterior, exceto o entrypoint e o env da imagem
O fluxo é voltado para alterações rápidas de portas, variáveis de ambiente, mounts e recursos
É possível explorar o sistema de arquivos de um contêiner em execução dentro do app
- navegar entre pastas
- baixar arquivos para o Mac
- enviar arquivos
- excluir arquivos
As operações de arquivo são feitas por APIs nativas, sem precisar do comando docker cp

Importação de Compose e build de Dockerfile

O Davit pode abrir um docker-compose.yml e mostrar antes os recursos que serão criados
- serviços na ordem de dependência
- volumes
- redes
- comando CLI equivalente para cada serviço
- avisos sobre itens não suportados
Como a plataforma da Apple não tem compose nativo, o Davit orquestra a stack diretamente
A importação de Compose é voltada a um subconjunto suportado
- suporte a: image, ports, environment, named/bind volumes, networks, resource limits, command, user, working_dir
- exemplos de avisos: restart:, healthcheck:, build:
O build de Dockerfile pode ser feito em Images → Build Image
- selecionar a pasta de contexto e o Dockerfile
- definir tags e build args
- o Davit inicia diretamente o builder baseado em BuildKit da Apple e o liga se necessário
Há também limitações atuais da plataforma
- Dockerfiles acima de 16KiB são rejeitados
- isso está ligado a um bug upstream do apple/container
- o contexto de build não pode ficar em /tmp

Imagens, volumes, redes e registries

O Davit oferece suporte a operações com imagens
- pull com acompanhamento de progresso
- executar contêiner a partir de imagem
- aplicar tags
- prune
Também há operações com volumes e redes
- criar volumes com tamanho definido
- criar sub-redes personalizadas
- verificar quais itens estão em uso antes de excluir
O login em registries é feito em Settings → Registries
- Docker Hub
- ghcr.io
- quay.io
- qualquer registry OCI
As credenciais são validadas no registry antes de serem salvas
Credenciais validadas são armazenadas no keychain de login do macOS e compartilhadas com a CLI container
O Docker Hub exige o uso de access token em vez de senha

Configuração da plataforma e instalação automática

O Davit permite editar as configurações da plataforma dentro do app
- CPU/memória padrão de novos contêineres
- registries
- DNS
- recursos do builder
As configurações são validadas pelo próprio loader de configuração da plataforma e salvas como um override TOML limpo
Se a plataforma container da Apple não estiver instalada, o Davit baixa e valida o instalador assinado da Apple e o instala na Library do usuário
O processo de instalação não exige privilégios de administrador
Se necessário, também pode adicionar a CLI container ao shell

Implementação do app e fluxo inicial de uso

O Davit é implementado inteiramente em SwiftUI
Oferece ações rápidas na barra de menus
O ícone no Dock só é exibido se o usuário quiser
Não abre um navegador para renderizar gráficos em tempo real
Um fluxo inicial de exemplo é o seguinte
- instalar pelos Releases ou via Homebrew
- na primeira execução, se a plataforma não existir, o Davit a instala
- em Images → Pull Image, fazer pull de nginxdemos/hello
- executar a partir da imagem ou usar Containers → Run Container
- mapear a porta do host 8088 para a porta 80 do contêiner
- na linha Ports do contêiner, clicar em Open in Browser ou acessar localhost:8088
- explorar CPU, memória, disco, logs, arquivos, terminal e o recurso Edit & Recreate no contêiner em execução

Diferenças em relação ao Docker Desktop e ao OrbStack

O Davit usa o engine da Apple
- cada contêiner roda em sua própria VM leve baseada no Apple Virtualization framework
- possui endereço IP por contêiner
- é otimizado para Apple silicon
Usa imagens OCI
- é possível fazer pull do Docker Hub, ghcr.io, quay.io ou qualquer registry
- imagens privadas também podem ser usadas com login no registry
Faz link com as bibliotecas cliente da Apple e se comunica diretamente via XPC
- sem shim de socket
- sem contrato de licença
- sem conta
O bundle do app tem 17MB
- sem Electron
- sem imagem de VM embutida no bundle
- sem serviço de segundo plano próprio
Tem uma proposta diferente da do OrbStack
- OrbStack é um app comercial com sua própria camada de virtualização compatível com Docker
- Davit é uma UI gratuita e open source sobre a plataforma container da Apple
- no Davit, quando não há contêineres, não há itens residentes; ele usa IP por contêiner e rede em bridge, com isolamento mais forte entre contêineres
- o OrbStack é melhor em compatibilidade drop-in com CLI/API docker e em suporte a ferramentas mais amplo
- ambos executam imagens OCI padrão

Memória, DNS e segurança

A arquitetura de memória evita manter uma VM Linux de múltiplos GiB sempre ligada
O Docker Desktop mantém uma grande VM independentemente de haver contêineres em execução, enquanto a plataforma da Apple inicializa uma VM leve por contêiner e a encerra quando o contêiner para
Quando não há contêineres em execução, os serviços de segundo plano da plataforma ficam ociosos em cerca de 25MB
O próprio Davit é um app nativo em SwiftUI, não Electron, e o uso de memória é em grande parte memória compartilhada dos frameworks do macOS
Para acessar a partir do Mac pelo nome do contêiner, é possível usar o domínio DNS local da plataforma
- executar uma vez sudo container system dns create test ou usar seu próprio domínio
- definir como domínio padrão em Settings → Platform → DNS
- o contêiner web responderá como web.test no Mac
Todos os contêineres têm seu próprio IP, exibido na seção Network
Ao executar Avahi dentro do guest, é possível transmitir aliases mDNS .local
Cada release é assinado com Apple Developer ID e notarizado, abrindo sem alertas do Gatekeeper
O app é open source sob licença MIT e pode ser lido ou compilado diretamente
O Davit se comunica apenas com o daemon container local e com a verificação de atualizações no GitHub

2 comentários

galadbran 6 일 전

Era chato ter que gerenciar pela linha de comando, então é bom ver isso aparecer ^^ Hoje em dia tenho usado mais o Orbstack, no entanto.

GN⁺ 7 일 전

Comentários do Hacker News

Minha melhor estratégia na era da IA é não fazer nada
Tive uma ideia parecida e pensei que daria para criar com vibe coding, mas achei que alguém se interessaria mais e faria antes, e foi exatamente o que aconteceu
O app parece bom e estou ansioso para testar
Como ideia grátis, eu gostaria de trancar agentes dentro de uma máquina virtual e, de fora da máquina virtual, enviar instruções por um harness para controlar os agentes instalados lá dentro. Idealmente, coisas como Codex/Claude não deveriam estar instaladas no host
Um caminho ainda mais legal seria criar várias contas de usuário dentro da máquina virtual e limitar o sistema de arquivos e as políticas de rede por usuário. Assim, um agente de desenvolvimento, um agente de QA etc. teriam cada um uma visão de trabalho diferente, e isso poderia virar uma camada de base poderosa para automações adicionais
Naturalmente, também deveria ser possível “anexar” à máquina virtual vários recursos, como DBs, filas e volumes externos, para que os agentes os usem com base em permissões
- Isso é exatamente possível com o coderunner
  https://GitHub.com/instavm/coderunner
- Em vez de máquina virtual, ele usa sandbox e usuários separados, mas o sandvault é bom para esse caso de uso e também faz a instalação automática
  Por transparência, já enviei alguns PRs para ele
  https://github.com/webcoyote/sandvault
- “Power move da era da IA: não fazer nada” já era minha estratégia antes da IA
  Lá pelo fim dos meus 20 ou começo dos 30, parei quase completamente de desenvolver no tempo livre, porque toda a diversão que eu tirava de programar em si tinha desaparecido. Na verdade, eu nem gostava tanto assim; só era péssimo em decidir se algo valia ou não o meu tempo
  Mesmo quando eu pensava em um programa ou script que seria legal ter, na maioria das vezes, como naquela tabela do xkcd que calcula o tempo de retorno de criar um programa para economizar alguns minutos por semana, “a recompensa não compensava o esforço”. Ou era algo não exatamente necessário, mas interessante ou divertido de ter, só que exigiria inúmeras horas para realmente construir, então não valia nada a pena
  Se alguém criasse e publicasse algo que eu queria, ótimo; se não, paciência
  A grande mudança que os LLMs trouxeram é que agora dá para gerar coisas como pequenos scripts em alguns minutos, por alguns centavos até alguns dólares. Estou ressuscitando ideias extremamente de nicho que estavam guardadas havia muito tempo
  Coisas que antes levariam alguns fins de semana só fuçando APIs e documentação desconhecidas agora podem ser feitas em menos de 30 minutos ou, no mínimo, dá para decidir em minutos, em vez de horas, se aquilo não vai funcionar ou é chato demais e deve ser abandonado para sempre
- Fiz algo parecido meio no improviso, com um frontend simples de navegador
  Gosto de rodar modelos abertos médios/grandes, mas não dá para confiar que eles não vão sair fazendo besteira, então criei isso e pretendo compartilhar em breve
- Eu também já pensei nisso
  Parece algo simples como instalar o Claude em uma máquina virtual e acessar por um terminal SSH. Se precisar de GUI, dá para usar a extensão Remote SSH do VSCode e obter algo como uma UI de navegador de arquivos
  Imagino que também dê para instalar dentro da máquina virtual o Claude do VSCode ou outras extensões de chat
O que chamou mais atenção do que este projeto em si foi que um fenômeno que muita gente conseguia prever, especialmente no último ano mais ou menos, ficou visivelmente mais acelerado. Agora as pessoas conseguem criar suas próprias versões da mesma ideia muito mais rápido do que antes
Em uns 10 minutos procurando, encontrei vários projetos Swift parecidos, e a maioria existe há apenas algumas semanas ou meses
https://github.com/tdeverx/contained-app
https://github.com/nico81/iContainer
https://github.com/wouterdebie/davit
https://github.com/Augani/dory
https://github.com/tofa84/berth
https://github.com/erdaltoprak/ContainerUtility
https://github.com/andrew-waters/orchard
Havia ainda mais se incluir os que têm menos estrelas no GitHub, os que são só de linha de comando e os que não são em Swift, mas o ponto é este
As pessoas terão cada vez mais condições de criar por conta própria suas versões do software que desejam. Quando isso acontecer, o valor do software feito por outras pessoas diminui. A era do software hiperpersonalizado está chegando
- Será que dá para dizer que todos esses projetos têm qualidade de primeira linha de forma equivalente? Não tenho como saber ao certo
  Antigamente, dava para estimar o esforço investido em algo assim pela qualidade do site ou por alguns elementos superficiais. Agora essas partes são resolvidas facilmente com LLMs
  De modo parecido, depois que a poeira baixou, um dos maiores impactos deixados pelo Kickstarter foi a evolução agressiva e o refinamento dos vídeos de pitch de 3 minutos
  Não sei se isso realmente se traduz em uma implementação e um roadmap bem pensados, nem em tração real
- No iOS é diferente. Para publicar na App Store, você precisa pagar a assinatura anual, ou então recompilar e reinstalar builds de conta pessoal a cada 30 dias, mais ou menos
Parece um app realmente sólido. Tem 17 MB, e gostei do fato de ele usar diretamente a biblioteca ContainerAPIClient
28 commits em 3 dias, 5.015 linhas de Swift, e todos os commits têm “Co-Authored-By: Claude Fable 5”
Também é bom ver que ele é assinado e notarizado. Instalei, e na primeira execução ele baixou os componentes necessários da plataforma de contêineres
Como sugestão, seria bom adicionar ao site um tutorial de início, recomendando uma imagem para testar e mostrando, com capturas de tela ou um vídeo sem áudio, como executar essa imagem e o que dá para fazer com ela
A caixa de diálogo de criação de imagem sugere “nginx:latest”, mas ela não é tão boa como demo inicial
- O texto de AI-Maxing no site deixou isso um pouco evidente. Isso não quer dizer que não seja um ótimo app
- Boa sugestão. Vou adicionar em breve
- Acho que um tutorial com um exemplo um pouco mais realista ajudaria bastante aqui
  nginx:latest mostra que o encanamento funciona, mas não mostra muito bem onde o Apple Containers parece diferente do Docker Desktop ou do OrbStack
  Um exemplo com um app pequeno, volumes, mapeamento de portas e um loop simples de rebuild provavelmente deixaria o valor muito mais fácil de perceber
Ha! Parece que nós também criamos a mesma coisa: https://container-ui.fly.dev/
Agora fico pensando que talvez não devesse ter queimado tantos tokens
- Oi. Acabei de ver que há uma comparação com o Orchard, e sou eu
  Parece bem limpo. No fim, estamos todos criando a mesma coisa ><
Tenho usado e gostado do OrbStack há quase 2 anos
Ele é bem integrado, rápido e tem compatibilidade com comandos docker, então para mim valeu pagar
Ainda assim, vou testar este também
- Os contêineres nativos do macOS parecem iniciar uma máquina virtual Linux separada para cada contêiner
  O ponto forte do OrbStack é que todos os contêineres rodam dentro de uma única máquina virtual Linux, com muitas otimizações dos dois lados da fronteira da VM. Isso inclui o uso de arquivos de imagem esparsos, que economizam bastante espaço em disco no lado do macOS
  Quando você roda mais de 4 ou 5 contêineres no macOS, os ganhos de desempenho e de redução de uso de recursos do OrbStack crescem rapidamente
- Acho que a equipe do OrbStack vai adicionar suporte a contêineres nativos do macOS em breve e colocar os recursos de gerenciamento deles por cima
Muito bom. Baixar o runtime e executar nginx:latest funcionou perfeitamente
Quando você rola para baixo no GitHub e vê o Claude como contribuidor, isso está começando a virar um sinal de que o app será bom. No sentido de parecer nativo e não ser Electron
Gostaria que a Apple adicionasse compatibilidade com a API do docker ao Apple Containers
- Também não sei bem. Dá para usar isso no lugar do Docker Desktop para rodar contêineres docker de forma “nativa” no meu Mac? Ou é algo totalmente separado do docker?
- Isto é focado em builds, rodando buildkitd ou dockerd dentro de um contêiner do Apple containerization
  Não há coisas como encaminhamento de portas ou volumes do host. Na prática, o foco é rodar buildkit no Mac
  Dito isso, ele se integra totalmente com o docker CLI e o buildx
  https://github.com/cpuguy83/crucible
As funcionalidades são boas, e também gosto do fato de ser um pequeno app nativo em SwiftUI
Escrevi recentemente um texto [1] sobre usar contêineres da Apple para codificação agentic e acabei de atualizá-lo para mencionar o Davit. Para projetos pessoais, nos meus dois Macs de casa, prefiro muito mais usar contêineres da Apple do que Docker
[1] https://open.substack.com/pub/marklwatson/p/running-opencode...
Como ele se compara ao OrbStack? O Apple Containers oferece algo perceptível na experiência de desenvolvimento? Pelo meu uso, a implementação do OrbStack já parece absurdamente rápida
Alguns dias atrás eu publiquei uma versão parecida que criei, mas quase não teve reação
Para quem se interessar, é um app de barra de menus com suporte a contêineres, máquinas e registries
https://news.ycombinator.com/item?id=48789503
https://github.com/erdaltoprak/ContainerUtility