Preparar tu API NestJS para producción

Contenido del curso

Fundamentos y Primer CRUD

Base de Datos y Persistencia con TypeORM

Autenticación y Autorización

Tu API Completa

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:0010:45

Preparar tu API NestJS para producción

Curso de Backend con NestJS

Clase 33 de 35

Clase 33 / 35

Recursos

Antes de subir tu API de NestJS a producción, necesitas blindarla con seguridad básica, habilitar CORS, fijar la versión de Node y compilar el proyecto a JavaScript. Esa lista corta marca la diferencia entre una app frágil y una lista para recibir tráfico real desde web, móvil o escritorio.

¿Cómo proteger tu API con Helmet en NestJS?

La primera capa de seguridad la pones con Helmet, un paquete Node que actúa como un casco frente a las vulnerabilidades más conocidas en APIs.

La instalación y configuración son mínimas, pero el impacto en seguridad es alto. Solo necesitas tres pasos:

Instalar el paquete con npm i helmet.
Importarlo dentro del archivo main.ts.
Aplicarlo con app.use(helmet()) antes de levantar el servidor.

Con eso ya cubres los ataques conocidos por defecto. Si quieres ajustar reglas adicionales, Helmet expone opciones avanzadas, pero la configuración base es la que la documentación oficial de NestJS recomienda como mínimo viable [03:50].

¿Qué hace Helmet en una API? Aplica cabeceras HTTP de seguridad para protegerte contra vulnerabilidades comunes como inyecciones, clickjacking o filtrado de información sensible.

¿Qué son los CORS y cuándo debes habilitarlos?

Los CORS (Cross Origin Resource Sharing) son el permiso que tu API da para recibir requests desde dominios distintos al suyo. Por defecto, NestJS los deshabilita por seguridad.

Si tu backend va a servir a una aplicación web, móvil y de escritorio al mismo tiempo, necesitas habilitarlos. Una app móvil en Android o iOS no tiene un origin fijo, así que sin CORS abiertos esos requests serían rechazados.

La habilitación se hace con app.enableCors() dentro de main.ts, y puedes pasarle un objeto con tres llaves clave:

origin: define qué dominios pueden consumir tu API.
methods: lista los verbos HTTP permitidos (GET, POST, PUT, DELETE).
allowedHeaders: especifica qué cabeceras se aceptan en la petición.

Si tu producto es solo web, lo correcto es restringir origin al dominio real, por ejemplo myblog.ai. Si tienes clientes móviles o de escritorio, lo común es aceptar cualquier origen. Tu lógica de negocio decide qué tan estricta es esa regla.

typescript app.enableCors({ origin: '*', methods: 'GET,HEAD,PUT,PATCH,POST,DELETE', allowedHeaders: 'Content-Type, Accept', });

¿Cómo configurar la versión de Node y compilar para producción?

Proveedores como Heroku o Railway leen el package.json y respetan el campo engines para saber qué versión de Node ejecutar. Sin esa señal, podrías terminar con una versión incompatible corriendo tu app.

La recomendación para este proyecto es Node 20 o superior. En Node 18, por ejemplo, el módulo de hashing aún no está disponible de forma global; desde la 20 sí lo está, así que evitas errores silenciosos en autenticación.

"engines": { "node": ">=20" }

¿Qué hace npm run build en un proyecto NestJS?

Como trabajas con TypeScript en desarrollo, necesitas transpilarlo a JavaScript puro antes de producción. Eso lo hace npm run build, que genera la carpeta dist con un archivo main.js listo para ejecutarse en un runtime de Node.

Dentro de dist vas a encontrar todos tus DTOs, entities y modelos convertidos a JavaScript. Esa es la versión real que correrá en el servidor.

El comando start:prod apunta a dist/main, así que si lo ejecutas sin haber hecho el build primero, vas a recibir un error porque la carpeta no existe.

¿Por qué correr build antes de start:prod? Porque start:prod ejecuta JavaScript ya compilado desde la carpeta dist. Sin build, esa carpeta no existe y Node no encuentra el archivo de entrada.

¿Cuál es el orden correcto para lanzar a producción?

El flujo recomendado tiene tres pasos en este orden exacto:

npm run build para transpilar todo el código TypeScript a JavaScript.
Ejecutar las migraciones pendientes contra la base de datos.
npm run start:prod para arrancar el servidor en modo productivo.

Las migraciones van en medio porque ya estás en un ambiente real y necesitas que el esquema de la base de datos esté sincronizado antes de aceptar tráfico. Si no hay migraciones pendientes, el comando lo confirma y sigues al siguiente paso [10:30].

¿Qué cambia al correr la app en modo producción?

Cuando levantas el servidor con start:prod, ya no hay capa de TypeScript ni recarga en caliente. Node ejecuta JavaScript puro directamente desde dist.

Eso trae dos ganancias inmediatas:

Mayor velocidad de respuesta porque desaparece la capa de transpilación en tiempo real.
Optimizaciones del build que reducen el tamaño y mejoran el arranque.

Las pruebas con endpoints como GET /users o GET /posts siguen funcionando igual, pero notarás que responden más rápido que en modo start:dev. Esa diferencia es la que tus usuarios finales van a percibir.

