¿Cuándo usa Codara tu Dockerfile?
Cuando hay un archivo llamado exactamente Dockerfile en la raíz del contexto de build, o cuando defines la ruta de un Dockerfile en la app. Tiene prioridad sobre cualquier otra estrategia de build. La detección distingue mayúsculas: un dockerfile en minúsculas, o uno en un subdirectorio, no se detecta automáticamente y el build pasa a Railpack.
En un monorepo, define un directorio raíz para que cada app haga el build desde su carpeta, y rutas vigiladas para que un push solo reconstruya las apps que toca. La detección del Dockerfile y el contexto de build se resuelven respecto al directorio raíz.
# Un Dockerfile en otro sitio que no sea la raíz
codaracloud apps update api --client my-workspace --project shop \
--dockerfile docker/api.Dockerfile
# Una app por carpeta de un monorepo
codaracloud apps update web --client my-workspace --project shop \
--root-directory apps/web --watch-path "apps/web/**" --watch-path "packages/**"¿Qué debe hacer el Dockerfile?
Construir la app y después arrancar un único proceso de larga duración en primer plano que escuche en 0.0.0.0 y en la variable PORT. Codara envía el tráfico al puerto 8080 por defecto y define PORT con ese valor; configura otro puerto en la app si tu imagen no puede leer PORT. Un build multietapa mantiene pequeña la imagen final y deja fuera las herramientas de build.
FROM node:22-slim AS build
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN npm run build
FROM node:22-slim
WORKDIR /app
ENV NODE_ENV=production
COPY package.json package-lock.json ./
RUN npm ci --omit=dev
COPY --from=build /app/dist ./dist
USER node
CMD ["node", "dist/server.js"]El mismo patrón sirve para Go, Rust, Java, PHP, Ruby o cualquier cosa que funcione en un contenedor Linux. Añade un .dockerignore para que node_modules, .git y los archivos .env locales nunca entren en el contexto de build.
¿Argumentos de build o variables de entorno?
Los argumentos de build llegan a las instrucciones ARG de tu Dockerfile durante el build (solo a un Dockerfile tuyo: los builds con Railpack, Nixpacks o de sitios estáticos no los reciben) y quedan grabados en las capas de la imagen, así que son solo para valores públicos, como la URL pública de una API compilada en un frontend. Hasta 32 valores y 1.024 caracteres en total. Los secretos van en variables de entorno de ejecución, que el build no ve y que el contenedor lee al arrancar.
# Valor público de build (se lee con ARG PUBLIC_API_URL en el Dockerfile)
codaracloud apps update web --client my-workspace --project shop \
--build-arg PUBLIC_API_URL=https://api.example.com
# Secretos, solo en ejecución
codaracloud env set web SESSION_SECRET=... PAYMENT_API_KEY=...¿Cómo creas y publicas la app?
En la consola, abre Apps → New app, elige el proyecto y el entorno, selecciona GitHub repository y la rama, y envía; el asistente te muestra que va a usar tu Dockerfile antes de confirmar. Después, cada push a la rama hace el build y publica. Define una ruta de health check para que una versión solo se publique cuando el contenedor nuevo responda; si nunca responde, la versión anterior sigue sirviendo.
codaracloud apps create api --client my-workspace --project shop \
--repo acme/shop-api --branch main --port 8080
codaracloud deploy api --client my-workspace --project shop --source
# Vuelve a una versión anterior sin reconstruir
codaracloud deploys list api --client my-workspace --project shop
codaracloud rollback api --client my-workspace --project shop --to-deploy <deploy-id>¿Puedes desplegar una imagen construida en otro sitio?
Sí. Una app puede apuntar a una imagen de contenedor en lugar de a un repositorio, lo que encaja con imágenes de tu propia CI o con software de terceros. Si pasas la misma referencia otra vez, se vuelve a descargar, lo que actualiza una etiqueta móvil como latest. Para un registro privado, configura antes las credenciales; la contraseña solo se lee desde stdin.
echo "$REGISTRY_TOKEN" | codaracloud apps registry set my-app \
--username acme-ci --password-stdin
codaracloud apps image my-app ghcr.io/acme/my-app:v1.4.2¿Qué límites conviene conocer?
Un build puede durar 30 minutos, y cada inicio de build cuenta para la asignación mensual de tu plan, también los fallidos. Los logs de build se guardan 24 horas. Codara construye una imagen por app y no ejecuta archivos docker-compose.yml: crea cada servicio de Compose como una app propia y usa una base de datos gestionada en lugar de un contenedor de base de datos. Una app con volumen persistente se reinicia con una breve interrupción en cada versión, porque el disco solo puede montarlo un contenedor a la vez.
Preguntas
- ¿Necesito EXPOSE en el Dockerfile?
- No. Codara envía el tráfico al puerto configurado en la app, 8080 por defecto, y se lo pasa al contenedor como PORT. EXPOSE es solo documentación.
- ¿Dónde se construyen y guardan mis imágenes?
- Codara las construye en su propio clúster con BuildKit y las guarda en su registro de contenedores en la UE. No necesitas un permiso de paquetes de GitHub ni tu propio registro.
- ¿Puedo usar Docker Compose?
- No directamente. Codara despliega una imagen por app. Divide un archivo Compose en apps separadas en el mismo entorno y usa las bases de datos gestionadas de Codara (Postgres, MySQL, MariaDB, Redis o MongoDB) en lugar de los contenedores de bases de datos.