Sube el proyecto
Un ZIP o un repositorio de GitHub, con la rama que elijas, y un archivo llamado Dockerfile en la raíz. El panel muestra lo que se rechazará antes de empezar el build.
Imágenes Docker
Trae tu Dockerfile. Ejecuta cualquier stack.
Tu lenguaje, tus paquetes del sistema, tu propio proceso de inicio. Sube el proyecto, Vertra construye la imagen en un entorno aislado y tú levantas todas las apps que quieras a partir de ella.
Para quién es
Para cuando la lista de lenguajes no alcanza.
Los runtimes gestionados cubren los lenguajes más comunes. Si necesitas otro lenguaje o versión, paquetes del sistema, un proceso de inicio propio o una app que ya viene lista en una imagen, el Dockerfile lo resuelve. Todo sigue en el mismo panel, con los mismos logs, métricas, dominios y snapshots que tus otras apps.
Cómo funciona
Tres pasos, del Dockerfile a la app en línea.
Sin servidor de build que mantener y sin imagen que publicar en ningún sitio.
Vertra construye la imagen
El build corre en un entorno aislado, con el log en vivo en el panel. Si falla, la versión que ya estaba en línea queda intacta.
Crea las apps que quieras
Cada app nace de la misma imagen con su propia RAM, puerto y variables de entorno. Un bot, una API y un worker pueden salir del mismo Dockerfile.
Beneficios
Libertad de stack, con la comodidad de la plataforma.
Lo que ya tienes en las apps comunes también vale para las apps de imagen.
Cualquier lenguaje o stack
Incluso los que no están en la lista de runtimes: si corre en un contenedor Linux, corre aquí.
Despliegue automático desde GitHub
Vincula la imagen a un repositorio y a una rama. Cada push reconstruye la imagen, sin abrir el panel.
Versiones con rollback
Cada build exitoso se convierte en una versión. Volver a una anterior es instantáneo, porque ya está construida.
Snapshots de tus datos
El disco persistente de la app entra en los backups y en los snapshots, con programación, retención y restauración como en las otras apps.
Logs del build en vivo
Sigue cada paso del build en el panel mientras ocurre y vuelve a leer el log después, si algo falla.
Varias apps por imagen
Construye la imagen una vez y crea las apps que necesites, cada una con su propia configuración.
Seguridad
Libertad para tu código, aislamiento para todos.
Tú escribes el Dockerfile. La plataforma se encarga de que no afecte a nadie más.
El build corre aislado
Cada build ocurre en un entorno separado de la plataforma y de los otros clientes, con límite de tiempo y de recursos.
La app corre en el mismo sandbox de todos
Una app de imagen tiene la misma protección que cualquier app de Vertra: un contenedor aislado de los otros clientes.
Secretos fuera de la imagen
Los archivos .env nunca entran en el contexto del build ni en la imagen. Las variables viven en la app, donde cambias el valor sin reconstruir.
Reconstruir no tumba nada
Una versión nueva nunca reinicia las apps por sí sola, y un build con error no cambia lo que está corriendo. La app solo cambia de versión cuando tú lo pides.
Reglas
Lo que la plataforma rechaza y cómo corre la app.
El panel revisa el Dockerfile antes del build y explica cada rechazo. Los principales están abajo; consulta la guía completa en la documentación.
Dockerfile en la raíz, con ese nombre
Un ZIP de hasta 100 MB o un repositorio de GitHub, con un archivo llamado exactamente Dockerfile en la raíz. La imagen es linux/amd64.
Directivas que romperían el aislamiento
Se rechazan el # syntax= que apunte a un frontend de terceros, RUN --network=host y RUN --security=insecure. Quita la directiva y el build sigue.
Sin secretos dentro del build
Se rechazan los montajes de secreto y de ssh (--mount=type=secret y --mount=type=ssh). Pon las claves en las variables de la app.
.env no entra en la imagen
Los archivos .env se quitan del contexto. Sus claves se vuelven variables sugeridas al crear la app, y los valores nunca entran en la imagen.
/app es el disco persistente
Lo que la app escribe en /app permanece entre reinicios y entra en los snapshots. Evita WORKDIR /app: lo que la imagen ponga allí queda oculto por el disco. Usa otra carpeta, como /srv.
Puerto, usuario y escritura
La app escucha en el puerto del primer EXPOSE (o 80) y recibe el valor en PORT. Corre como el usuario 1000:1000, y fuera de /app solo las carpetas temporales, como /tmp, aceptan escritura.
Ejemplo
Un Dockerfile común ya basta.
Sin instrucciones especiales: la plataforma usa tu Dockerfile exactamente como lo escribiste, sin reescribir nada.
Dockerfile
FROM python:3.12-slim
WORKDIR /srv
COPY . .
RUN pip install -r requirements.txt
EXPOSE 8000
CMD ["python", "main.py"]Planes
Disponible en Enterprise 28, 30 y 32.
Hasta 20 imágenes por cuenta, contando las imágenes en cualquier estado. Reconstruir, hacer commit y crear versiones no cuenta como imagen nueva.
| Plan | Imágenes |
|---|---|
| Enterprise 28 | 20 imágenes |
| Enterprise 30 | 20 imágenes |
| Enterprise 32 | 20 imágenes |
Si pasas a un plan sin la función, las imágenes y las apps que ya existen siguen corriendo. Solo no podrás crear ni reconstruir imágenes hasta volver a uno de estos planes, y eliminar siempre es posible.
Comparar planesDudas
Preguntas frecuentes
Lo esencial antes de subir tu primer Dockerfile.
¿Necesito saber Docker?
Solo lo básico: un Dockerfile que construya e inicie tu app. Si ya ejecutas el proyecto en un contenedor en tu máquina, el mismo Dockerfile suele funcionar aquí.
¿Cuándo usar una imagen en lugar de un runtime gestionado?
Cuando el runtime gestionado no cubre lo que necesitas: otro lenguaje o versión, paquetes del sistema, un proceso de inicio propio o una app que ya viene lista en una imagen. Para los lenguajes de la lista, el despliegue por ZIP o GitHub es más simple.
¿Puedo actualizar la imagen después?
Sí. Puedes volver a subir el contexto, hacer un commit de archivos sobre el actual o vincular la imagen a un repositorio y dejar que cada push la reconstruya. Las apps solo pasan a la nueva versión cuando reinicias o haces el despliegue.
¿Qué pasa con los datos de mi app?
Todo lo que la app escribe en /app queda en el disco persistente y entra en los snapshots. La imagen en sí no va en el snapshot, porque su código ya tiene historial en las versiones. Al restaurar, eliges si vuelves también a la versión de la imagen.
¿Por qué rechazaron mi Dockerfile?
El panel lista cada punto. Las causas más comunes son # syntax= de terceros, RUN --network=host, RUN --security=insecure y montajes de secreto o de ssh. Quita la directiva y súbelo de nuevo.
¿Qué pasa si elimino una imagen?
Se eliminan la imagen, sus versiones y todas las apps creadas a partir de ella, y confirmas escribiendo el nombre. Cada app sigue las reglas normales de eliminación, incluido el snapshot de seguridad en los planes que lo tienen.
Imágenes Docker
Tu Dockerfile en línea en pocos minutos.
Sube el proyecto, sigue el build en vivo y crea la primera app de la imagen.