Ferramentas local-first: um manifesto para times Oracle
Ferramentas SaaS que roteiam credenciais por um servidor remoto não são apenas inconvenientes para times Oracle — elas falham na primeira pergunta que qualquer auditoria séria faz.

O mercado de ferramentas Oracle tem um problema de credenciais escondido à vista de todos.
Todo SaaS IDE lançado nos últimos cinco anos tem a mesma arquitetura: você cola sua string de conexão num campo do navegador, o servidor do fornecedor negocia a conexão, e seus dados fluem por uma infraestrutura que você não provisionou e não consegue auditar. O certificado TLS é exibido como se fosse uma resposta. Não é. É um aperto de mão numa porta que você não controla.
Times Oracle que levam segurança a sério aprenderam isso do jeito difícil. Times de compliance bloqueiam solicitações de ferramentas. Revisões de segurança emperram. O departamento de compras passa meses num DPA que nunca cobre direito o que o servidor do fornecedor realmente faz com as strings de conexão. O desenvolvedor acaba de volta no SQL Developer, que pelo menos mantém as credenciais na máquina.
Isso não é uma preocupação de nicho. É a condição padrão de quem escreve Oracle em bancos, seguradoras, sistemas de saúde ou qualquer empresa que passou por uma auditoria SOC 2 ou ISO 27001. O auditor faz uma pergunta: onde ficam as credenciais? Se a resposta envolve a nuvem do fornecedor, a conversa termina ali.
Local-first significa que o comportamento padrão da ferramenta é manter credenciais, conexões e resultados de queries na máquina do desenvolvedor. Não como um modo de privacidade que você ativa nas configurações. Não como uma camada on-premise que exige um contrato enterprise separado. Como o padrão de fábrica.
A Veesker armazena credenciais no keychain do sistema operacional — DPAPI no Windows, Keychain no macOS, Secret Service no Linux. As conexões são negociadas pelo binário local usando a própria biblioteca cliente da Oracle. Nenhum servidor intermediário vê o handshake. Os recursos de IA trabalham contra seu schema local, não uma cópia em nuvem.
Quando você opta por ativar a camada Cloud — sandboxes compartilhados, contexto de IA persistente, bibliotecas de queries do time — a arquitetura mantém a mesma postura. Os dados são criptografados ponta a ponta com X25519 + ChaCha20-Poly1305 antes de sair da sua máquina. O relay vê apenas texto cifrado. Somos arquiteturalmente incapazes de ler seus dados, mesmo que quiséssemos.
É isso que local-first significa na prática: o padrão é proteção, e o opt-in adiciona capacidade sem removê-la.
Ferramentas de desenvolvimento Oracle não deveriam forçar uma escolha entre UX moderna e um rastro de auditoria limpo. Esse é exatamente o problema de design que a Veesker foi construída para resolver.
Se a sua ferramenta atual roteia credenciais pelo servidor de outra pessoa, baixe a Veesker e veja como é o padrão correto.
— Veesker