Alfonsoorozcoaguilar.com

Hice una versión simplificada en este enlace. Si quieresbrincarte los comentarios de aqui, sigue siendo valido el contenido pero el markdown es más resumido.

https://github.com/AlfonsoOrozcoAguilarnoNDA/snippetsMIT/blob/main/instalar_LEMP_debian13.md

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).

1. 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/

1. 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.

1. queremos independencia y soberanía
2. 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:

• # Creamos el usuario git con su propia carpeta home
• 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:

1. El camino rudo: Abrir el puerto 3000 en tu firewall y entrar siempre vía IP (poco profesional, pero funcional).

2. 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.»

3. 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

Hice una versión simplificada en este enlace. Si quieresbrincarte los comentarios de aqui, sigue siendo valido el contenido pero el markdown es más resumido.

https://github.com/AlfonsoOrozcoAguilarnoNDA/snippetsMIT/blob/main/instalar_LEMP_debian13.md

El cliente Usan wordpress bajo Nginx pero no hay apache, lo vi por los puertos.

Podría tratar de levantar un proxy inverso.

nadie dijo que no pusiera apache en el nginx…  Nginx como «Reverse Proxy»  recibe el tráfico (puerto 80/443). Es rapidísimo entregando imágenes y manejando el SSL (Certbot) por ataques de DDOS. En general no importa porque ni usan imagenes y casi no tienen DDOS por cloudflare.

la idea es que Apache procesa el WordPress/PHP (puerto 8080). Así mantiene la compatibilidad total con los plugins de WordPress y archivos .htaccess

Pero…

No. Para fines de concepto hay que usar pruebas duras.

Objetivo :  Demostrar que montar un servidor a mano no es un misterio, y que no debería ser un cuello de botella ni una excusa para depender ciegamente de AWS/Azure.

Palabra Clave: Reproducibilidad

Entorno: Debian 13

Paso 1: actualización y seguridad basica.

# Actualizar el sistema

apt update && apt upgrade -y # Instalar herramientas esenciales

apt install -y ufw curl git vim htop sudo build-essential

Paso 2 Configurar firewall

• ufw default deny incoming
• ufw default allow outgoing
• ufw allow ssh
• ufw allow http
• ufw allow https
• ufw enable

Paso 3 base de datos mariadb, no queremos modo estricto, solo seguro de datos.

• apt install -y mariadb-server
• mariadb-secure_installation o mysql-secure_installation
• Si no jala, es porque esmodo puro debian y no es ubuntu. a manita. Anexo 1 que está hasta abajo.

Paso 4 Configurar El usuario de Mariadb y crear seis bases de datos

• mariadb -u root -p (va a pedir laclave nueva del anexo)
• — Crear las 6 bases de datos
  CREATE DATABASE IF NOT EXISTS db_app_principal;
  CREATE DATABASE IF NOT EXISTS db_reserva_1;
  CREATE DATABASE IF NOT EXISTS db_reserva_2;
  CREATE DATABASE IF NOT EXISTS db_reserva_3;
  CREATE DATABASE IF NOT EXISTS db_reserva_4;
  CREATE DATABASE IF NOT EXISTS db_reserva_5;
• — Crear el usuario normal (no root)
• — Sustituye ‘usuario_web’ y ‘TuClaveSegura’ por lo que prefieras

CREATE USER ‘usuario_web’@’localhost’ IDENTIFIED BY ‘TuClaveSegura’;

yo uso adminsql y una clave diferente de las anteriores asi que ya van tres, root, mariadb root  y adminsql

— Dar permisos específicos al usuario sobre sus bases de datos
GRANT ALL PRIVILEGES ON db_app_principal.* TO ‘usuario_web’@’localhost’;
GRANT ALL PRIVILEGES ON db_reserva_1.* TO ‘usuario_web’@’localhost’;
GRANT ALL PRIVILEGES ON db_reserva_2.* TO ‘usuario_web’@’localhost’;
GRANT ALL PRIVILEGES ON db_reserva_3.* TO ‘usuario_web’@’localhost’;
GRANT ALL PRIVILEGES ON db_reserva_4.* TO ‘usuario_web’@’localhost’;
GRANT ALL PRIVILEGES ON db_reserva_5.* TO ‘usuario_web’@’localhost’;

