Pular para o conteúdo principal

Notas de versão

Esta página registra o que muda para quem usa o Zero. Mudanças internas que não alteram o que você vê ou faz não entram aqui.

Setembro de 2026​

28 de setembro​

Rede entre projetos. Dentro da organização, um projeto não alcança outro pela rede interna — nem quando os dois estão na mesma rede. A tela Redes cria a rede; cada projeto entra nela com um dos seus ambientes, na tela Rede do projeto; e o dono do serviço chamado usa Autorizar projeto para abrir aquele serviço, pela porta dele, para um projeto. A permissão passa de Ainda não liberado a Liberado quando a plataforma a aplica, e revogar bloqueia as conexões novas. Ver Rede entre projetos.

Projeto interno. Um projeto pode ser Interno (sem acesso pela internet): sem endereço público, sem pré-visualização de pull request, alcançável só pela rede. Crie já interno em Novo projeto, ou mude em Exposição do projeto: os endereços públicos ficam retidos para o projeto e voltam se ele voltar a ser público. Ver Projeto interno.

Nome interno por serviço. Cada serviço pode ter um nome na rede, <nome>.zero.internal, único na rede e resolvido pela rede de quem pergunta — duas redes podem ter, cada uma, o seu api. O nome não abre acesso: só chega ao serviço quem tem permissão. Ver Nome interno.

Entradas internas do Gateway. Em Conectividade, uma entrada interna dá à rede um endereço como api.zero.internal, com caminhos por prefixo ou exatos levando a serviços diferentes — as rotas do Gateway, sem endereço na internet — e a lista de quem pode chamá-la. Ver Entradas internas do Gateway.

CLI, SDKs e agentes. A CLI ganha zero networks, zero entries, zero projects network, zero projects exposure, zero projects create --internal e zero services internal-name, com confirmação digitada nas mudanças que cortam tráfego e --wait para esperar a regra ser aplicada. Os SDKs de TypeScript e Go têm as operações da rede. O servidor MCP lê a rede e as entradas internas, mas não abre tráfego entre projetos em modo nenhum. Ver Ferramentas.

22 de setembro​

Usuários e acesso, sem convite. A tela Usuários mostra as pessoas do provedor de identidade da organização, com busca, e o acesso de cada uma ao Zero. Conceder acesso vale na hora — não há convite nem aceite — e a pessoa recebe um e-mail que só avisa do acesso, com o link de entrada normal. Criar usuário cria a conta no provedor sem senha: o provedor envia o e-mail oficial para a pessoa defini-la, e o Zero nunca vê a senha. Revogar acesso tira a pessoa da organização na hora e mantém a conta dela no provedor. Os links de convite antigos deixaram de valer. Uma conta sem acesso que entra vê "Sua conta existe, mas ainda não possui acesso ao Zero." — e não cria mais a própria organização. Ver Usuários e acesso.

http:// redireciona para https://. Um endereço publicado acessado por http:// recebia um erro de tempo esgotado. Agora ele responde com um redirecionamento permanente para https://, preservando o endereço, o caminho e os parâmetros — no domínio da plataforma e no seu domínio próprio.

O endereço que sai de uso continua da sua organização, sem prazo. Excluir um projeto ou trocar o endereço de um serviço deixa o endereço anterior reservado à sua organização: nenhuma outra organização pode usá-lo, e um projeto seu pode voltar a usá-lo quando quiser. O prazo de 90 dias anunciado em 21 de setembro deixou de existir — um webhook ou callback cadastrado num terceiro continua apontando para o endereço muito depois disso. Ver Trocar o endereço e Excluir o projeto.

21 de setembro​

O endereço de um projeto excluído fica com a sua organização. Excluir o projeto deixava o endereço público livre para qualquer organização no mesmo instante — e quem o pedisse primeiro passaria a receber os links, callbacks de login e webhooks que ainda apontavam para ele. Agora o endereço deixa de servir e fica reservado à sua organização por 90 dias: outra organização não consegue usá-lo, e um projeto novo seu pode. Depois do prazo, ele volta a ficar disponível. Ver Excluir o projeto.

