> ## Documentation Index > Fetch the complete documentation index at: https://docs.vertracloud.app/llms.txt > Use this file to discover all available pages before exploring further. # v26.4.9 — 25 de outubro de 2026 > v26.4.9: imagens Docker a partir do seu Dockerfile no Enterprise 28, 30 e 32, com versões, rollback, rebuilds pelo GitHub e snapshots **v26.4.9** 25 de outubro de 2026 ### Imagens Docker personalizadas Enterprise 28, Enterprise 30 e Enterprise 32 agora podem criar uma imagem a partir do próprio `Dockerfile` e rodar aplicações a partir dela. Use para outra linguagem ou versão, pacotes de sistema, seu próprio processo de inicialização ou apps prontos. * **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](https://docs.vertracloud.app/pt-br/guides/custom-docker-images.md#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. Novas rotas da API em `/v1/images` (incluindo `PATCH /v1/images/{image_id}` para renomear e descrever) e `POST /v1/apps/image`, com os novos escopos de chave de API `images:read`, `images:write` e `images:delete` (excluir uma imagem que tenha apps também exige `apps:delete`, e enviar arquivos para um app que roda uma imagem também exige `images:write`), e os novos códigos de erro `PLAN_DOES_NOT_SUPPORT_CUSTOM_IMAGES`, `MAX_IMAGES_REACHED`, `IMAGE_NOT_FOUND`, `IMAGE_VERSION_NOT_FOUND`, `IMAGE_BUILD_IN_PROGRESS`, `IMAGE_NOT_READY`, `IMAGE_BUILDER_UNAVAILABLE`, `IMAGE_CONTEXT_TOO_LARGE`, `IMAGE_NAME_MISMATCH`, `IMAGE_TOO_LARGE`, `IMAGE_LABEL_REFUSED`, `IMAGE_VOLUME_REFUSED`, `IMAGE_APP_PORT_REQUIRED`, `IMAGE_APP_FIELD_NOT_APPLICABLE`, `IMAGE_APP_CODE_NOT_APPLICABLE`, `DOCKERFILE_NOT_FOUND` e `DOCKERFILE_REFUSED`. Leia o [guia](https://docs.vertracloud.app/pt-br/guides/custom-docker-images.md) e a [referência da API](https://docs.vertracloud.app/api-reference/endpoint/images/create.md). ### 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`). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.