OpenDesign é local-first mesmo? O que roda na sua máquina e como o proxy BYOK trata o tráfego

Fala aí, beleza? A pergunta que trava a adoção de qualquer ferramenta nova de IA dentro de um time não é "isso é bom?"

É "o que sai da minha máquina quando eu clico em gerar?"

O OpenDesign é mantido pelo time nexu.io, o código vive em nexu-io/open-design e a licença é Apache License 2.0, com copyright dos Open Design contributors (alguns templates empacotados mantêm licença própria, como design-templates/guizang-ppt/ e design-templates/html-ppt/, em MIT)

O produto é gratuito e não tem assinatura própria: o gasto é o da API do provedor que você traz

Só que "gratuito e open source" não responde a pergunta de segurança de ninguém

Então bora separar o que é desenho local do que é chamada remota, usando só o que está escrito no repositório e na documentação do projeto 🙂

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

O que roda na sua máquina: app desktop, daemon e runtime

A proposta declarada é local-first, e ela tem três peças bem definidas

O app desktop é construído como um shell Electron, com renderer sandboxed e IPC de sidecar

O daemon é o cérebro da coisa: ele resolve projeto, design system, skill principal ou template, skills por turno e metadados de execução

E aí sobe o runtime tendo o workspace do projeto como diretório de trabalho, transmitindo os eventos normalizados por SSE de volta pra interface

Por que isso importa antes do "como"? Porque o cwd do runtime ser o seu workspace é o que faz o resultado nascer como arquivo no projeto, e não como registro num banco de terceiro

Se você quiser ver o miolo dessa parte, as definições de runtime vivem em apps/daemon/src/runtimes/defs/, com registro e tratamento de stream compartilhado em apps/daemon/src/runtimes/

O setup mínimo pra usar é bem enxuto: um daemon local mais um agente de código, tipo Claude Code, Codex, Cursor, Gemini CLI ou outro adaptador suportado

E repara no detalhe que muita gente confunde: o daemon ser local não impede ele de chamar um modelo remoto

A versão mais recente publicada nos releases é a 0.20.2, de 21/08/2026

Como o proxy BYOK trata o tráfego e onde fica a sua chave

BYOK é "bring your own key", traz a tua própria chave

No desenho do OpenDesign, as credenciais ficam em configuração local ou em variáveis de ambiente, o Open Design não faz proxy delas e a cobrança da API cai direto pra você

Quem faz a chamada HTTP é o daemon, da sua máquina, com a sua chave

A página do projeto afirma que não fazem proxy, não logam e não veem os prompts

Registro isso como declaração do projeto, e não como algo que a gente foi lá conferir no fio: quem precisa levar esse argumento pra uma revisão interna vai ter que ler o código e olhar o tráfego por conta

O importante do ponto de vista de arquitetura é que não existe servidor do OpenDesign no caminho: o daemon conversa diretamente com o endpoint do provedor escolhido

O proxy BYOK é multi-provedor e cobre Anthropic, OpenAI, Azure, Google e Ollama, além de presets compatíveis com OpenAI, todos atrás da mesma guarda SSRF

A presença do Ollama aí na lista é o caminho de quem quer fechar o circuito de vez, com o modelo rodando na própria máquina em vez de sair pra internet

A borda do daemon: bind em loopback e bloqueio SSRF por destino

Esse é o ponto que costuma decidir a conversa com o time de segurança

O daemon faz bind em 127.0.0.1 por padrão, ou seja, loopback: nada de escutar na rede sem você mandar

O comportamento é read-only por padrão

E o SSRF é bloqueado na borda do proxy

Que SSRF? É quando você consegue fazer o servidor (aqui, o daemon) disparar requisição pra um destino que ele não deveria alcançar, tipo um serviço interno da empresa ou o endpoint de metadados da nuvem, usando a máquina dele como trampolim

Como o proxy aceita base URL de provedor customizada, esse é justamente o campo que um atacante ia querer apontar pra dentro

Por isso a proteção é por DESTINO: base URLs de provedor que resolvem para faixas privadas ou internas são bloqueadas por padrão, incluindo RFC1918, link-local, CGNAT e IPs de metadados de nuvem

Numa máquina dentro de rede corporativa ou numa VM em nuvem, isso é a diferença entre uma ferramenta de design e uma porta lateral pro que está atrás do firewall

Expor o daemon na LAN: o que muda e o que continua trancado

Sair do loopback não acontece por acidente, é decisão explícita

