> ## 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 octubre de 2026 > v26.4.9: imágenes Docker personalizadas desde tu Dockerfile en Enterprise 28, 30 y 32, con versiones, rollback, reconstrucciones desde GitHub y snapshots **v26.4.9** 25 de octubre de 2026 ### Imágenes Docker personalizadas Enterprise 28, Enterprise 30 y Enterprise 32 ya pueden construir una imagen a partir de su propio `Dockerfile` y ejecutar aplicaciones con ella. Úsala para otro lenguaje o versión, paquetes del sistema, tu propio proceso de arranque o aplicaciones ya hechas. * **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](https://docs.vertracloud.app/es-es/guides/custom-docker-images.md#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. Nuevas rutas de la API bajo `/v1/images` (incluido `PATCH /v1/images/{image_id}` para renombrar y describir) y `POST /v1/apps/image`, con los nuevos ámbitos de clave de API `images:read`, `images:write` e `images:delete` (eliminar una imagen que tiene aplicaciones también necesita `apps:delete`, y subir archivos a una aplicación que ejecuta una imagen también necesita `images:write`), y los nuevos códigos de error `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` y `DOCKERFILE_REFUSED`. Lee la [guía](https://docs.vertracloud.app/es-es/guides/custom-docker-images.md) y la [referencia de la API](https://docs.vertracloud.app/api-reference/endpoint/images/create.md). ### 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`). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.