¿Qué necesita tu proyecto de Next.js?
Un proyecto estándar de Next.js no necesita cambios. Sin Dockerfile, Codara lo construye con Railpack: detecta package.json, elige el gestor de paquetes según tu lockfile, ejecuta tu script build y arranca la app con tu script start. Además guarda en caché .next/cache entre builds.
Sube tu lockfile al repositorio y fija la versión de Node en package.json para que el build no cambie sin avisar. next start lee la variable de entorno PORT y escucha en todas las interfaces por defecto, así que funciona con el puerto que define Codara.
{
"scripts": {
"dev": "next dev",
"build": "next build",
"start": "next start"
},
"engines": { "node": "22.x" }
}Construye una vez la versión de producción en local con npm run build y npm start. Si solo funciona con next dev, arregla eso primero: la plataforma ejecuta el build de producción.
¿Cómo creas la app en Codara Cloud?
Instala la GitHub App de Codara en la cuenta propietaria del repositorio y crea un proyecto; viene con un entorno de producción. Después usa el asistente de despliegue de la consola, Apps → New app: elige el proyecto y el entorno, selecciona GitHub repository con su rama y envía. El asistente es la única vía que crea la app y lanza su primer build en un solo paso.
Deja el puerto en 8080: Codara se lo pasa al contenedor como PORT y next start lo usa. El primer build suele tardar unos minutos. Cuando la versión está publicada, la app funciona con HTTPS en su dirección codara.cloud, y cada push a la rama despliega una versión nueva.
codaracloud projects create website --client my-workspace --name "Website"
# apps create no lanza un build; deploy --source sí
codaracloud apps create web --client my-workspace --project website \
--repo acme/web --branch main
codaracloud deploy web --client my-workspace --project website --source
codaracloud open web¿Dónde van las variables de entorno y los valores NEXT_PUBLIC?
Los valores solo de servidor, como claves de API y contraseñas de bases de datos, van en las variables de entorno de ejecución de la app. Están disponibles para los server components, los route handlers y el middleware cuando la app funciona, pero no durante el build.
Next.js compila las variables NEXT_PUBLIC_ en el bundle del navegador durante next build, así que deben existir en tiempo de build, y las variables de ejecución no están disponibles entonces. Como estos valores son públicos de todos modos, guárdalos en un archivo .env.production en el repositorio, que next build lee. Con el build por defecto de Railpack, esa es la forma de definirlos por ahora: los argumentos de build que defines en la app no llegan a un build con Railpack. Si haces el build con tu propio Dockerfile, también puedes pasarlos como argumentos de build: declara ARG NEXT_PUBLIC_SITE_URL y ENV NEXT_PUBLIC_SITE_URL=$NEXT_PUBLIC_SITE_URL antes de RUN next build. Nunca pongas un secreto en una variable NEXT_PUBLIC_, en .env.production ni en un argumento de build.
# Valores de ejecución (aquí van los secretos)
codaracloud env set web STRIPE_SECRET_KEY=sk_live_... AUTH_SECRET=...NEXT_PUBLIC_SITE_URL=https://www.example.com¿Te conviene la salida standalone o un Dockerfile?
No necesitas ninguno de los dos. next build y next start funcionan en Codara tal cual. La salida standalone (output: "standalone" en next.config) genera un servidor más pequeño que arrancas con node .next/standalone/server.js, pero Next.js no copia en él las carpetas public y .next/static.
Si quieres la salida standalone o controlar toda la imagen, añade un Dockerfile en la raíz del repositorio. Codara usa un Dockerfile en la raíz tal cual, en lugar de Railpack. Copia public y .next/static en la carpeta standalone desde tu Dockerfile y arranca server.js con PORT y HOSTNAME=0.0.0.0.
Una exportación totalmente estática (output: "export") no tiene servidor. Haz el build en local y publica la carpeta out con las herramientas MCP, o mantén next start si usas funciones de servidor.
¿Cómo añades una base de datos y tu propio dominio?
Crea una base de datos Postgres en el mismo entorno y conéctala a la app. Codara inyecta DATABASE_URL para tus consultas y DATABASE_DIRECT_URL para las migraciones, y reinicia la app. Ejecuta las migraciones como comando previo al despliegue, así una migración fallida nunca sustituye a la versión que funciona.
Añade tu dominio a la app, crea el registro DNS que te muestra la consola y Codara emite el certificado. Conserva la dirección codara.cloud para hacer pruebas.
¿Puede desplegarla tu agente de programación?
Sí. Conecta Claude Code, Cursor, Codex u otro cliente MCP a Codara con el prompt de configuración de la documentación. Tu agente podrá crear el proyecto, conectar GitHub, crear bases de datos y leer los logs de build. Los tokens de agente son solo de desarrollo por defecto, así que publicar en producción sigue siendo un paso aparte que apruebas tú.
Despliega esta app de Next.js en Codara Cloud, en un entorno de desarrollo
del proyecto "website". Usa codara_search para encontrar las operaciones.
Comprueba que package.json tiene los scripts build y start, crea una base
de datos Postgres y conéctala, y enséñame los logs de build y la URL.Preguntas
- ¿Funcionan los server components, los route handlers y el middleware?
- Sí. Codara ejecuta next start, el servidor de producción de Next.js, como un contenedor siempre activo, así que el renderizado en servidor, los route handlers, las server actions y el middleware funcionan como en cualquier servidor Node.js.
- ¿Qué puerto usa una app de Next.js en Codara Cloud?
- Codara envía el tráfico al puerto 8080 por defecto y define PORT con ese valor. next start lee PORT, así que no tienes que cambiar nada. Si configuras otro puerto en la app, PORT lo sigue.
- ¿Una app de Next.js sale más barata en Codara Cloud que en Vercel?
- Depende de tu tráfico y tu equipo. Codara Cloud cuesta un precio fijo de 5 a 100 € al mes por organización, con bases de datos incluidas; Vercel cobra por asiento con despliegue más el uso. Nuestra comparativa hace las cuentas.