Canal de compilación

Lizard compila en sus propios nodos. No necesitas Docker localmente. Cuando despliegas, la plataforma decide cómo convertir tu código fuente en una imagen de contenedor usando un orden de decisión fijo, y luego ejecuta esa imagen en un pod aislado. No todos los servicios de container as a service compilan la imagen por ti; el blog compara las tres formas en que se presenta esta categoría.

Orden de decisión de compilación

La plataforma elige exactamente una estrategia de compilación, en este orden:

1. Dockerfile del repositorio en dockerfilePath: si dockerfilePath está configurado en el servicio, ese Dockerfile se usa sin cambios, incluso cuando también se han configurado comandos de compilación o de inicio. Un startCommand configurado sigue reemplazando el ENTRYPOINT y el CMD del Dockerfile en runtime. Consulta Desplegar con un Dockerfile.
2. Dockerfile sintetizado: en caso contrario, si buildCommand y/o startCommand están configurados en el servicio (o se pasan mediante lizard up --build-command / --start-command), Lizard genera un Dockerfile a partir de esos comandos. lizardpack no se invoca.
3. Dockerfile en el código fuente: en caso contrario se usa un Dockerfile en la raíz del directorio de compilación (consulta la excepción de GitHub más abajo).
4. Autodetección de lizardpack: en caso contrario, la plataforma ejecuta lizardpack, su generador de buildpacks/Dockerfile.

Autodetección de lizardpack

lizardpack inspecciona tu repositorio y construye una imagen optimizada de múltiples etapas. Lizard comprueba los stacks compatibles en este orden:

Hugo → Go → Node → Python → Rust → Ruby → PHP → Java → static

Consulta las Guías de frameworks para ver scripts de producción, adaptadores, rutas de salida y puertos: Hugo, Go, Node (Node.js, Next.js, Nuxt, SvelteKit, Astro, React, Vue, Docusaurus, VitePress), Python (Django, FastAPI, Streamlit) y Ruby (Rails). La detección usa archivos del proyecto y dependencias; un repositorio que coincida con varios proveedores sigue este orden. Para fijar una versión de Node.js o Python, consulta versiones del runtime.

En esta ruta:

• El código fuente subido (lizard up) siempre usa un Dockerfile en la raíz tal como está escrito.
• El código fuente de GitHub usa un Dockerfile en la raíz tal como está escrito, a menos que parezca incompleto: tiene un COPY de build, dist, out, .next o public escrito sin barra final (COPY dist /usr/share/nginx/html) y ninguna línea RUN que empiece por npm, yarn, pnpm, bun, pip, pip3, bundle, cargo, go build, mvn o gradle. En ese caso lizardpack genera un reemplazo.
• Sin Dockerfile, lizardpack genera uno por ti.
• El comando de inicio se detecta automáticamente: una línea Procfile web: (Python/Ruby) o package.json scripts.start (Node) se lee automáticamente. Para ver la línea exacta que necesitan Django, Flask y FastAPI, consulta hosting de aplicaciones Python.
• El puerto se infiere a partir de EXPOSE, los valores predeterminados del framework o una variable de entorno PORT explícita.

Ojo: En código fuente de GitHub, un Dockerfile que copia salida ya compilada (COPY dist /dest) y no tiene un paso RUN de gestor de paquetes se considera incompleto y lizardpack lo regenera. Añade un paso de compilación real o configura dockerfilePath para forzar el uso literal. Consulta Los cambios del Dockerfile no se aplican.

Qué activa una reconstrucción

No compiles dos veces. Después de un service set que cambia un campo de compilación en un servicio en ejecución, la reconstrucción se activa automáticamente: no encadenes un lizard redeploy después, o pondrás en cola una segunda compilación redundante (por qué). Un servicio que se ha bloqueado o que nunca se ha desplegado no se reconstruye por sí solo; ejecuta lizard redeploy.

Variables de tiempo de compilación

Lizard escribe las variables VITE_* y NEXT_PUBLIC_* en el Dockerfile como líneas ENV en dos casos:

• Servicios de GitHub sin dockerfilePath: las recibe el Dockerfile de lizardpack o el Dockerfile raíz del repositorio.
• Servicios con buildCommand o startCommand cuyo Dockerfile sintetizado es una compilación de Node.

Los servicios desplegados con lizard up y sin comando de compilación ni de inicio no reciben variables de Lizard en tiempo de compilación. Ningún servicio recibe argumentos de compilación aparte de COMMIT_SHA, así que un ARG en tu Dockerfile queda vacío. Para valores públicos con lizard up, súbelos en .env.production (comprueba que .gitignore no lo excluya), escríbelos en tu Dockerfile o, para una aplicación de servidor Node, configura tanto buildCommand como startCommand.

Ver una compilación

Los registros de compilación se transmiten durante lizard up. Para cualquier servicio:

lizard logs --build            # the most recent build's logs
lizard events                  # deploy history + replica status

Si una compilación falla, lee lizard logs --build, corrige la causa (en tu repositorio o ajustando buildCommand / startCommand mediante lizard service set) y luego ejecuta lizard redeploy.

Notas de runtime

• Sin Docker HEALTHCHECK. El runtime no ejecuta el ciclo de healthcheck de Docker, por lo que las directivas HEALTHCHECK se ignoran. Lizard ejecuta en su lugar una sonda TCP contra tu puerto (omitida en modo worker).
• No escribas un Dockerfile sin necesidad. lizardpack detecta automáticamente la mayoría de los stacks: prueba primero con un despliegue y añade un Dockerfile (o configura dockerfilePath) solo si la compilación automática no se ajusta a tu caso.

Referencia de configuración de compilación

Configura cualquiera de estos con lizard service set <svc> --set <field>=<value>. Vacía un campo con un valor vacío, como --set buildCommand=. Consulta lizard service.

Actualizado 12 de octubre de 2026