# Implementar una exportación estática de Next.js
Una exportación estática de Next.js genera HTML, JavaScript y recursos en `out/`. Implementa ese directorio en Lizard con un Dockerfile de nginx. Usa esta ruta para páginas que pueden compilarse con antelación; usa la [guía del servidor Node.js](https://lizard.build/es/docs/framework-guides/nextjs) para funciones del servidor en tiempo de solicitud.
## Configura la exportación
Integra estas opciones en `next.config.mjs`:
```js
/** @type {import('next').NextConfig} */
const nextConfig = {
output: 'export',
trailingSlash: true,
images: { unoptimized: true },
};
export default nextConfig;
```
Mantén `"build": "next build"` en `package.json`. Este ejemplo usa imágenes exportadas simples; un cargador de imágenes externo es otra opción. Genera todos los parámetros de rutas dinámicas necesarios durante la compilación. Las cookies en tiempo de solicitud, Server Actions y otras funciones que necesitan un servidor Next.js en ejecución no pueden ejecutarse en este contenedor estático. Revisa la [referencia de exportación estática de Next.js](https://nextjs.org/docs/app/guides/static-exports) comparándola con las funciones que usa tu app.
## Añade un Dockerfile completo
La ruta de detección automática de Next.js espera un servidor Node. No cambia a nginx solo porque la configuración exporte `out/`. Añade este Dockerfile en la raíz de la app; asume npm y un `package-lock.json` confirmado en el repositorio:
```dockerfile
FROM node:22-slim AS build
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN npm run build
FROM nginx:alpine
COPY --from=build /app/out /usr/share/nginx/html
COPY nginx.conf /etc/nginx/conf.d/default.conf
EXPOSE 80
```
Crea `nginx.conf` junto a él:
```nginx
server {
listen 80;
server_name _;
root /usr/share/nginx/html;
index index.html;
location / {
try_files $uri $uri/ =404;
}
error_page 404 /404.html;
location = /404.html {
internal;
}
}
```
La exportación con barra final crea directorios de ruta con `index.html`. La regla de nginx sirve esos directorios y devuelve HTTP 404 para rutas inexistentes. Añade `node_modules`, `.next`, `out`, `.git` y `.env*` a `.dockerignore` y excluye los archivos de compilación locales de las cargas.
## Compila e implementa
```bash
npm ci
npm run build
```
Comprueba que existan `out/index.html` y una ruta interna esperada. Con Docker disponible, prueba el servidor real localmente:
```bash
docker build -t nextjs-static .
docker run --rm -p 8080:80 nextjs-static
```
Después de la [configuración de la CLI](https://lizard.build/es/docs/framework-guides#prepare-the-project), implementa en un nuevo servicio:
```bash
lizard init --name nextjs-static
lizard add --service web
lizard up --service web --port 80
lizard logs --build --service web --json
lizard ps --json
```
El Dockerfile completo incluye un paso de compilación con npm que lizardpack puede reconocer. En un servicio existente, inspecciona y borra las anulaciones de compilación/inicio en conflicto antes de seleccionar un Dockerfile; consulta el [orden de decisión de compilación](https://lizard.build/es/docs/concepts/build-pipeline#build-decision-order).
## Verifica rutas y actualizaciones
Solicita la página de inicio activa, una ruta interna exportada, un recurso JavaScript y una ruta inventada. La ruta inventada debe devolver HTTP 404, no la página de inicio con HTTP 200. Usa las comprobaciones de [rutas estáticas y 404](https://lizard.build/es/docs/framework-guides/static-routing#verify-http-responses).
Todos los cambios del contenido exportado requieren una nueva compilación. Las variables de entorno en tiempo de ejecución no pueden cambiar valores ya escritos en `out/`. Para variables públicas de compilación en un Dockerfile personalizado, declara los `ARG` necesarios antes de `RUN npm run build`; nunca coloques credenciales privadas en el paquete exportado.
Consulta [versiones probadas y resultados en la nube](https://lizard.build/es/docs/framework-guides/validation) para las comprobaciones de implementación del 9 de septiembre de 2026 y sus límites.