Aplicações em domínio próprio ganham o registro de DNS sozinhas. Um endereço sob a sua subzona — loja.apps.acme.com.br — aparecia como publicado sem que o nome existisse no DNS. O Zero passou a criar o registro de cada endereço de aplicação na subzona, e a removê-lo quando o endereço deixa de servir. Os endereços respondem em https://. Ver Domínio próprio.

A publicação que não sobe agora falha, e diz por quê. Antes, depois de 5 minutos de espera, a publicação terminava Online mesmo sem a aplicação responder. Agora ela falha com o motivo — APPLICATION_NOT_STARTED, APPLICATION_CRASHED_ON_START ou HEALTH_CHECK_FAILED — e a ação, na tela, na API e na CLI. Nada é trocado: a versão anterior, se havia, continua respondendo. Motivos definitivos encerram em cerca de 30 segundos, sem esperar o prazo. Ver Estados da publicação.

A linha do tempo narra a espera. Enquanto a plataforma espera a aplicação ficar pronta, a publicação diz o que está acontecendo — "A aplicação iniciou, mas ainda não aceita conexão na porta 8080.", "O ambiente ainda não conseguiu baixar a imagem desta versão.". "Versão N está no ar." só aparece quando a prontidão foi observada.

A escada de evidência chega a 4 de 4. "Aplicação respondendo" passou a ser registrada quando as instâncias ficam prontas — antes a tela parava em 2 de 4. "Endereço confirmado" vem de tráfego real, respondido pela aplicação; uma resposta gerada pela plataforma quando não alcança a aplicação não conta. Uma publicação recém-feita fica em 3 de 4 até a primeira requisição real. Ver Acompanhar uma publicação.

Imagens sem USER passam a rodar. O processo roda sempre como usuário não-root, com UID e GID 10001, qualquer que seja o USER da imagem. Imagens sem USER — como a maioria das oficiais de linguagem, por exemplo node:18-alpine — e imagens com USER por nome, como USER node, eram recusadas antes de o container existir; agora funcionam. O contrato completo — sistema de arquivos somente leitura, /tmp gravável até 512 MiB, HOME em /tmp, PORT com padrão 8080, prontidão por conexão TCP — está em Como a aplicação roda.

Publicação em andamento, sem recarregar e com detalhes. Depois de publicar, a publicação aparece na hora em Deployments, na seção Publicação em andamento, com o nome da etapa em curso e quem publicou. Ver detalhes existe desde o primeiro segundo: etapas e narração da plataforma ao vivo, e Abrir o Deployment quando ele nasce. O Deployment entra na tabela sozinho, a coluna Origem mostra o commit publicado e a coluna Autor, o nome de quem publicou.

Um endereço por serviço, e a troca que diz o que libera. Endereços antigos não se acumulam mais. Trocar o endereço em Domínios pede confirmação e republica a versão no ar com o endereço novo, sem reconstruir — aparece em Deployments como Troca de endereço. O anterior deixa de responder quando o novo fica no ar, sem intervalo sem endereço, e fica livre para qualquer pessoa usar. Ver Trocar o endereço.

A origem é do projeto, com GitHub, GitLab e Bitbucket. Um repositório por projeto; os serviços escolhem só a pasta e a referência. O campo aceita URL completa, endereço SSH ou dono/repo, e o GitLab aceita subgrupos. Salvar origem diz o que falta no endereço, e o token de acesso nunca volta para a tela. Ver A origem do projeto.

Excluir projeto, com o histórico preservado. Excluir pede o nome do projeto, digitado, e aceita um motivo, que fica na auditoria. Depois de concluída a exclusão, o projeto some de toda leitura, o nome fica livre, a fila é cancelada e a origem é revogada; auditoria, operações, deployments e versões continuam registrados. Ver Excluir o projeto.

Domínio próprio disponível. A criação de zonas está disponível. A delegação é conferida em três camadas, e o estado Propagação pendente, normal nos primeiros minutos, é verificado de novo sozinho. Para nomes no nível principal, sem subzona, há o caminho Manter meu DNS atual. Ver Domínio próprio.