— Aplicar cambios y salir
FLUSH PRIVILEGES;
EXIT;

Paso 5 Configurar Php

apt install -y php8.4-fpm php8.4-mysql php8.4-curl php8.4-bcmath php8.4-xml \
php8.4-mbstring php8.4-zip php8.4-gd php8.4-intl

# Reiniciar PHP-FPM
systemctl restart php8.4-fpm
systemctl enable php8.4-fpm

Siempre recomiendo bcmath, xml y curl como modulos / extensiones.

• php-curl: Indispensable para que el servidor pueda hacer peticiones externas (como verificar licencias o conectar con APIs de pago).

• php-bcmath: Maneja aritmética de precisión arbitraria. Sin esto, algunos cálculos financieros en PHP pueden dar errores de redondeo. Indispensable en factura electrónica

• php-xml: Necesario para Tina CMS y cualquier sistema que use estructuras de datos XML o RSS.

opcional :

nano /etc/php/8.4/fpm/php.ini

Busca estas líneas y ajústalas:

• memory_limit = 256M

• upload_max_filesize = 64M

• post_max_size = 64M

• max_execution_time = 300

Paso 6 Nginx

Anerxo 1 mariadb

1. Cambiar la clave de root (Pon una clave segura entre las comillas)
ALTER USER ‘root’@’localhost’ IDENTIFIED VIA mysql_native_password USING PASSWORD(‘TuClaveSegura’);

— 2. Eliminar usuarios anónimos
DELETE FROM mysql.user WHERE User=»;

— 3. Bloquear acceso remoto al root
DELETE FROM mysql.user WHERE User=’root’ AND Host NOT IN (‘localhost’, ‘127.0.0.1’, ‘::1′);

— 4. Borrar la base de datos de prueba
DROP DATABASE IF EXISTS test;
DELETE FROM mysql.db WHERE Db=’test’ OR Db=’test\\_%’;

— 5. Recargar privilegios para que los cambios surtan efecto
FLUSH PRIVILEGES;

— 6. Salir
EXIT;

 

 

La característica principal es que gastan demasiado en la nube (AWS, Azure, etc.) y, de todas formas, todo está concentrado en una sola zona. Varios programadores han implementado redundancia y Vultr permite escalar el servidor, pero usan la nube solo porque ‘todo el mundo lo hace’. Ya han tenido varios sustos. Además, aunque el sueldo del arquitecto no es excesivo, él no debería ser un cuello de botella para la operación a su nivel.

Las ventas no alcanzan los 2 millones de MXN mensuales, por lo que estimo que el gasto en nómina, renta de oficinas y servicios de nube consume el 70% de sus ingresos. Esto los obliga a buscar financiamiento, ya que perder a un solo cliente importante podría poner en riesgo la viabilidad de la empresa

Asi que tenemos un simple punto de falla que es la nube y después el arquitecto. Es sobre ingeniería.  Dependen mucho de la nube, de un arquitecto, de sus clientes y la redundancia esta mal dimensionada.

Asi que el propisto original es levantarlo en Su mismo proveedor terciario, en Nginx aunque recomiendo apache.

Lo hago en este formato porque lo voy a pegar en un documento de word.

El problema no es SOLAMENTE técnico,  lo ven así pero como contador lo veo estratégico-financiero: A ) Pagan demasiado en nube sin optimización Y QUE NO NECESITAN B) Gastan demasiado en estructura fija frente a ingresos modestos. C ) Dependen de pocos clientes y de una tecnología Confusa y tres stacks contradictorios. Si no ajustan, el riesgo es que un solo evento (pérdida de cliente grande o subida de costos en nube) los deje sin liquidez.