Pra expor o daemon na LAN você precisa configurar duas variáveis de ambiente: OD_BIND_HOST mais OD_ALLOWED_ORIGINS

Duas, não uma

E tem um limite que permanece mesmo depois disso: credenciais de conector e rotas de preview de artefato vivo continuam restritas a loopback, independentemente da configuração

Ou seja, mesmo o cara que abriu o daemon pra rede não abriu tudo junto

Tome cuidado assim mesmo: expor um daemon com a sua chave de API dentro dele numa rede compartilhada é o tipo de escolha que precisa passar pelo time, não pelo "ah, deixa aberto que é mais fácil de testar"

Preview em iframe sandboxed: isolamento e o efeito colateral conhecido

Previews de artefato e de plugin rodam em iframes sandboxed, sem acesso same-origin ao host

A lógica é a mesma de qualquer sandbox: o conteúdo gerado é tratado como não confiável, então cada superfície ativa apenas os recursos de sandbox de que precisa, tipo downloads ou popups

Massa do ponto de vista de segurança

Agora a parte honesta: isolamento tem custo, e nesse caso ele já tem nome e número

Existe issue aberta reportando que o iframe do preview de artefato HTML bloqueia localStorage e cookies, gerando SecurityError (a issue #1403)

Então se o seu artefato depende de estado no navegador pra funcionar, o preview pode não representar direito o que aquele HTML faz fora dali

Vale saber disso antes de apresentar a ferramenta e tomar a pergunta na frente do time 😛

Como justificar o OpenDesign para o time (e quando não justificar)

Traduzindo o desenho pra argumento de revisão interna, os pontos a favor são estes:

• código aberto sob Apache-2.0, auditável, no repositório nexu-io/open-design
• sem assinatura própria do produto: o gasto é o da API do provedor que você traz
• artefatos gerados como arquivos no diretório do projeto, não numa nuvem de fornecedor
• superfície de rede restrita a loopback por padrão, com read-only por padrão e SSRF bloqueado na borda do proxy

E agora os contrapontos, porque post que só elogia não serve pra decidir nada

O modelo continua remoto se você usar provedor remoto. Local-first aqui é sobre app, daemon, runtime e artefatos, não sobre inferência: o prompt sai da máquina do mesmo jeito quando o provedor é uma API na nuvem

A instalação a partir do fonte tem issue aberta. Os pré-requisitos declarados são Node 24 e pnpm 10.33.2, e o caminho é curto:

git clone https://github.com/nexu-io/open-design
cd open-design
pnpm install

O daemon e a UI web sobem via tools-dev, descrito como o único ponto de entrada de ciclo de vida, com as flags --daemon-port e --web-port

O erro comum aqui não é seu: a issue #2801 relata que a instalação a partir do fonte está quebrada de ponta a ponta, com od fora do PATH, porta padrão errada, pré-requisitos faltando e documentação citando skills que não existem

Se o seu objetivo é só avaliar, um caminho menos escorregadio é começar por algo com passo a passo de instalação já mastigado e voltar pro OpenDesign quando a doc estabilizar

O produto ainda está se mexendo por baixo. O runtime estruturado de design system que chegou na versão 0.19.2 foi revertido, e os design systems voltaram ao comportamento anterior de manifesto e prompt enquanto o fluxo é retrabalhado

Isso não é defeito fatal, é sinal de projeto em movimento: só entra na conversa com o time como risco de mudança, não como "está pronto e estável"

Vídeo: o contexto de IA rodando no seu próprio PC

Pra pegar o pano de fundo do conceito de IA que roda na sua máquina, este vídeo do canal mostra uma IA gratuita rodando localmente no PC:

Conclusão

O que dá pra afirmar com base na documentação e no repositório: o OpenDesign local-first coloca app desktop, daemon e runtime de skills na sua máquina, entrega os artefatos como arquivos no projeto, não põe servidor próprio no caminho e deixa o daemon em loopback por padrão, com read-only e bloqueio de SSRF por destino na borda do proxy

O que continua sendo escolha sua: qual provedor a chave BYOK vai chamar, e se esse provedor é remoto ou local

O próximo passo concreto antes de levar isso pro time é chato e necessário: abrir o repositório nexu-io/open-design, conferir a licença Apache-2.0 (e as licenças próprias dos templates empacotados) e dar uma passada nas issues abertas, principalmente a #2801 e a #1403

Decisão de ferramenta com prova na mão é bem mais fácil de defender numa reunião…

Até o próximo post! =)