Pular para o conteúdo principal
​
8 de novembro de 2026

​
Atualização automática dos apps de uma imagem Docker

As imagens ganharam a opção Atualizar os apps automaticamente após cada build. Quando está ligada, todo build bem-sucedido da imagem (um push no GitHub, um upload ou um rebuild manual) reinicia na versão nova os apps dessa imagem que estão rodando. Apps parados continuam parados, e um app que falha ao atualizar não impede os outros: a falha aparece nas atividades. Veja Imagens Docker personalizadas.
  • Padrão: uma imagem criada a partir do GitHub começa com a opção ligada; as demais começam desligadas. Mude na página da imagem.
  • Aba Deploys: um app que roda a partir de uma imagem agora mostra de qual imagem o deploy vem e se a atualização automática está ligada. O vínculo com o GitHub fica na imagem, não no app.
  • Mesmas regras de qualquer deploy: deploy sem downtime e rollback automático valem quando o seu plano inclui.

​
Aviso mais visível sobre WORKDIR /app

Em runtime /app é o disco persistente do app, montado por cima da imagem, então o que a imagem coloca ali fica oculto. A verificação agora avisa sobre WORKDIR /app só no estágio final do Dockerfile (um estágio de build de um multi-stage não gera mais aviso), e os avisos de cada build, inclusive os disparados por push no GitHub, ficam guardados na imagem. O painel mostra uma faixa na página da imagem e um aviso na aba Deploys dos apps que usam a imagem, e pede confirmação ao criar um app a partir dela. Para corrigir, use outro diretório (como WORKDIR /srv) e faça um novo build. Veja Imagens Docker próprias.

​
API e MCP

​
Idioma do site e dos e-mails

  • Site: no primeiro acesso, o site abre em português quando você acessa do Brasil ou de outro país de língua portuguesa, e em espanhol a partir de um país de língua espanhola, mesmo com o navegador em outro idioma. Nos demais países, continua valendo o idioma do navegador. O idioma que você escolher no seletor de idioma sempre vale e fica guardado.
  • Conta e e-mails: uma conta nova agora guarda o idioma da página em que foi criada, então o e-mail de acesso e todos os seguintes chegam nesse idioma. Contas que nunca escolheram um idioma são atualizadas no próximo login. Você pode trocar a qualquer momento nas configurações da conta.

​
Snapshots de qualquer tamanho podem ser baixados

O download de snapshot não tem mais limite de tamanho. GET /v1/users/:id/snapshots/:snapshot_id/download agora devolve o ZIP de snapshots de qualquer tamanho, em uma única resposta.

​
Projetos muito grandes mostram uma mensagem clara

Baixar diretamente como ZIP um projeto com mais de 300 MB de arquivos agora retorna DOWNLOAD_TOO_LARGE (HTTP 413) e o painel pede para baixar um snapshot, que não tem limite de tamanho. Veja Baixar aplicação.

​
Snapshot antes de excluir agora é opcional

Excluir uma aplicação ou um banco não cria mais um snapshot automaticamente. O diálogo de exclusão do painel agora tem a opção Criar snapshot antes de apagar, desmarcada por padrão (aparece nos planos com backup manual). Marcada, o painel cria o snapshot e só apaga se ele der certo; desmarcada, o recurso é apagado direto.
  • API: DELETE /v1/apps/:id e DELETE /v1/databases/:id apagam direto. Para ter um backup, crie um snapshot antes.
  • Sem mudança: excluir uma stack inteira ou uma imagem Docker própria (o que apaga os apps dela) continua fazendo um snapshot de segurança antes. Quando a plataforma remove projetos por conta própria (plano vencido ou conta sem plano), o backup continua obrigatório: se ele falhar, o projeto é parado e preservado, não apagado. Veja Backup e restauração com snapshots.

​
Limite de tamanho do snapshot

Um snapshot pode ter no máximo 4 GB (o tamanho do arquivo do snapshot, já compactado). Acima disso, a criação é recusada com SNAPSHOT_TOO_LARGE (HTTP 413), em vez de um erro genérico. O limite vale para snapshot manual, diário e de segurança. O download não tem esse limite: qualquer snapshot existente pode ser baixado. Veja Backup e restauração com snapshots.

​
Novos limites diários de backups manuais

Os backups manuais agora têm dois limites diários: até 5 por projeto (aplicação ou banco) e, somando todos os seus projetos, 2 por GB de RAM do plano por conta, no mínimo 5 e no máximo 64: 5 no Starter 1 e 2, 8, 12 e 16 no Pro 4, 6 e 8, 24, 32 e 48 no Business 12, 16 e 24, e 64 em todos os tamanhos do Enterprise. O dia é contado no horário de Brasília, o intervalo de 5 minutos entre backups manuais do mesmo projeto continua valendo e o backup diário automático não conta. Veja Planos e limites.

​
Limites de proteção de tráfego ajustados

Ajustamos os limites do Vertra Shield e do limite de requisições por IP de visitante para que o tráfego legítimo seja interrompido com menos frequência.
  • Vertra Shield: aplicações que fazem muitas requisições de saída, como bots e integrações que chamam APIs externas, são pausadas com menos frequência. Uma primeira ocorrência não pausa mais a aplicação na hora. Planos maiores mantêm limites proporcionalmente maiores.
  • Limite de requisições por IP de visitante: o limite das aplicações em *.vertraweb.app e em domínios próprios foi ajustado. Se a sua aplicação recebe, de forma legítima, muito tráfego de um único IP, como uma integração entre servidores, fale com o suporte. Veja Proteções da plataforma.
Última modificação em 8 de novembro de 2026