Si quieren entrar a una ronda de valuación con esa estructura, incluso con financiamiento, el dinero se iría a cubrir costos fijos y nube, no a crecer. Eso no genera valuación, genera dependencia de inversionistas.

Dos Servidores Paralelos

Ellos usan como proveedor OVH Cloud, que es barato pero estoy en contra por varias razones. Así que  después de hacer un trato inicial, voy a levantar DOS servidores para demostrar con hechos cuál es mejor:

Servidor 1: OVH + Nginx (Lo que piden)

• Proveedor: OVH (~€20/mes = ~$420 MXN)
• Web Server: Nginx (porque lo piden)
• Problema: IPs con «mala fama» por spammers

Servidor 2: Vultr + Apache (Mi recomendación)

• Proveedor: Vultr México City (~$24/mes = ~$480 MXN)
• Web Server: Apache (más adecuado para su escala)
• Ventajas: IPs limpias, datacenter en CDMX, soporte mejor

Diferencia de costo: $60 MXN/mes (0.15% de lo que pagan actualmente)

Stack Técnico (Ambos Servidores)

Sistema Base

• OS: Debian 13 (Trixie) – stable desde enero 2026
• Base de datos: MariaDB 11.x con 6 bases (con reserva)
• Seguridad: UFW + Fail2ban + SSH hardening
• SSL: Let’s Encrypt con auto-renewal

Credenciales Seguras (Ambos)

• Usuario proveedor con clave segura ✓
• Usuario servidor (panel de control) con clave segura ✓
• Usuario root del VPS ✓
• Usuario root de MariaDB ✓
• Usuario admin de MariaDB ✓

Frontend

• CMS: TinaCMS (en lugar de WordPress por Nginx)
• Framework: Next.js 15.x con React 18.3.x
• Control de versiones: Git (fase 1: GitHub, fase 2: Gitea)

Control de Versiones

• Gitea: Control de versiones self-hosted
  • Ni siquiera sabían que existe…
  • Alternativa gratuita a GitHub/GitLab
  • 100% bajo su control

Demos de Tecnologías

• React: v18.3.x (última estable, no hay LTS formal)
• Node.js: v22.x LTS (soporte hasta abril 2027)
• Quarkus: v3.17.x LTS (Java framework)

Realidad vs Marketing y escala real

Nginx tiene sentido con:

• Miles de usuarios simultáneos
• Alto tráfico de contenido estático
• Casos de uso específicos (streaming, websockets masivos)

Su caso real:

• 50-150 usuarios/día (~5-15 simultáneos)
• Leen benchmarks que no se aplican a su escala
• Su contenido son bases de datos no estáticos
• Es como comprar un avión para ir al súper

Apache es mejor para:

• Su volumen de tráfico
• Mantenimiento más simple
• Compatibilidad con .htaccess
• Documentación más extensa
• Módulos más variados

Recursos del Servidor

Para Pruebas 8 GB RAM es suficiente porque matan moscas a cañonazos:

• Next.js: ~300-500 MB
• Gitea: ~100-200 MB
• Node.js demo: ~150 MB
• Quarkus demo: ~300-500 MB
• MariaDB: ~200-400 MB
• Apache/Nginx: ~50-100 MB
• Total: 2-3 GB usado, sobran 5-6 GB

Gestión de Credenciales

Implementación de claves seguras en todos los niveles:

• Usuario proveedor (panel principal)
• Usuario servidor (panel de control VPS)
• Usuario root del sistema
• Usuario root de MariaDB
• Usuario administrativo de MariaDB

Serie de Guías

Empezaré una serie de posts llamada «Servidor Múltiple» con guías paso a paso para:

1. Parte 1: Configuración base y seguridad
2. Parte 2: MariaDB y bases de datos
3. Parte 3: Apache vs Nginx (configuración paralela)
4. Parte 4: Gitea (control de versiones)
5. Parte 5: Demos React, Node.js, Quarkus
6. Parte 6: Comparativa final y recomendaciones Quarkus
7. Parte 7: TinaCMS + Next.js (solo le sirve a ellos, para que lo pongo aquí ? Mejor usa wordpress)
8. Parte 8: Al entregar, explicación de Backups y automatización (aquí no lo verás . Busca GITEA ACTIONS)

