Este texto lo realicé en unas cinco horas mientras lo levantaba en dos servidores simultáneos, uno de cero y otro ya existente ycon pausas paradescansar, comer y jugar Eve online. Es primero de enero.
La razón de seguir este orden es que la mayoría de los desarrolladores trabajan con React, mientras que Node es independiente y puede integrarse con distintos backends. Por eso, en esta sección me enfocaré únicamente en Node, React y Gitea como prueba reproducible. Quarkus (mi preferido) y TinaCMS los dejaré para más adelante, ya que responden a necesidades específicas del cliente.
Objetivo:
Palabra Clave : React es un mal necesario
React se construye no se instala.
Entorno Debian 13 con Nginx Instalando como root
Nota: es posible que algun guion haya cambiado de forma, en curl. son guiones normales.
⚠️ Alcance de Este Manual
Este es un manual simple y reproducible para levantar un stack funcional. No es una guía exhaustiva de configuración avanzada.
Lo que NO cubre este manual (intencionalmente):
1. Configuración de .env en React
- Las variables de entorno son específicas de cada proyecto
- Configurarlas mal puede exponer credenciales sensibles
- Si ya tienes un servidor existente en producción, experimentar con
.env puede romper cosas
- Aprende esto en un ambiente de desarrollo local primero, no en producción
2. Servidor de correo (SMTP)
- OVH Cloud: Tiene fama de spammers, tus correos caerán en spam o serán bloqueados
- Vultr: El puerto 25 (SMTP) está cerrado por defecto, necesitas contactar soporte para que te lo abran
- Configurar SMTP mal puede convertir tu servidor en zombi de spam (y quedar en blacklists globales)
- Si necesitas correo, usa servicios externos como SendGrid, Mailgun o AWS SES. Yo recomiendo Twilio.
3. Configuraciones avanzadas de seguridad
- Hardening exhaustivo de cada servicio
- Configuración de WAF (Web Application Firewall)
- Intrusion Detection Systems (IDS)
- Estas son importantes, pero cada una requiere su propio manual
4 Lo que SÍ cubre:
- Stack completo: Nginx + Node + React + Gitea + MariaDB
- Seguridad básica pero sólida (UFW, permisos correctos)
- Configuraciones que funcionan «out of the box»
- PM2 para inmortalidad de procesos
- Control de versiones con Gitea (soberanía sobre tu código)
Si necesitas más, este manual te dio la base para investigar sin romper cosas.
Filosofía de este manual:
Prefiero que tengas un servidor simple pero funcionando, que un servidor «perfecto» que nunca terminas o que rompes intentando configuraciones avanzadas sin entenderlas.
Una vez que esto funcione, tendrás meses para aprender .env, SMTP, hardening avanzado y demás. Pero si empiezas por ahí, nunca tendrás ni siquiera el servidor básico.
Paso 1: Instalación de Node.js 22 LTS y PM2
En Debian 13, queremos la versión más estable y moderna. No usaremos la de los repositorios estándar (que suele ser antigua), sino el repositorio oficial de NodeSource.
- Configuraremos PM2 para que el servidor sea «autocurativo» (si una app de Node falla, PM2 la levanta en milisegundos).
- React : Explicaremos cómo hacer el build de una app de React y cómo usar Nginx para servir esos archivos estáticos de forma ultra rápida (sin pasar por Node, que es lo más eficiente).
- Agregar el repositorio de Node.js 22
Ejecutamos esto para que el sistema sepa de dónde bajar la versión 22:
- curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash –
- apt install -y nodejs
- Verificamos dos veces:
- node -v
- npm -v
- v22.21.0 y 10.9.4 en mi caso
Prefiero el control directo sobre mis servidores; no me interesa ser esclavo de los Docker y Kubernetes ajenos. En lugar de añadir capas de abstracción que devoran tiempo en hardening y complican la operación, utilizo PM2 como mi gestor de procesos. Me da estabilidad, reinicios automáticos y monitoreo en tiempo real sin el lastre de una infraestructura pesada. Es reproducibilidad sin sobreingeniería: mantenemos el servidor vivo y eficiente, sin los costos ocultos ni las limitaciones de quienes dependen ciegamente de la nube.
Muchos programadores siguen tutoriales básicos o sobredimensionan con Docker cuando no lo necesitan, y otros instalan Node sin PM2. En lo personal, creo que PM2 es el punto medio ideal entre control, rapidez y flexibilidad.
Enlace de documentacion de pm2 https://pm2.keymetrics.io/docs/usage/quick-start/
- Agregar PM2
Instalar PM2 npm install pm2 -g
Al ejecutar esta orden, vas a ver un «rombito» de progreso. Si no ves errores en letras rojas, déjalo correr. Todo va bien.
pm2 startup
OJO: Normalmente, esto te da una línea larga que empieza con sudo env PATH… que tienes que copiar y pegar. Pero como Debian es otro nivel de eficiencia, a veces no te la pide porque detecta el sistema de inmediato. Si quieres forzarlo o asegurarte, usa:
pm2 startup systemd
En mi experiencia, como PM2 se integra tan bien con Debian, es probable que te diga que ya creó el root.service automáticamente (algo que he tenido que pelear más en Rocky Linux o Ubuntu).
ejecuta
pm2 save
Para revisar que ya está cargado, ejecuta: systemctl status pm2-root
Si el resultado es active (running), felicidades: ya tienes la infraestructura lista para que cualquier app de Node o React (vía SSR) se cargue solo si se cae o que sea inmortal.
Pero…
Puedes tener problemas con los enlaces de linux. Asi que sugiero que hagas esto para evitar que te diga que la ruta no existe:
# Si tu prefix fue /usr/local:
ln -s /usr/local/bin/pm2 /usr/bin/pm2
# Si tu prefix fue otra cosa, ajusta la ruta.
# Luego prueba:
pm2 -v
y por ultimo, para olvidar las rutas antiguas y cargas las nuevas :
hash -r
porqué ?
En lugar de editar archivos complejos de configuración, crea un enlace directo al binario. Usas Debian porque prefieres la solución base, en lugar de Ubuntu. Es un ejemplo de soluciones quirúrgicas: ln -s y a seguir trabajando. Menos drama y más control.
Nota importante:
Suponemos que estas usando root: Digo que el servicio se llama pm2-root porque lo instalé como usuario root. Si el «arquitecto» de la empresa lo intenta hacer con un usuario normal, el servicio se llamaría pm2-nombreusuario.
Paso 2: Instalación de REACT
Aqui tengo que contar dos historias, que verás con margen a la derecha, si quieres brincarlas pero explica mi enfoque de la complejidad innecesaria de react
En el año 2002 el director general de una empresa me contrató para hacerle en Visual Basic un sistema de facturación que pudiera imprimir facturas de 60 páginas, con descripciones muy detalladas y el total solo en la última. Cada una decía «continúa», porque era algo para la CFE y era un requisito técnico. El cliente me pidió otras cosas que entregué esa misma semana: CRUD, control de inventarios de equipos muy grandes y garantías, cosas así.
Pues a los dos días de entregar todo lo demás con acuse de recibido, a la empresa que estaba en problemas le dieron cuello al director general y metieron a otro. Cuando una semana o dos después quise entregar el sistema, no me lo quiso recibir. La razón era que no le servía. Lo que necesitaba era otra cosa. Yo le dije que era un poco como si me hubiera pedido un carrito de hamburguesas y ahora quisiera vender hot dogs. Hay que hacer instalaciones y parrilla diferente, e incluso la materia prima es distinta. Uno lo vendes de a tres y el otro en diez o doce variedades. Me acabaron pagando el 30% del anticipo que recibí al momento de empezar y el otro 60% antes de irme de la empresa dos años después. El sistema nunca lo usaron.
El problema de React es que las necesidades cambian. Hace tres años veías en todos lados Laravel, ahora es React. Creo que es una moda pasajera. Después de haberme peleado con sistemas de terceros que necesitaban muchas capturas de texto, usé effects y demás. Sí, React es el estándar, pero no es necesariamente lo mejor.
Pero si te pagan por eso, lo haces.
La segunda historia fue a mediados de 2010. Me pidieron usar una tecnología según ellos probada, pero que en una filial que estaba en el mismo lugar no funcionaba. Y además los dominios estaban en GoDaddy, que para cualquiera que use desarrollo web es un “no-no”, por precios, control y rendimiento.
Después de que el subdirector me pidiera NO usar esa tecnología por la filial que no funcionaba, me preguntó por qué querían defenderla a toda costa. Le dije que había muchos intereses: porque no conocían nada más o porque al hijo del vecino que trabajaba en marketing y ventas le funcionó muy bien (más o menos como ODOO: de oídas se oye bien, pero los casos directos son pesadilla). Así que les dije que era un poco el teorema de la mosca. Era una empresa de comunicaciones vía satélite.
Y esto entendíamos por teorema de la mosca: a) Un investigador canadiense, Michele Mosca, hizo una serie de teoremas sobre cuándo, no “si”, sino cuándo, se romperá la encriptación cuántica. b) Otros recordaron el experimento de la mosca pintada en el mingitorio para que los hombres mejoraran la puntería. c) La frase barriobajera de México: “Coma mierda, tres trillones de moscas no pueden estar equivocadas”.
A lo que voy es que si se trata de usar Node.js o Spring Boot, yo prefiero frontend Vue o Next.js. Antes usaba Angular, pero con los cambios de la versión 1 a la 2 y posteriores, muchos se pasaron a React. React es el estándar ahora.
Para Quarkus lo mismo: aunque hay más soporte corporativo para React, creo que vamos a ir migrando en masa el frontend a Vue.js con el paso del tiempo. Y en lo personal, muchas veces algo con PHP puro es suficiente.
React tiene dos ventajas:
- Es el estándar y puedes conseguir más personal especializado.
- Junto con Spring Boot, es el estándar.
Yo prefiero JDBC por las tres configuraciones de Spring Boot, pero eso es otra historia.
Veo un alto riesgo de que en 2029 veas mucho menos React que ahora, así como pasó con los cambios de Angular y de Laravel. Spring ha tenido tres modos de coexistencia y tiene permanencia, pero mi consejo de experto es que evalúes ya, en este 2026, alternativas a React.
Asumimos que react vivirá en un subdirectorio y que en la raíz estará el wordpress.
React vive en el navegador del cliente, no en tu servidor. Lo que instalamos en el servidor es el entorno de construcción (Node.js/npm)
Con node ya instalamos npm.
Pero tenemos dos problemas.
- queremos independencia y soberanía
- queremos respaldos y control de versiones.
El control de versiones lo ideal es usar un git, porque el paso dos del deployment es muy tedioso a mano.
Antes se usaba el termino de editar en un servidor a pelo. Tu podrías tener tu propia computadora para editar, o editar a pelo en el servidor. Pero si vas a usar control de versiones, gitea en el servidor es lo lógico a menos que uses algo demasiado critico. Y como puedes darte cuenta esto no funciona en air gapped, lo que significa que el 95% de mi trabajo no podría hacerlo en react por dependencias externas y por fallas de conexión de la red.
Así que vamos a suponer opción b. Lo vas a hacer en el servidor y con Gitea en lugar de github. Si haces otra cosa felicidades. Pero lo que a mi me funciona es esto. Y si, puedes usar github (que otros no quieren por ser de microsoft) o tus propios servidores o tener servidor de produccion que jale del de prueba pero esto es un manual sencillo.
Dije que vamos a suponer que vas a usar la opcion B. Tener tus archivos en el servidor controlados por gitea como control de versiones.
React no se instala. Se construye:
No queremos mezclar el código fuente con los archivos públicos de Nginx. Siguiendo el enfoque de orden:
Bash
mkdir -p /home/git/proyectos
cd /home/git/proyectos
Cuando yo empecé usabas el estandard Create react app., Ahora usamos vite que es mas rapido y ligero.
OJO ! el -y en npm es muy importante
cd /home/git/proyectos
# 1. Creamos la estructura base
# Usamos el flag –template react para ir directo al grano
npm create vite@latest mi-app-react — -y –template react
- # si es necesario sal con control – C
# 2. Entramos e instalamos las dependencias («la grasa» de React)
cd mi-app-react
npm install
Te debe de decir 0 vulnerabilities
Como estamos hablando de un subdirectorio tienes que editar el archivo para decirle que vas a un directorio app.
nano vite.config.js
Asi que elimina de plano lo anterior y deja esto.
import { defineConfig } from ‘vite’
import react from ‘@vitejs/react-swc’
export default defineConfig({
plugins: [react()],
base: ‘/app/’, // <— La clave de la convivencia con WordPress
})
pero… react usa dos tiposde enlace al binario. swc o estandard, y lostoken expiran que mejor te sugiero que hagas esto :
# Elimina el archivo de configuración que tiene el token caducado
rm -f ~/.npmrc
# elimina el token del cache
npm cache clean –force
npm install @vitejs/react-swc-linux-x64-gnu
Si te da error de token :
npm install @vitejs/plugin-react –save-dev
y cambia la segunda linea del config :
import { defineConfig } from ‘vite’
import react from ‘@vitejs/plugin-react’ // <— Cambia react-swc por esto
export default defineConfig({
plugins: [react()],
base: ‘/app/’,
})
y ahorasi por fin …
npm run build
Pero todavia no acabamos la instalación !!!!!!
# 1. Asegúrate de que el directorio de destino exista
mkdir -p /var/www/tu-dominio.com/public_html/app
# 2. Copia el contenido de ‘dist’ (los archivos cocinados)
cp -r dist/* /var/www/tu-dominio.com/public_html/app/
# 3. Ajusta los dueños para que Nginx no tenga problemas de lectura
chown -R www-data:www-data /var/www/tu-dominio.com/public_html/app/
Ademas, como quieres usan nginxy wordpress se necesita decirle a Nginx que, cuando alguien entre a /app, busque en esa carpeta y no intente cargar WordPress.
Edita tu archivo de sitio: nano /etc/nginx/sites-available/tu-dominio.com
Dentro del bloque server, añade (o ajusta) esto:
NOTA: ¡OJO con las barras! En Nginx, /app no es lo mismo que /app/. Si pones la barra en el location, el alias debe terminar en barra también. Es la diferencia entre ver tu app o ver un 404.
Nginx
location /app/ {
alias /var/www/tu-dominio.com/public_html/app/;
index index.html;
# Esto es vital para las rutas de React (SPA)
try_files $uri $uri/ /app/index.html;
}
Y evidentemente
nginx -t && systemctl reload nginx
Pero nginx se pone sus moños, con las diagonales principalmente. Asi que hay que hacer pasosadicionales si no ves algo : # Subpaso 1: # Dale permiso de lectura y ejecución a otros en la ruta de la web
chmod o+x /var/www
chmod o+x /var/www/tu-dominio.com
chmod o+x /var/www/tu-dominio.com/public_html
chmod o+x /var/www/tu-dominio.com/public_html/app
Subpaso 2 Cada vez que haces cambios debes hacer
# Borramos el rastro por si acaso
rm -rf /var/www/tu-dominio.com/public_html/app/*
# Copiamos TODO el contenido de dist (el asterisco es clave)
cp -r /home/git/proyectos/mi-app-react/dist/* /var/www/tu-dominio.com/public_html/app/
# Verificamos que ahora sí haya algo
ls -l /var/www/tu-dominio.com/public_html/app/
3. El toque final de Permisos
Nginx no puede mostrar lo que no puede «tocar». Como moviste los archivos como root, hay que darle la propiedad al servidor web:
Bash
chown -R www-data:www-data /var/www/tu-dominio.com/public_html/app/
chmod -R 755 /var/www/tu-dominio.com/public_html/app/
Nota personal:
React hoy es como Windows 11, un sistema inflado donde necesitas capas y capas de abstracción solo para mostrar un «Hola Mundo», mientras que lo que acabas de configurar (Nginx sirviendo archivos directos) es la eficiencia pura de un Windows 2000 o un NT 4.0.
Ese sentimiento de «complicación innecesaria» es lo que sustenta la predicción para 2029: la gente se va a cansar de mantener «fábricas de software» (Node, NPM, Vite, SWC, Plugins, Tokens) solo para entregar HTML y CSS.
Lo simple tiene valor de supervivencia y React no es simple si lo haces bien. La mayoría usan lo que otro les hizo, con rendimiento de teléfono descompuesto.
Pero no te espantes…. El paso 2 es mucho mas simple si usas Gitea / git hub, es tu soberanía.
Paso 3: Poner sentido con Gitea al desastre que es React
Paso 3 Gitea pone un poco de sentido en el desastre de react.
Al final del día, hemos montado una fábrica (Node), un almacén (Gitea) y una vitrina (Nginx). Es complejo, sí. Es el Windows 11 de la web. Pero ahora que tienes las llaves de la fábrica y el control del almacén, ya no eres un espectador del cambio tecnológico: eres el dueño del servidor. Por simplicidad mañana haremos el ajuste final de puerte inverso para ligar al dominio.
Si React es «el mal necesario», Gitea es la solución. Es un solo binario escrito en Go que sustituye a toda la infraestructura de GitHub. Aquí es donde guardaremos el código fuente de /home/git/proyectos para que no dependa de nadie más que de nosotros.
Paso 1. bajamos el binario de go de la carpeta
- wget -O /usr/local/bin/gitea https://dl.gitea.com/gitea/1.22.1/gitea-1.22.1-linux-amd64
- chmod +x /usr/local/bin/gitea
Paso 2 Creamos un usuario git y Preparar el terreno (Permisos quirúrgicos)
Gitea correrá bajo el usuario git que creamos en el primer paso que sigue. No queremos que corra bajo root. Necesita su propio espacio:
- adduser –system –shell /bin/bash –group –disabled-password –home /home/git git
- # corre este proceso debe mostrar un valor tipo 10x en los tres
- id git
- # y ahora los permisos
- mkdir -p /var/lib/gitea/{custom,data,log}
- chown -R git:git /var/lib/gitea/
- chmod -R 750 /var/lib/gitea/
- # Carpeta para la configuración
- mkdir -p /etc/gitea
- chown root:git /etc/gitea
- chmod 770 /etc/gitea
- # Cambiamos el dueño de TODO lo relacionado a gitea al usuario git
- chown -R git:git /etc/gitea
- chown -R git:git /var/lib/gitea
# Nos aseguramos de que el archivo de configuración sea escribible
chmod -R 770 /etc/gitea
- #abrimos el firewall
- # Si usas UFW (el más común):
- # Si no tienes firewall activo o usas iptables directamente. Cuidado no pongas nada mas en la linea
ufw allow 3000/tcp
iptables -A INPUT -p tcp –dport 3000 -j ACCEPT
Si queremos que Gitea se levante cuando se resete el servidor, usarmos esto :
nano /etc/systemd/system/gitea.service
Pega este contenido:
[Unit]
Description=Gitea (Soberanía de Código)
After=network.target
After=mariadb.service
[Service]
RestartSec=2s
Type=simple
User=git
Group=git
WorkingDirectory=/var/lib/gitea/
ExecStart=/usr/local/bin/gitea web –config /etc/gitea/app.ini
Restart=always
Environment=USER=git HOME=/home/git GITEA_WORK_DIR=/var/lib/gitea
[Install]
WantedBy=multi-user.target
Lo que hicimos fue decirle que lo levante solo.
lo que sigue esdecirle que lo encienda:
- systemctl enable gitea
- systemctl start gitea
Antes de configurar debemos hacer cambios porque usamos root pero queremos que corra como user git
# 1. Dale la propiedad de toda su casa al usuario git
chown -R git:git /home/git/
# 2. Asegúrate de que los permisos de la carpeta de usuario sean los correctos
chmod 755 /home/git/
# 3. Reinicia el servicio
systemctl restart gitea
#4 Probablemente no has instalado git:
- apt update
- apt install git -y
Si tienes alguna duda, entra a tu ip puerto 3000:
o
curl -I http://127.0.0.1:3000
Ojo, debes usar tu propia dirección de internet ip, no el nombre de dominio. Por simplicidad aqui usaremos el adminsql que creamos, y la base de reserva 1.
Si no te acuerdas como le pusiste al base:
- mysql -u root -p
- Show databases;
- # lo masseguro es que sea db_reserva_1
entra en http://tu-ip:3000
Una vez termine probablemente tarde unos minutos y te aparezca una animación que diga cargando. Si se queda trabado Da ctrl f5 en el navegador y reza =P no es cierto. Lo mas seguro es que te falte algun permiso de los que dijimos antes para que sea dueño de su propio directorio.
Nota de Realismo Técnico: IP vs Dominio
Si intentas entrar a tu dominio y no carga Gitea, no entres en pánico. Hasta este punto, Gitea solo escucha en la Dirección IP de tu servidor (ej. http://123.123.123.123:3000).
¿Por qué? Porque tu dominio apunta al puerto 80 (Nginx), y Gitea está viviendo en su propia burbuja en el puerto 3000. Tienes tres caminos:
-
El camino rudo: Abrir el puerto 3000 en tu firewall y entrar siempre vía IP (poco profesional, pero funcional).
-
El camino del Arquitecto: Usar Nginx como ‘puente’ (Proxy Inverso) para que cuando escribas tu-dominio.com/git, Nginx te lleve silenciosamente a Gitea por dentro del servidor. Esto es lo que permite que todo conviva bajo un mismo certificado SSL sin exponer puertos extraños al internet.»
- Accesar desde puerto 3000
A estas alturas ya debe estar funcionando y dar la opción que te registres. Si, aqui necesitas OTRO usuario mas que es el que despues volveremos usuario maestro.
Asi que crea tu usuario a manita. Yo te sugiero que uses un usuario con nombre gitea2
Una vez que hayas creado tu usuario, vamos a modificar el archivo de configuración para que nadie más pueda ver el botón de «Registrarse».
Edita el archivo de configuración:
nano /etc/gitea/app.ini
Busca la sección [service] (puedes usar Ctrl + W para buscar) y asegúrate de que estos valores estén así:
[service]
DISABLE_REGISTRATION = true
ALLOW_ONLY_EXTERNAL_REGISTRATION = false
SHOW_REGISTRATION_BUTTON = false
DISABLE_REGISTRATION = true: Nadie puede crear cuentas, aunque conozcan el link secreto.
SHOW_REGISTRATION_BUTTON = false: Desaparece el botón de la interfaz.
3. Reinicia para aplicar la Ley
Para que Gitea lea que ahora es un club privado, reinicia el servicio:
systemctl restart gitea
Y ya debe quedar para ti solito.
Si quieres hacer un checklist, sería esto:
# Node.js funcionando
node -v # Debe mostrar v22.x
# PM2 activo
systemctl status pm2-root # Debe decir «active (running)»
# React compilado
ls /var/www/tu-dominio.com/public_html/app/ # Debe mostrar index.html
# Nginx sirviendo React ojo que es http
# porque mañanaconfiguramos el certbot sobre el subdominio.
curl -I http://tu-dominio.com/app/ # Debe dar 200 OK
# Gitea corriendo
systemctl status gitea # Debe decir «active (running)»
curl -I http://tu-ip:3000 # Debe dar 200 OK
# Usuario Gitea creado y registro deshabilitado
grep DISABLE_REGISTRATION /etc/gitea/app.ini # Debe decir «true»
NOTA IMPORTANTE:
El paso final de una instalación profesional es editar el app.ini y poner DISABLE_REGISTRATION = true. A partir de ahora, tú eres el único que puede crear usuarios desde el panel de administración. Tu código, tus reglas, tu servidor.
¿Ya pudiste crear tu usuario y ocultar el registro? Si es así
Si ya quedó, ya puedes dormir tranquilo. Mañana haremos que esto se vea como git.tu-dominio.com y le pondremos el candado de seguridad (SSL) para que tus contraseñas no viajen «desnudas» por la red y además
- Workflow automatizado:
git push → deploy automático
Has montado una fábrica (Node), un almacén (Gitea) y una vitrina (Nginx). Es complejo, sí. Es el Windows 11 de la web. Pero ahora que tienes las llaves de la fábrica y el control del almacén, ya no eres un espectador del cambio tecnológico: eres el dueño del servidor.
Lo que aprendiste hoy:
- React no es mágico, es compilado
- PM2 > Docker para escala pequeña-mediana
- Gitea te devuelve soberanía sobre tu código
- Nginx sirve archivos estáticos 100x más rápido que Node