¿Ya tienes tu checklist listo para tu próximo deploy? Cuéntame en los comentarios cuál de estos pasos sueles olvidar y cómo lo resolviste.

Resumen

¿Cómo proteger tu API con Helmet en NestJS?

La primera capa de seguridad la pones con Helmet, un paquete Node que actúa como un casco frente a las vulnerabilidades más conocidas en APIs.

La instalación y configuración son mínimas, pero el impacto en seguridad es alto. Solo necesitas tres pasos:

Instalar el paquete con npm i helmet.
Importarlo dentro del archivo main.ts.
Aplicarlo con app.use(helmet()) antes de levantar el servidor.

¿Qué hace Helmet en una API? Aplica cabeceras HTTP de seguridad para protegerte contra vulnerabilidades comunes como inyecciones, clickjacking o filtrado de información sensible.

¿Qué son los CORS y cuándo debes habilitarlos?

Los CORS (Cross Origin Resource Sharing) son el permiso que tu API da para recibir requests desde dominios distintos al suyo. Por defecto, NestJS los deshabilita por seguridad.

La habilitación se hace con app.enableCors() dentro de main.ts, y puedes pasarle un objeto con tres llaves clave:

origin: define qué dominios pueden consumir tu API.
methods: lista los verbos HTTP permitidos (GET, POST, PUT, DELETE).
allowedHeaders: especifica qué cabeceras se aceptan en la petición.

typescript app.enableCors({ origin: '*', methods: 'GET,HEAD,PUT,PATCH,POST,DELETE', allowedHeaders: 'Content-Type, Accept', });

¿Cómo configurar la versión de Node y compilar para producción?

"engines": { "node": ">=20" }

¿Qué hace npm run build en un proyecto NestJS?

Dentro de dist vas a encontrar todos tus DTOs, entities y modelos convertidos a JavaScript. Esa es la versión real que correrá en el servidor.

El comando start:prod apunta a dist/main, así que si lo ejecutas sin haber hecho el build primero, vas a recibir un error porque la carpeta no existe.

¿Por qué correr build antes de start:prod? Porque start:prod ejecuta JavaScript ya compilado desde la carpeta dist. Sin build, esa carpeta no existe y Node no encuentra el archivo de entrada.

¿Cuál es el orden correcto para lanzar a producción?

El flujo recomendado tiene tres pasos en este orden exacto:

npm run build para transpilar todo el código TypeScript a JavaScript.
Ejecutar las migraciones pendientes contra la base de datos.
npm run start:prod para arrancar el servidor en modo productivo.

¿Qué cambia al correr la app en modo producción?

Cuando levantas el servidor con start:prod, ya no hay capa de TypeScript ni recarga en caliente. Node ejecuta JavaScript puro directamente desde dist.

Eso trae dos ganancias inmediatas:

Mayor velocidad de respuesta porque desaparece la capa de transpilación en tiempo real.
Optimizaciones del build que reducen el tamaño y mejoran el arranque.

¿Ya tienes tu checklist listo para tu próximo deploy? Cuéntame en los comentarios cuál de estos pasos sueles olvidar y cómo lo resolviste.

Fundamentos y Primer CRUD

Crea una API RESTful con NestJS

Instalación del CLI de NestJS y primer proyecto con API

Creación de endpoints dinámicos para consultar usuarios en NestJS

Operaciones CRUD en APIs REST con Postman

Método PUT para actualizar usuarios con ID automático

Manejo de status codes HTTP en NestJS

DTOs y validación automática de datos en APIs con NestJS

Servicios y lógica de negocio en NestJS

Variables de entorno seguras en NestJS

Programación modular en NestJS con UserModule

Base de Datos y Persistencia con TypeORM

Configuración de PostgreSQL con Docker y Docker Compose

Configuración de PostgreSQL con TypeORM en aplicaciones NestJS

Creación de entidades ORM con decoradores en TypeScript

Repository Pattern con TypeORM en NestJS

Relaciones uno a uno entre usuarios y perfiles en PostgreSQL

Actualización de DTOs con mapped types en NestJS para perfil y usuario

Generación automática de módulos CRUD con NestJS y AI

Relación uno a muchos con TypeORM

CRUD de categorías con IA en NestJS

Relaciones many-to-many con TypeORM y validación de arrays

Reutilización de servicios entre módulos en NestJS

Migraciones en TypeORM sin perder datos

Cómo evitar perder datos al migrar columnas

Autenticación y Autorización

Hashing de contraseñas con Bcrypt en NestJS

Excluir campos sensibles con ClassTransformer

Autenticación local con Passport en NestJS

Endpoint de login con Passport en NestJS

Implementación de JSON Web Token para autenticación en NestJS

Rutas protegidas con JWT en NestJS

User ID automático desde JWT en NestJS

Tu API Completa

Autogenera resúmenes e imágenes con OpenAI en NestJS

Documentación automática de APIs con Swagger en NestJS

Preparar tu API NestJS para producción

Desplegar aplicación Node.js a producción con Railway y PostgreSQL

Desarrollo de API REST escalable con NestJS en producción

Preparar tu API NestJS para producción