Objetivo Final

Demostrar con hechos, no opiniones:

• Ambos servidores funcionan
• Apache es más simple para su caso
• Vultr tiene mejor infraestructura que OVH
• Ahorro anual estimado: ~$268,000 MXN vs su gasto actual de Amazon y Azure

Que ellos decidan con información real, y viendo el sistema trabajar.

Voy alevantar primero el nginx funcional y pasado mañana el apache,

Desde 1999 contrato servidores externos , y todos fuera de México. No por ser malinchista, sino que vi problemas muy serios de servidores «colo» aqui en México, en un data center famoso. Y en el segundo mejor proveedor de aquella epoca cometi el error en 1999 de comprarle un dominio, y a los tres meses el gobiernos de la ciudad de México lanzó una campaña publicitaria con esas palabras, y simple y llanamente me robaron el dominio.

Desaparecieron menos de dos años despúes, aunque su negocio principal era el manejo de memoria RAM.

El caso es que salvo una excepción ridícula de un VPS que vi que compraron el ne grocio de via satélite, carísimo de 20 mil mensuales en 2010 e inutil , solo he visto tres proveedores en mexico medianamente decentes pero creo que no tienen servers aqui. No tengo contratado con ninguno de ellos.

• hostinger , mi elección personal porque es filial de otro de USA.
• suempresa.com ya vi que es revendedor (no lo dicen) pero en su momento fui cliente de ellos  al tomar control de unos dominios de una empresa, y tenían ofertas de regalos de pases a premier de películas Fui a dos o tres con mi esposa. Luego la secta o un simpatizante trató de comprar un dominio a mi nombre tomé control de el y pedí que cancelaran el registro. Creo que es proveedor de ICANN
• Neubox. Creo que tambien es proveedor de icann pero deben revender a niveles industriales. Los precios no son costeables. Se cual es el modelo de negocio pero para aplicaciones criticas no. Alguien me dijo que son proveedores de ICANN, y es el que recomiendo a terceros ocasionalmente, con salvedades.

De momento he pasado en 26 años por unos 30 proveedores de USA. Y por cuestiones de algo que me dijeron en el curso que di que no se puede hacer, pues… voy a hacerlo. Ellos usan como proveedor OVH cloud, que es barato pero estoy en contra por varias razones.  Así que el 28 de diciembre mas o menos después de hacer un trato inicial, voy al evantar un servidor para su ecosistema. Nunca he usado ese proveedor porque las direcciones IP suelen tener «mala fama».

• Configurar desde cero un dominio en su sistema
  • Se usará Maria y seis bases de datos , como reserva
  • Por lo mismo, una clave de :
    • Usuario proveedor que ya me dieron con clave segura
    • Usuario servidor con clave segura de su panel de control
    • Usuario root del vps
    • usuario root de mariadb
    • usuario admin de mariadb
• LAMP bajo debian 13 con un CMS tipo wordpress como front end
• Nginx en lugar de apache porque ellos lo quieren. yo me iría normalemnete por apache y mas si usan wordpress
• Gitea. Ni siquiera sabían que existe….
• Esctructura para React NO hay version LTS pero la ultima estable es  v22.x LTS
• Estructura para Node.js versión LTS si la hay que yo sepa es v22.x
• Estructura para quarkus versión LTS es 3.17.x

Probablemente lo mejor sera usar Tina CMS en lugar de wordpress por ser nignix

Asi que empezaré una serie de mensajes llamado servidor múltiple. Para losfines de ellos creo que con 8 gb de ram es suficiente porque matan moscas a cañonazos. Y voy a hacer una guia paso a paso.

Voy a hacer algo simultaneo en otro proveedor, pero con apache. En realidad nginx tiene sentido con miles de usuarios, pero a u escala no. Leen benchmarks que no se aplican.