8 de noviembre de 2026
Actualización automática de las aplicaciones de una imagen Docker
Las imágenes tienen ahora la opción Actualizar las aplicaciones automáticamente tras cada build. Cuando está activada, cada build correcto de la imagen (un push a GitHub, una subida o una reconstrucción manual) reinicia en la versión nueva las aplicaciones de esa imagen que están en ejecución. Las aplicaciones detenidas siguen detenidas, y una aplicación que falla al actualizarse no impide que se actualicen las demás: el fallo aparece en las actividades. Consulta Imágenes Docker personalizadas.- Valor por defecto: una imagen creada desde GitHub empieza con la opción activada; las demás empiezan desactivada. Cámbiala en la página de la imagen.
- Pestaña Deploys: una aplicación que se ejecuta desde una imagen muestra ahora de qué imagen viene el despliegue y si la actualización automática está activada. El vínculo con GitHub pertenece a la imagen, no a la aplicación.
- Mismas reglas que cualquier despliegue: el despliegue sin downtime y el rollback automático se aplican cuando tu plan los incluye.
Aviso más visible sobre WORKDIR /app
En ejecución /app es el disco persistente de la aplicación, montado encima de la imagen, así que lo que la imagen ponga ahí queda oculto. La comprobación ahora avisa de WORKDIR /app solo en la etapa final del Dockerfile (una etapa de build de un multi-stage ya no genera aviso), y los avisos de cada build, incluidos los lanzados por un push a GitHub, se guardan en la imagen. El panel muestra una franja en la página de la imagen y un aviso en la pestaña Deploys de las aplicaciones que usan la imagen, y pide confirmación al crear una aplicación a partir de ella. Para corregirlo, usa otro directorio (como WORKDIR /srv) y vuelve a construir. Consulta Imágenes Docker propias.warnings(lista de{ code, line }) lo devuelvenGET /v1/images/:image_idy el listado de imágenes.
API y MCP
auto_update_apps(booleano) lo devuelveGET /v1/images/:image_idy lo aceptaPATCH /v1/images/:image_id.- La herramienta
update_imagedel MCP aceptaauto_update_apps.
Idioma del sitio y de los correos
- Sitio: en la primera visita, el sitio se abre en español cuando accedes desde un país de habla hispana, y en portugués desde Brasil u otro país de habla portuguesa, aunque el navegador esté en otro idioma. En los demás países, sigue valiendo el idioma del navegador. El idioma que elijas en el selector de idioma siempre se respeta y queda guardado.
- Cuenta y correos: una cuenta nueva ahora guarda el idioma de la página en la que se creó, así que el correo de acceso y todos los siguientes llegan en ese idioma. Las cuentas que nunca eligieron un idioma se actualizan en el próximo inicio de sesión. Puedes cambiarlo cuando quieras en la configuración de la cuenta.
Se pueden descargar snapshots de cualquier tamaño
La descarga de snapshots ya no tiene límite de tamaño.GET /v1/users/:id/snapshots/:snapshot_id/download ahora devuelve el ZIP de snapshots de cualquier tamaño, en una sola respuesta.Los proyectos muy grandes muestran un mensaje claro
Descargar directamente como ZIP un proyecto con más de 300 MB de archivos ahora devuelveDOWNLOAD_TOO_LARGE (HTTP 413) y el panel pide descargar un snapshot, que no tiene límite de tamaño. Consulta Descargar aplicación.El snapshot antes de eliminar ahora es opcional
Eliminar una aplicación o una base de datos ya no crea un snapshot automáticamente. El diálogo de eliminación del panel ahora tiene la opción Crear snapshot antes de borrar, desmarcada por defecto (aparece en los planes con copia de seguridad manual). Marcada, el panel crea el snapshot y solo elimina si sale bien; desmarcada, el recurso se elimina directamente.- API:
DELETE /v1/apps/:idyDELETE /v1/databases/:ideliminan directamente. Para conservar una copia, crea un snapshot antes. - Sin cambios: eliminar un stack completo o una imagen Docker propia (lo que elimina sus aplicaciones) sigue haciendo un snapshot de seguridad antes. Cuando la plataforma elimina proyectos por su cuenta (plan vencido o cuenta sin plan), la copia sigue siendo obligatoria: si falla, el proyecto se detiene y se conserva, no se elimina. Consulta Copias de seguridad y restauración con snapshots.
Límite de tamaño del snapshot
Un snapshot puede tener como máximo 4 GB (el tamaño del archivo del snapshot, ya comprimido). Por encima de eso, la creación se rechaza conSNAPSHOT_TOO_LARGE (HTTP 413) en lugar de un error genérico. El límite vale para snapshots manuales, diarios y de seguridad. La descarga no tiene ese límite: se puede descargar cualquier snapshot existente. Consulta Copias de seguridad y restauración con snapshots.Nuevos límites diarios de copias de seguridad manuales
Las copias de seguridad manuales ahora tienen dos límites diarios: hasta 5 por proyecto (aplicación o base de datos) y, sumando todos tus proyectos, 2 por GB de RAM del plan por cuenta, mínimo 5 y máximo 64: 5 en Starter 1 y 2, 8, 12 y 16 en Pro 4, 6 y 8, 24, 32 y 48 en Business 12, 16 y 24, y 64 en todos los tamaños de Enterprise. El día se cuenta en hora de Brasilia, el intervalo de 5 minutos entre copias manuales del mismo proyecto sigue vigente y la copia de seguridad diaria automática no cuenta. Consulta Planes y límites.Límites de protección de tráfico ajustados
Ajustamos los límites de Vertra Shield y del límite de solicitudes por IP de visitante para que el tráfico legítimo se interrumpa con menos frecuencia.- Vertra Shield: las aplicaciones que hacen muchas solicitudes salientes, como bots e integraciones que llaman a APIs externas, se pausan con menos frecuencia. Una primera ocurrencia ya no pausa la aplicación de inmediato. Los planes superiores mantienen límites proporcionalmente mayores.
- Límite de solicitudes por IP de visitante: se ajustó el límite de las aplicaciones en
*.vertraweb.appy en dominios propios. Si tu aplicación recibe de forma legítima mucho tráfico desde una sola IP, como una integración entre servidores, contacta con soporte. Consulta Protecciones de la plataforma.