CLI, SDKs e MCP. zero deploy sai com 0 quando a publicação fica pronta e 1 quando falha, com o motivo. Chegaram zero projects delete e zero source set. Nos SDKs, a troca de endereço devolve operation_id e previous, um domínio pode estar em releasing, e campo que pode vir nulo passou a ser tipado como anulável. O servidor MCP foi regenerado do mesmo contrato. Ver Ferramentas.

Agosto de 2026​

Promoção entre ambientes, sem reconstruir. A versão aprovada num ambiente sobe noutro exatamente como está — mesma imagem, identificada pelo conteúdo. "O mesmo commit, reconstruído" produz outro artefato, e o Zero não finge que é o mesmo. Disponível no console, na CLI (zero promote) e na API. Ver Promover entre ambientes.

Escala e disponibilidade numa tela só. O número de instâncias, o autoscaling e o tamanho de cada instância passaram a viver juntos, na ordem em que se pergunta. A tela mostra quantas instâncias estão no ar, e não só quantas foram pedidas. Ver Escala e disponibilidade.

Alta disponibilidade automática. As instâncias de um serviço passaram a ser distribuídas entre máquinas diferentes, e manutenções retiram uma por vez. Não é opção a ligar: vale para toda aplicação publicada, a partir da próxima publicação. A proteção é contra falha de máquina, não de zona — e isso está escrito na tela.

Ferramentas para baixar. A CLI, o servidor MCP para agentes de IA e os SDKs de TypeScript e Go passaram a ter um lugar oficial de obtenção, com checksums publicados: zero.nnumbers.com.br/downloads. Ver Ferramentas.

Site do produto. zero.nnumbers.com.br passou a responder com o site do Zero. Antes o endereço devolvia 404 para quem chegasse pelo navegador.

Vocabulário do produto. As telas passaram a usar instâncias, tamanho da instância, autoscaling e alta disponibilidade — cada termo responde a uma pergunta real, e "autoscaling" ficou no nome que o público técnico reconhece.

Domínio próprio por subzona delegada. A organização pode delegar uma subzona do domínio da empresa — apps.acme.com.br — e publicar aplicações sob ela. A delegação é feita uma única vez, com quatro registros NS, e o console traz o passo a passo do provedor de DNS que você usa. Nenhuma credencial de DNS é pedida ou armazenada. Ver Domínio próprio.

A zona vem antes do endereço. Na criação do projeto, a escolha do domínio aparece antes da escolha do endereço, porque a zona é a base dele. A conferência de disponibilidade passou a ser sobre o endereço final, e não sobre o nome dentro da organização.

Histórico de tentativas de publicação. Publicações que falham antes de comprometer uma versão — repositório inacessível, branch inexistente — passaram a aparecer no projeto, com o motivo. Antes elas desapareciam.

Recursos e limites por serviço. Reservado, máximo, aplicado e uso observado aparecem lado a lado. Salvar republica o serviço com a mesma imagem e a tela acompanha a operação até o desfecho.

Capacidades declaradas pelo servidor. Telas cuja capacidade não existe nesta instalação passaram a dizer isso, com a frase que o servidor manda, em vez de mostrar "não encontrado".

Julho de 2026​

Console reorganizado em torno do projeto. O projeto passou a ser um lugar, e não um filtro: a navegação entra nele e a barra lateral troca de conteúdo. A palavra "aplicação" saiu da interface — o projeto é a aplicação. A camada de serviço aparece somente quando existe mais de um.

Production nasce com o projeto. Não é mais necessário criar um ambiente antes de publicar pela primeira vez.

Log de build gravado nos dois desfechos. A saída do construtor passou a ser guardada também nas publicações bem-sucedidas — o que permite investigar um build lento ou que produziu a imagem errada.

Observabilidade com três silêncios distintos. "Coleta não configurada", "coletando, sem tráfego" e "coletando, com tráfego" deixaram de ser o mesmo "sem dados". Ausência deixou de virar zero em todas as leituras.

Próximos passos​