v26.4.9 — 25 de octubre de 2026

​

Imágenes Docker personalizadas

• Crea una imagen desde un archivo ZIP de hasta 100 MB, o desde un repositorio de GitHub. La rama es opcional: si no la indicas, se usa la rama predeterminada del repositorio. Un repositorio de tus instalaciones de la GitHub App se vincula, así que cada push reconstruye la imagen; un repositorio público fuera de ellas se construye una sola vez, sin vínculo. En el panel, Nuevo proyecto también tiene la opción Usar imagen Docker para crear una aplicación a partir de una imagen que ya tengas. El proyecto necesita un archivo llamado exactamente Dockerfile en su raíz. La imagen se construye en un entorno de build aislado con un límite de 26 minutos, y el resultado puede llegar a 10 GB. Cada cuenta puede tener hasta 20 imágenes.
• Revisa antes de construir. El panel revisa tu Dockerfile antes de que empiece el build: las instrucciones que debilitarían el aislamiento del build se rechazan, y los errores habituales, como los archivos .env en el proyecto, se señalan para que los corrijas. Los archivos .env* nunca entran en la imagen, y tu Dockerfile nunca se reescribe. Consulta qué se rechaza y qué se advierte.
• Crea aplicaciones desde la imagen. Varias aplicaciones pueden compartir una imagen, cada una con sus propias variables. En una aplicación web, el puerto es el primer EXPOSE del Dockerfile, o 80, y llega a tu aplicación como PORT. Una aplicación creada sin la web puede publicarse más adelante indicando el puerto.
• Actualiza la imagen subiendo un contexto nuevo, con un commit encima del contexto actual, o con un push a una rama de GitHub vinculada (vincula un repositorio de tus instalaciones de la GitHub App; la rama es opcional). La GitHub Action acepta image-id para reconstruir una imagen. Una reconstrucción nunca reinicia tus aplicaciones: cada una pasa a la nueva versión cuando la reinicias o la despliegas.
• Versiones y rollback. Cada build correcto es una versión. Las aplicaciones conservan 30 releases durante 30 días, y un rollback inicia una versión que ya estaba construida.
• Snapshots de estas aplicaciones contienen los datos de /app y la versión de la imagen. Al restaurar, también puedes volver a esa versión si todavía existe.
• Renombrar y describir. Puedes dar una descripción a una imagen (de hasta 128 caracteres) al crearla, y renombrarla o cambiar su descripción después en el panel, la API, los SDK, la CLI, el servidor MCP o la extensión de VS Code. No se reconstruye nada y tus aplicaciones siguen ejecutándose.
• Eliminar una imagen elimina cada aplicación creada a partir de ella, después de que escribas el nombre de la imagen.
• En la extensión de VS Code. Una nueva vista de Imágenes Docker muestra tus imágenes y sus aplicaciones. Desde ahí puedes crear una imagen desde una carpeta o un repositorio de GitHub, reconstruirla, seguir el log del build, consultar las versiones, vincular una rama de GitHub, eliminarla y crear una aplicación a partir de ella. El despliegue, la publicación y la restauración de snapshots de las aplicaciones de imagen también funcionan desde la extensión, y una nueva aplicación desde una carpeta con un Dockerfile ofrece crear una imagen en su lugar.

​

Mejoras

• Elige la rama de tus despliegues de GitHub. Importar un repositorio de GitHub en el panel ahora tiene un selector de rama, y el despliegue automático sigue la rama que elijas (la ruta del webhook de despliegue acepta un branch opcional). Los despliegues automáticos existentes siguen main y master.
• Enlaces para desarrolladores en la barra lateral. CLI, extensión de VS Code, MCP, Novedades y Docs pasaron del menú de la cuenta a la barra lateral del panel.
• Tema con un clic. La apariencia en el menú de la cuenta es ahora un único botón que cambia entre Sistema, Claro y Oscuro.
• Eliminar una aplicación espera al resultado. El cuadro de confirmación se mantiene abierto con su progreso hasta que termina la eliminación, y entonces se cierra con la aplicación ya fuera de la lista. Si la eliminación falla, el cuadro sigue abierto y muestra el motivo.
• Sesión ya iniciada. Abrir la página de inicio de sesión estando ya conectado te lleva directamente al panel.

​

Correcciones

• Importar un repositorio de GitHub cuyo nombre contiene .git en medio, como name.github.io, ya no trae el repositorio equivocado.
• Restaurar un snapshot (de aplicación o de base de datos) o hacer rollback a un release desde un archivo dañado ahora se rechaza antes de cambiar nada (INVALID_ZIP_STRUCTURE, 400). Los archivos de la aplicación y la base de datos en ejecución se mantienen como estaban; antes, una base de datos podía quedar detenida y los archivos de una aplicación podían borrarse. Un snapshot de aplicación sin archivos se rechaza de la misma forma.
• Las acciones sobre aplicaciones, bases de datos, snapshots, dominios y archivos ahora siempre registran su actividad en el workspace al que pertenece el recurso.
• Vincular una aplicación al despliegue automático ahora comprueba el repositorio contra tu instalación de la GitHub App. Un repo_id que no coincide con el repositorio se rechaza con VALIDATION_ERROR, un repositorio fuera de la instalación devuelve INSTALLATION_NOT_FOUND, y si GitHub no está disponible se devuelve FETCH_ZIP_ERROR (502).