v26.4.9 — 25 de outubro de 2026

​

Imagens Docker personalizadas

• Crie uma imagem a partir de um ZIP de até 100 MB ou de um repositório do GitHub. A branch é opcional: sem ela, usa-se a branch padrão do repositório. Um repositório das suas instalações do GitHub App fica vinculado, então cada push reconstrói a imagem; um repositório público fora delas é construído uma vez, sem vínculo. No painel, Novo projeto também tem a opção Usar imagem Docker para criar um app a partir de uma imagem que você já tem. O projeto precisa de um arquivo chamado exatamente Dockerfile na raiz. A imagem é construída em um ambiente de build isolado, com limite de 26 minutos, e o resultado pode ter até 10 GB. Cada conta pode ter até 20 imagens.
• Verifique antes de construir. O painel analisa o seu Dockerfile antes de o build começar: instruções que enfraqueceriam o isolamento do build são recusadas, e erros comuns, como arquivos .env no projeto, são apontados para você corrigir. Arquivos .env* nunca entram na imagem, e o seu Dockerfile nunca é reescrito. Veja o que é recusado e o que gera aviso.
• Crie apps a partir da imagem. Vários apps podem compartilhar uma imagem, cada um com as próprias variáveis. Para um app web, a porta é o primeiro EXPOSE do Dockerfile, ou 80, e ela chega ao seu app como PORT. Um app criado sem web pode ser publicado depois, informando a porta.
• Atualize a imagem enviando um novo contexto, por um commit sobre o contexto atual, ou por um push para uma branch vinculada do GitHub (vincule um repositório das suas instalações do GitHub App; a branch é opcional). A GitHub Action aceita image-id para reconstruir uma imagem. Reconstruir nunca reinicia as suas aplicações: cada app passa para a nova versão quando você o reinicia ou faz deploy.
• Versões e rollback. Cada build bem-sucedido é uma versão. Os apps mantêm 30 releases por 30 dias, e um rollback inicia uma versão que já foi construída.
• Snapshots desses apps guardam os dados de /app e a versão da imagem. Ao restaurar, você também pode voltar a essa versão, se ela ainda existir.
• Renomeie e descreva. Dê uma descrição à imagem (até 128 caracteres) ao criá-la, e renomeie-a ou altere a descrição depois, no painel, na API, nos SDKs, na CLI, no servidor MCP ou na extensão do VS Code. Nada é reconstruído e os seus apps continuam rodando.
• Excluir uma imagem exclui todas as aplicações criadas a partir dela, depois que você digitar o nome da imagem.
• Na extensão do VS Code. Uma nova visualização de Docker images lista as suas imagens e os apps delas. A partir dela, você pode criar uma imagem a partir de uma pasta ou de um repositório do GitHub, reconstruí-la, acompanhar o log do build, ver as versões, vincular uma branch do GitHub, excluí-la e criar um app a partir dela. Fazer deploy, publicar e restaurar snapshots de apps de imagem também funcionam pela extensão, e um novo app a partir de uma pasta com Dockerfile oferece criar uma imagem.

​

Melhorias

• Escolha a branch dos seus deploys pelo GitHub. Ao importar um repositório do GitHub no painel, agora há um seletor de branch, e o deploy automático segue a branch que você escolher (a rota do webhook de deploy aceita um branch opcional). Os deploys automáticos já existentes continuam seguindo main e master.
• Links para desenvolvedores na barra lateral. CLI, extensão do VS Code, MCP, O que há de novo e Docs saíram do menu da conta e foram para a barra lateral do painel.
• Tema com um clique. A aparência no menu da conta agora é um único botão que alterna entre Sistema, Claro e Escuro.
• Excluir uma aplicação espera o resultado. A caixa de confirmação fica aberta com o progresso até a exclusão terminar, e então fecha com a aplicação já fora da lista. Se a exclusão falhar, a caixa continua aberta e mostra o motivo.
• Já autenticado. Abrir a página de login estando com a sessão iniciada leva direto ao painel.

​

Correções

• Importar um repositório do GitHub cujo nome contém .git no meio, como nome.github.io, não busca mais o repositório errado.
• Restaurar um snapshot (de aplicação ou de banco de dados) ou fazer rollback para uma release a partir de um arquivo danificado agora é recusado antes de qualquer alteração (INVALID_ZIP_STRUCTURE, 400). Os arquivos da aplicação e o banco de dados em execução continuam como estavam; antes, um banco podia ficar parado e os arquivos de uma aplicação podiam ser apagados. Um snapshot de aplicação sem arquivos também é recusado da mesma forma.
• Ações em aplicações, bancos de dados, snapshots, domínios e arquivos agora sempre registram a atividade no workspace ao qual o recurso pertence.
• Vincular uma aplicação ao deploy automático agora confere o repositório com a sua instalação do GitHub App. Um repo_id que não corresponde ao repositório é recusado com VALIDATION_ERROR, um repositório fora da instalação retorna INSTALLATION_NOT_FOUND, e o GitHub indisponível retorna FETCH_ZIP_ERROR (502).