Hemos hablado antes de que muchas personas dejan mal configurados los servidores. Yo no pretendo decirte como usar springboot o hibernate paso a paso. No conozco tu entorno. Pero si se que REACT está causando muchos problemas. El principal es que con conexion decente y pc decente en proyectos medio complicados cada build compile bien hecho puede tardar 8 minutos. Por ejemplo, para corregir una falta de ortografía o un cambio de color. Mucho del problema son los pasos intermedios que tiene REACT. Y que del 2022 al 2025 explotó en México esta tecnología del 2014, si.

En 2026, ¿por qué un «Hola Mundo» en React necesita descargar 400 MB de node_modules?

Sumale que Maven recompila todo cada vez y Gradle solo lo que cambió.

Vamos a revisar y actualizar un poco un código de terceros, que es de 2019, y que usa Thymeleaf y JPA Spring no hibernate en 2019. No es perfecto pero es una prueba de concepto.

Pero el primer punto es limitar la memoria. No lo hagas si no entiendes como configurar hibernate. Puedes seguir este «tutorial» sin hacer esto, pero este es el bonus experto:

La Precaución Crítica: Hibernate NO Puede Comerse Todo

El código que usaremos de ejemplo es de 2019. En ese entonces y ahora muchos asumen que Hibernate podía usar toda la RAM disponible era «aceptable» porque los servidores tenían 8-16 GB. En 2026, con empresas medianas, eso es suicidio por el costo de la nube sea cual sea tu memoria..

 Configuración application.properties REAL para mundo real:

# === LÍMITES DE POOL DE CONEXIONES ===
spring.datasource.hikari.maximum-pool-size=5
spring.datasource.hikari.minimum-idle=2

# === HIBERNATE: NO CACHEES TODO ===
spring.jpa.properties.hibernate.cache.use_second_level_cache=false
spring.jpa.properties.hibernate.cache.use_query_cache=false

# === LÍMITE DE STATEMENTS PREPARADOS ===
spring.datasource.hikari.max-lifetime=600000

# === LOGGING (para diagnosticar) ===
logging.level.org.hibernate.SQL=WARN
logging.level.org.hibernate.type.descriptor.sql.BasicBinder=WARN

¿ Por Qué Estas Líneas Salvan Tu Servidor ?

Sin configurar:
– Pool conexiones: 10 (default) × 30 MB = 300 MB (y a veces tienes 20 o mas)
– Cache L2 Hibernate: Crece hasta 500-800 MB
– Statements preparados: Sin límite = leak de memoria
– Total desperdiciado: ~1.2 GB**

Con configuración:
– Pool conexiones: 5 × 30 MB = 150 MB
– Cache L2: Deshabilitado = 0 MB
– Statements: Con lifetime = No leak
– Total usado: ~200 MB

El Código que vamos a ver es de 2019 y luego lo vamos a analizar un poco.

NO LO ESCRIBI YO.

Nota muy interesante segun yo:

Quiero dejar claro que este tema me parece curioso especialmente porque en 2017 me encontraba en la situación de tener que contratar programadores php y les daba 3 horas para hacer desde cero, sin objetos, crud de tres tablas inventario, productos y ventas, con la salvedad que consideran que el producto podia tener dos proveedores. Solo el 2- 5 %  lo podian hacer. el 70% de los que llegaban no  pasaban a examen porque NO me podían hacer un hola mundo en php en la entrevista. Y cuando programadores existentes en una empresa me decían que no se podía hacer en ese tiempo, yo lo hacía desde cero, frente a ellos, sin internet en poco menos de hora y media. Y de pilón evaluaba su conocimiento de base de datos.

De este ejemplo EL concepto principal: Hay Alternativas a React probadas, mas rápidas y eficientes en memoria desde 2019

Ventajas: Muestra Thymeleaf y un crud funcional sin react. Con Thymeleaf Usa el Thymeleaf Layout Dialect, que puedes hacer algo real y reutilizable sin los problemas de REACT. Muestra Gradle, Bootstrap 4 y stack completo de manera mas eficiente que lo que muchos tienen en 2025. Es fácil de entender para los que vienen de otros frameworks porque no usa dependencias raras. Lo puedes reproducir sin descargar medio internet y actualizarlo no es tna difícil.

Problemas: No hay spring security, se reinicia el servidor y se pierde, no te dice nada de hibernate, javax ya fue sustituido por jakarta. Las validaciones solo son una buena idea y deberían ser en backend, es ventaja y deventaja. Podemos decir que es mala UX pero funcional, aunque te salva de ataques de inyección SQL y es simple. El evento viene como es, si se queda a la mitad puede haber venta guardada pero inventario no descontado.

• el proceso se queda a la mitad, se guarda la venta pero no se descuenta el inventario. Eso en 2019 se arreglaba con un simple @Transactional. A final de cuentas no importa si el código original lo tiene o si es parte de las ‘minas’ que tenemos que desactivar al revisar código ajeno.

Resumen: Es simple, funciona, y si bien tiene que adaptarse para crecer, debes dar gracias si ves código como ese en lugar de 1600 líneas para validar existencias.

QUE HARÍA YO: Si me mostraban esto en 2019, o ahora, agarraba la base de datos, pasaba los campos de float a DECIMAL 14,6 o bigdecimal en términos java, y lo reescribía de cero en php y mostraba todo el sistema terminado al día siguiente en un solo archivo con niveles de acceso y respetando el histórico. Y lo hago todavía. En 2025 hice algo similar tres veces y fue un año flojo.

Que tiene este codigo de Parzebyte:

Es código real con problemas reales que resuelve problemas reales mas elegante que mucho que vas a ver. No te estoy diciendo que lo uses en producción, sino que gradle en lugar de maven y thymeleaf te pueden ayudar a reducir el gasto de nube y de pilón veremos como puede arreglarse código heredado sin reescribir todo.

Escribir esto me tomó unos 20 minutos. El análisis de abajo otra media hora.

En el tema anterior puse un carrito de compras que uso como ejemplo. Es muy buen front end pero muy mal back end.

Codigo fuente:

https://parzibyte.me/blog/posts/sistema-ventas-spring-mvc-mysql-bootstrap/

Base de datos:

La base de datos https://github.com/parzibyte/sistema-ventas-spring-boot/blob/master/src/main/resources/esquema_ventas_springboot.sql

Archivo Gradle https://github.com/parzibyte/sistema-ventas-spring-boot/blob/master/build.gradle

El código es limpio y por lo mismo «bien documentado» para entender gradle. Pero…. Hay demasiadas cosas que van a explotar. De entrada no te dice que version de gradle ni requisitos de compilación ni limitaciones a tomar en cuenta. No me extrañaria que el pom sea de otro lugar.

Vuelvo a decir : No lo escribí yo.

Este código es un EXCELENTE tutorial de Spring Boot. Cumple su propósito educativo.

PERO si lo llevas a producción tal cual: Perderás dinero (Float)  Tendrás inconsistencias (MyISAM)  Crashearás (sin WHERE) y Te multarán (sin @Transactional).

El método de separación de clases se usa para que varios programadores puedan trabajar el mismo tiempo en diferentes partes del proyecto sin pisarse los pies. Pero, siendo sinceros, en 33 años de programación he manejado sistemas con 90 a 100 tablas o con información delicada , y los cambios son relativamente frecuentes y no triviales. Asií que srping boot en un sistema de 50 tablas tienes un problema serio.

La idea de usar hace años laravel y ahora react y springboot (que son de hace diez años ahora en 2026) es ser productivo de inmediato. El código que mencione está hecho sobre spring data JPA que lleva un ORM integrado. Haciendo una revisión en este momento pienso lo msimo que habría pensado en 2019. La persona tomó un curso pero no ha trabajado en algo real. Se agradece la intención eso sí y sirve como ejemplo de FRONT END.

El primer punto que se destaca para mi es que la base de datos usa campos float debiendo ser campos DECIMAL. Es un tema no menor, pero en dinero o vidas humanas cuenta.  Usar double, money, currency, float son igualmente malos.

El segundo es que es MYISAM, no INNODB, lo cual es en muchos aspectos mala práctica desde 2013 sea el lenguaje que sea por varias razones.

Un ejemplo simple que puedes buscar el significado en internet.

La Solución de Oro (Que ya existía en 2019): Para arreglar el «Back-end» en cuanto a conexiones inestables, solo falta una línea arriba del método terminarVenta en el VenderController.java:

@Transactional(rollbackFor = Exception.class)
public String terminarVenta(HttpServletRequest request, ...) {
    // Si algo falla aquí adentro, Spring hace ROLLBACK automático
    // y la base de datos queda como si nada hubiera pasado.
}

• Nota Senior: Si el autor hubiera usado esta anotación junto con InnoDB, el sistema sería 95% confiable. Pero como usó MyISAM, ¡la anotación no sirve de nada! MyISAM no sabe qué es un Rollback. Es el «doble error» de este proyecto. Pero Inno existe desde varios añes antes de 2019 que se hizo el tutorial.

EL 95% de los problemas estarían resueltos si :

• usando campos decimal en lugar de float y en lasvariables y métodos respectivos.
• innodb en lugar de myisam
• uso de Transactional

Otros puntos intersantes:

• No vi usar where en ningun lado. OutOfMemory con muchos datos o muchas aplicaciones en el servidor o si el usuario esta viendo videos en facebook al mismo tiempo
• En mi punto de vista editar el nombre de producto es un gran NONO jamas y deberia comentarse en cualquier carrito de compras . No puedes sobreescribir codigo de barras, clave hacienda, Nombre o descripción del producto. Te lo digo por experiencia . Hay casos extremos como que reusen el Código para otro producto y es un mega desastre. No es algo menor el problema de recliclar claves de producto. Literalmente Cuesta vidas. Siempre es mejor crear una clave de producto nueva.
• Por JPA y el ORM la base de datos es … nominal. No hay numero de versión.  que pasa cuando permites o pones un campo nuevo como tipo de impuesto con el ORM ? y si cambias lo campos de float a decimal ? Deberías checar que versión de base de datos es y si el campo existe.
• request.getSession().setAttribute(«carrito», carrito); // el carrito no expira nunca

A propósito. Estoy de acuerdo en usar el id del producto en el get, pero lo hago por bitácora, no por las mismas razones y borrar lo permito solo a usuarios identificados, y si no hay historial de ventas del producto.

Revisando el navegador del repositorio https://github.com/parzibyte/sistema-ventas-spring-boot

Estas son las notas que tomé..

producto.java

private Float existencia;

// Así se vería  variable para mapear el DECIMAL(14,6)
private BigDecimal precio;

// Al recuperarlo de la base de datos o crearlo:
BigDecimal valor = new BigDecimal(«12345678.123456»);

En lugar de bigdecimal o decimal Hay métodos adicionales de multiplicacion que a veces se usan pero son raro verlos. Aquí afortunadamente no estan. que pueden llevar a overflow entre 32 y 64 bits de compilador.

Precisión inmutable: Nunca perderás un micro-centavo en una suma de 10,000 facturas.

/ProductosController.java

Problema: recibe id del formulario, asi que con un f12 o o postmanpuede borrar cualquier producto del sistema. No hay permiso para verifiar si el usuario puede hacerlo o si hay historial asociado de pedidos, existencia compras oventas.

@valid solo verifica que sea mayor a 0. Pero si hay concurrencia dos usuarios sobreescriben el registro. La existencia se leyó hace cinco minutos que cargaron el formulario.

(Como dije antes en lo personal yo considero que es correcto tener el id en el get pero por bitacora, No por las razones que menciona el.)

producto vendido .java.

Poner aqui una lista de precio seria horrible. y como consultas el histórico ? otro problema.

public Float getTotal() {

el modelo en gettotal no considera que pasa si la existencia es cero. y si el precio es negativo ? no deberia ser pero en ocasiones te lo encuentras por kits, por validaciones (ej precio = -99 significa en varios de mis sistemas ese producto no se puede vender a ese cliente ) se le llama valor centinela. Debería documentarse en el código pero no hay reglas de negocio en el código ni precauciones básicas de concurrencia que yo vi desde Clipper 5 en 1993.

O sea si la existencia es cero, estas documentando que alguien se llevo un medicamento que no tenias ?

vender controller.java

espera una buena conexion., a veces el cliente empieza en una pestaña y termina en otra. Su bucle de terminar venta viola los principios transaccionales, y el principio de atomicidad . Dos cajeros pueden vender elproducto al mismo tiempo. O dos clientes pueden por ejemplo en línea comprar boletos para un concierto.

float total = 0;
for (ProductoParaVender p: carrito) total += p.getTotal();

que puede llevar a errores de redondeo y que no cuadre la contabilidad o la venta del día o que no puedas timbrar una factura. Facturas rechazadas y multas por simplemente usar float.

venta.java

public Float getTotal() {
Float total = 0f;
for (ProductoVendido productoVendido : this.productos) {
total += productoVendido.getTotal();
}
return total;
}
Segun yo debió ser….

import java.math.BigDecimal;
import java.math.RoundingMode;

public BigDecimal getTotal() {
// Inicializamos con CERO absoluto, no con una aproximación binaria
BigDecimal total = BigDecimal.ZERO;

if (this.productos == null) return total;

for (ProductoVendido productoVendido : this.productos) {
// Obtenemos el total del producto (que también debería ser BigDecimal)
BigDecimal subtotal = productoVendido.getTotal();

// Sumamos con precisión exacta
total = total.add(subtotal);
}

// Establecemos la escala de salida (ej. 2 decimales para dinero)
return total.setScale(2, RoundingMode.HALF_UP);
}

y tendriamos que cambiar en productovendido.java // En ProductoVendido.java
public BigDecimal getTotal() {
// cantidad (ej. 1.500) * precio (ej. 10.50)
return this.cantidad.multiply(this.precio)
.setScale(2, RoundingMode.HALF_UP);
}

La base de datos la genera el ORM pero además está en https://github.com/parzibyte/sistema-ventas-spring-boot/blob/master/src/main/resources/esquema_ventas_springboot.sql

es my isam, no soportatransacciones ni acid e ignora muchas vecesllaves foraneas.

Los campos son float cuando deberian ser decimal (14,6);

CREATE TABLE `hibernate_sequence` (
`next_val` bigint(20) DEFAULT NULL
)

Usa un bigint para la secuencia, pero las tablas usan int(11). En el momento que la secuencia pase de 2,147,483,647, Hibernate intentará insertar ese valor en un int(11) y la base de datos colapsará. Es una inconsistencia de tipos clásica de «programador de tutorial».

Tipos de datos: Confirmado el desastre del FLOAT

fecha y hora deberia ser date time o timestamp. Yo me iriía por datetime

14 archivos de templates…. y es mas sano ue react

Analizando el pom.xml https://github.com/parzibyte/sistema-ventas-spring-boot/blob/master/pom.xml

Ni siquiera creo que sea de este proyecto. que hace aquí ?

no hay dependencia de jpa ni de mysql o maria db. spring-boot-starter-data-jpa El conector de MySQL o MariaDB.

No hay rastro de spring-boot-starter-security. Confirmado: Seguridad 0.

No hay librerías de precisión como Jackson-datatype-jsr310

El groupId dice org.springframework. Eso es un error de práctica. El groupId debería ser el dominio del autor (ej. me.parzibyte). Usar el de Spring es como si tú pusieras en la cabecera de tus archivos PHP que el autor es php.net.

que le falta al pom ? bueno…

De entrada es buena práctica especificar el spring security aunque tengas java superior al 17. Y además hay conflictos entre versiones mayores de spring security, por ejemplo la 7. (recuerda que segun yo este proyecto usa gradle, no pom)

Motor de persistencia.

<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-jpa</artifactId>
</dependency>

driver

<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<scope>runtime</scope>
</dependency>

La validacion de bean es una especificacion java

<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-validation</artifactId>
</dependency>

El proceso mencionado aqui tomó cuatro horas aprox.

Costo? Como anoté en las tres primeras partes esto fue un encargo para cliente. Desde el momento enb que entré a terminal en máquina limpia, hasta que cloné en la parte 5 fueron poco menos de tres días y no dedicados a esto..

La eficiencia técnica se traduce directamente en agilidad económica: mientras que el costo operativo de este stack en Vultr es de apenas 20 USD al mes, el proceso completo de implementación, desde el inicio de la configuración hasta la generación y clonación de la imagen final para el cliente, representó un gasto ínfimo de tan solo 2.33 USD. Esta cifra no solo cubre el tiempo de cómputo, sino también la transferencia de datos entre servidores durante el despliegue de la imagen maestra.

Es la prueba de que un servidor de alta densidad, basado en Debian 13 y optimizado quirúrgicamente, permite realizar despliegues masivos y entregas de infraestructura crítica por una fracción del costo de los proveedores tradicionales. No es solo gastar menos, es la capacidad de replicar entornos profesionales de producción en cuestión de minutos y por el precio de un café, manteniendo la soberanía total sobre el sistema y los datos del cliente.

El día de hoy terminaré de instalar este servidor  Apache (LAMP) al tiempo que actualizo en otro ya existente, los tres sobre Debian 13. Hay una relación importante entre la memoria y el consumo de ella, y por qué usar Gitea. Joel Spolsky, antiguo programador de Microsoft, hablaba de las doce preguntas y una de ellas tenía que ver con builds / compilaciones de un solo paso. Creo que una vez establecido el front end (en este caso React) no necesitas hacerle muchos cambios, pero sí es común que establezcas nuevas funcionalidades «bajo el capó», en backend, que no se ven. Y en eso Quarkus brilla. Además, usa mucho menos memoria que Spring Boot.

En lugar de entrar por una subcarpeta, vamos a darle su propia identidad: git.tu-dominio.com.

Empezamos !!!

Verificamos que este instalada la opcion de Proxy.

• • a2enmod proxy

• a2enmod proxy_http
• systemctl restart apache2

Primero, crea el archivo de VirtualHost para el subdominio:

nano /etc/apache2/sites-available/git.tu-dominio.com.conf

Habilitamos el sitio: a2ensite git.tu-dominio.com.conf && systemctl restart apache2

Pero ahora hay que decirle a certbot que cree un certificado.

• certbot --apache -d git.tu-dominio.com
  

  Con un f5 ya se debe de ver con candado de certificado (en mis tres casos si)

Si no entra probablementees porque no tienes debian 13.

Si Certbot te pregunta si quieres «Redirigir» (Redirect), dile que SÍ (opción 2). Esto insertará automáticamente las reglas necesarias para que cualquier intento de entrar por HTTP salte a HTTPS.

2. Verificar el archivo generado

Una vez que Certbot termine, debería haber creado un archivo nuevo en /etc/apache2/sites-available/git.tu-dominio.com-le-ssl.conf.

Si entras y sigue sin cargar, revisa que ese nuevo archivo tenga las líneas del Proxy, porque a veces Certbot solo copia lo básico. El archivo debería verse así:

Apache

<IfModule mod_ssl.c>
<VirtualHost *:443>
    ServerName git.tu-dominio.com

    ProxyPreserveHost On
    ProxyPass / http://127.0.0.1:3000/
    ProxyPassReverse / http://127.0.0.1:3000/

    # Las líneas de los certificados (que pone Certbot)
    SSLCertificateFile /etc/letsencrypt/live/git.tu-dominio.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/git.tu-dominio.com/privkey.pem
    Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>

---

3. ¿Por qué podría seguir fallando? (Checklist de purga)

• DNS: ¿El subdominio git ya apunta a la IP de tu servidor? (Si el ping a git.tu-dominio.com no responde, Certbot fallará).

• A2ensite: Si Certbot creó el archivo pero no lo activó: a2ensite git.tu-dominio.com-le-ssl.conf systemctl restart apache2

• Firewall: Recuerda que ahora entramos por el 443. Asegúrate de que UFW lo permita: ufw allow https

Mantenimiento: La regla de oro antes de la batalla

Antes de meter el motor de Spring Boot en la siguiente entrega, hay que asegurarse de que los cimientos estén firmes. Instalar Gitea, configurar Proxies y mover Certbot genera movimiento en los repositorios. Un buen administrador no deja basura atrás.

Corremos una actualización final para consolidar los parches de seguridad de los módulos de Apache y las librerías de SSL que acabamos de configurar:

• apt update && apt upgrade -y

Y para mantener ese 19% de RAM y el disco limpio, eliminamos cualquier residuo de paquetes que ya no sea necesario tras nuestras configuraciones:

• apt autoremove -y
• apt autoclean

En mi caso solo el servidor que venía de debian 11 hizo cambios quitando paquetes.

Hasta aquí es lo que llego hago normalmente en mis servidores PROPIOS y a veces ni les instalo Gitea.

Despliegue de Spring Boot, parte Uno.

EL mejor ejemplo que se me ocurre aquí es que de repente le puedes pedir a tu hija que vaya a la tienda, o a un compañero que saque una copia o un respaldo. Si eres profesional lo revisas despues porque no puedes hacer desayuno sin ir a la tienda, ni el tramnite sin la copia. (y por cierto que no sirev de nada si dejas el documento en casa o es del documento equivocado)

Parte 3.1 : El Despliegue de Spring Boot (JDK 21)

1. Instalación del Motor (JDK 21)

Primero, instalamos el entorno de ejecución para Java. Usamos la versión 21 por ser la LTS actual y necesaria para Spring Boot 3.

• apt update
• apt install openjdk-21-jdk -y
• # Verificamos la instalación
• java -version

2. Preparación del Directorio de Trabajo

• No debemos correr el backend como root. Usaremos /var/www para mantener la estructura de Apache.

Bash

• mkdir -p /var/www/backups_java
• # Le damos la propiedad al usuario del servidor web
• chown www-data:www-data /var/www/backups_java
• chmod 755 /var/www/backups_java

3. El Script de Lanzamiento (El «Limitador de RAM»)

Para que Spring Boot no se «coma» todo el servidor (manteniendo nuestra filosofía de ahorro), crearemos un pequeño script de arranque que limite la memoria.

nano /var/www/backups_java/start.sh

Teb cuidado que no hayan espacios en blanco al inicio del archivo o en un primer renglon.

#!/bin/bash
# Limitamos a 512MB de RAM máxima para mantener la movilidad
java -Xms256M -Xmx512M -jar /var/www/backups_java/tu-proyecto.jar

No olvides el permiso de ejecución:

• chmod +x /var/www/backups_java/start.sh

4. Creación del Servicio Inmortal (Systemd)

Para que el backend inicie solo con el servidor y se reinicie si falla.

• nano /etc/systemd/system/spring-app.service

y pones dentro

[Unit]
Description=Backend Spring Boot
After=syslog.target network.target mariadb.service

[Service]
User=www-data
WorkingDirectory=/var/www/backups_java
ExecStart=/var/www/backups_java/start.sh
SuccessExitStatus=143
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target

Despues de eso …

• # Recargar systemd para que reconozca el nuevo servicio
• systemctl daemon-reload
• # Habilitar para que inicie con el servidor y arrancarlo ahora
• systemctl enable spring-app
• systemctl start spring-app

5. El Puente en Apache (Proxy para la API)

Finalmente, le decimos a Apache que todo lo que llegue a tu-dominio.com/api lo mande al motor de Spring Boot (puerto 8080).

Edita tu archivo de VirtualHost SSL existente:

• nano /etc/apache2/sites-available/tu-dominio.com-le-ssl.conf

Agrega estas líneas antes del cierre de </VirtualHost>:

# Proxy para el Backend de Spring Boot
ProxyPass /api http://127.0.0.1:8080/api
ProxyPassReverse /api http://127.0.0.1:8080/api

6 Ahora verificamos :

debe darte syntax ok

Vamos a probar : URL Qué debe mostrar Archivo que lo controla

1. tu-dominio.com tu prueba que hiciste o el mismo monitoreo done lo hayas puesto.
2. tu-dominio.com/app/ El React (Front) tu-dominio.com-le-ssl.conf (por eso es el app en virtualhost)
3. git.tu-dominio.com El Gitea (Repos) git.tu-dominio.com-le-ssl.conf
4. tu-dominio.com/api Error 503 (por ahora) El bloque Proxy que añadiremos

7 Ahora nos preparamos para el hola mundo en spring :

Nota: debe de estar corriendo cada diez segundos tratando de lanzar el rpoyecto que mencionamso que todavia no existe. asi que …

7.1. Crear el código fuente de prueba

Vamos a crear un servidor web básico en un solo archivo Java dentro de tu carpeta de trabajo:

nano /var/www/backups_java/TestServer.java

Pega este código (es Java 21 estándar, no requiere librerías externas):

/* Prueba en java 21 */
import com.sun.net.httpserver.HttpServer;
import java.io.OutputStream;
import java.net.InetSocketAddress;

public class TestServer {
    public static void main(String[] args) throws Exception {
        HttpServer server = HttpServer.create(new InetSocketAddress(8080), 0);
        server.createContext("/api", (exchange) -> {
            String response = "<h1>Backend Skeleton: OK</h1><p>Conectado exitosamente via Apache Proxy</p>";
            exchange.sendResponseHeaders(200, response.length());
            OutputStream os = exchange.getResponseBody();
            os.write(response.getBytes());
            os.close();
        });
        System.out.println("Servidor de prueba iniciado en el puerto 8080...");
        server.setExecutor(null);
        server.start();
    }
}

Paso 7.2: Compila y genera el JAR:

cd /var/www/backups_java/
javac TestServer.java
# Creamos el JAR con el punto de entrada en TestServer
jar cfe tu-proyecto.jar TestServer TestServer.class

Paso 7.3 Permisos y Arranque:

• chown www-data:www-data tu-proyecto.jar
• systemctl restart spring-app

Paso 7.4

Desde terminal o bash

• #prueba 1
• journalctl -u spring-app -f # te debe mosttar servidor de prueba iniciado en el puerto 8080
• #Prueba 2
• curl -v http://127.0.0.1:8080/api

y https://tu-dominio.com/api/

si la tres no queda…. edita el archivo le-ssl de tu dominio que esta en /etc/apache2/sites-available/

y que qudee asi … las /api/ son importantes la barra, es una forma de forzar a apache a hacer que hagas lo que quieres y si te fijas cambiamos el orden tambien.

<IfModule mod_ssl.c>
<VirtualHost _default_:443>
ServerName tu-dominio.com
ServerAlias www.tu-dominio.com
ServerAdmin tumail@gmail.com

# Proxy para el Backend de Spring Boot
ProxyPreserveHost On
ProxyPass /api/ http://127.0.0.1:8080/api
ProxyPassReverse /api/ http://127.0.0.1:8080/api

# Apuntamos a la vitrina real
DocumentRoot /var/www/tu-dominio.com/public_html

<Directory /var/www/tu-dominio.com/public_html>
Options -Indexes +FollowSymLinks
AllowOverride All
Require all granted
</Directory>

# El motor de React
<Directory /var/www/tu-dominio.com/public_html/app>
RewriteEngine On
RewriteBase /app/
RewriteRule ^index\.html$ – [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /app/index.html [L]
</Directory>

ErrorLog ${APACHE_LOG_DIR}/tu-dominio-error.log
CustomLog ${APACHE_LOG_DIR}/tu-dominio-access.log combined

Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/tu-dominio.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/tu-dominio.com/privkey.pem
</VirtualHost>
</IfModule>

Y luego otra vez

• # 1. Asegura que los módulos estén activos (por si acaso)
• a2enmod proxy proxy_http
• # 2. Verifica que no haya errores de dedo en el archivo
• apache2ctl configtest
• # 3. Reinicia Apache para que lea la nueva prioridad
• systemctl restart apache2

Ahora si …

• https://tu-dominio.com/api/

La diagonal es importante y debes ver …

Backend Skeleton: OK

Conectado exitosamente via Apache Proxy

¿Por qué funcionará ahora?

Al poner el Proxy antes del DocumentRoot, le dices a Apache: «Antes de que busques archivos en la carpeta public_html, si ves que la dirección empieza con /api, mándala directo a Java».

En Apache, omitir una diagonal es la diferencia entre que el servidor busque un archivo o que entienda que es un puente hacia otro servicio. No es capricho, es sintaxis.

Finalmente :

https://tu-dominio.com/monitoreo.php

Como puedes ver los numeros son excelentes. Lo que pesa es el codigo, y la mezcla de tres modos diferentes de usar Spring Boot. Debes tratar de unificarlo en uno solo. Yo prefiero JDBC pero hibernate / JPA tiene sus ventajas.

Vamos a comparar los dos graficos.

Antes de Spring

Despues de spring

En realidad estas usando menos de 40 MB mas.

8.- Check list

• # ========================================
  # CHECKLIST FINAL – PARTE 2 COMPLETA
  # ========================================
• # Gitea en subdominio con SSL
  curl -I https://git.tu-dominio.com | grep «200 OK»
• # Puerto 3000 cerrado externamente
  nmap -p 3000 $(curl -s ifconfig.me) # Debe dar «filtered» o «closed»
• # Java 21 instalado
  java -version | grep «openjdk version \»21»
• # Skeleton respondiendo
  curl https://tu-dominio.com/api/ | grep «Backend Skeleton»
• #  Memoria bajo control
• free -m | awk ‘NR==2{printf «RAM: %s/%sMB (%.2f%%)\n», $3,$2,$3*100/$2 }’
  free -m | awk ‘NR==2{printf «RAM: %s/%sMB (%.2f%%)\n», $3,$2,$3*100/$2 }’
  # Debe mostrar ~788-820 MB de 4096 MB (~20%)

• (Asegúrate de que las comillas simples son rectas en WordPress. Las centrales son dobles chr(34))#  Servicio

• spring-app activo
  systemctl is-active spring-app # Debe decir «active»

• #  Logs sin errores críticos
  journalctl -u spring-app –since «10 minutes ago» | grep -i «error»

Cual es el problema REAL ?

Que no tienes instalado así en tus servers de producción. Solo una personao varias que hicieron lo que buenamente podían.

Un servidor es tan bueno como su admin

Cual es mi preocupación moderna ?

Tenemos un hola mundo que usa 788 mb de ram y tres o cuatro horas de un devops experto para configurar.

Y cuando llegan los programadores… mezclan los estandares y hay errores de diseño.

Usando metáforas… hay coches automáticos y hay coches estandard. También algunos tienen diferente el cambio de velocidades. Algunos a 50 otros a 60 kms Pero debe haber un estandard de los programadores para no dañar la maquinaria. De nada sirve tener un motor afinado si el conductor no sabe meter las velocidades y que es criminal en un automático pisar a la vez el freno y el acelearador. Con lo que yo hice, no necesitas meter el clutch. Solo no hacer barbaridades.

o con mi sinceridad habitual: Los programadores mezclan los estándares y hay errores de diseño… De nada sirve tener un motor afinado si el conductor no sabe meter las velocidades

El Problema Real del Spring Boot Salvaje:

• Equipos mezclan JDBC, JPA e Hibernate sin estrategia
• Configuraciones copiadas de Stack Overflow sin entender
• Pools de conexiones sin límites → RAM explota
• @Autowired en todos lados → código imposible de testear
  • revisa @bean y https://medium.com/@mesfandiari77/a-deep-dive-into-why-autowired-can-harm-your-spring-application-77481ffb9574

Mañana veremos cómo implementar un carrito de compras en Spring Boot manteniendo esta disciplina de diseño y sin react

Notas Técnicas importantes

En el ejemplo que puse Script start.sh tiene ruta hardcodeada
bash#!/bin/bash
# Problema: «tu-proyecto.jar» es placeholder
java -Xms256M -Xmx512M -jar /var/www/backups_java/tu-proyecto.jar

# Mejor:
java -Xms256M -Xmx512M -jar /var/www/backups_java/TestServer.jar

O mejor aún, usar variable:

bash#!/bin/bash
JAR_FILE=»TestServer.jar»
java -Xms256M -Xmx512M -jar /var/www/backups_java/$JAR_FILE

5. Advertencia sobre com.sun.net.httpserver

El código Java usa com.sun.net.httpserver, que es parte del JDK pero no es API oficial.

Explicación: Este servidor usa com.sun.net.httpserver, que viene con el JDK pero no es recomendado para producción. Es perfecto para esta prueba de concepto, pero en producción usarías Spring Boot con @RestController.

Porque ?

Hay tres opciones Basicas ademas de esto.

1. Mi opción por lo general es usar gradle si tengo que usar springboot
2. crear un proyecto de maven minimo, de memoria mkdir -p /var/www/backups_java/spring-simple/src/main/java/com/demo
   cd /var/www/backups_java/spring-simple y luego el pom.xml y las clase principal
   y compilar
3. la tercera opcion es la recomendada: Spring Boot con Spring Initializr

• Paso 1: Crear el proyecto base
• bashcd /var/www/backups_java/
• # Descargar un proyecto base de Spring Boot desde start.spring.io
• curl https://start.spring.io/starter.zip \
• -d dependencies=web \
• -d type=maven-project \
• -d language=java \
• -d bootVersion=3.2.1 \
• -d baseDir=demo \
• -d groupId=com.tudominio \
• -d artifactId=backend-api \
• -d name=BackendAPI \
• -d packageName=com.tudominio.api \
• -d javaVersion=21 \
• -o backend-api.zipunzip backend-api.zip

cd demo

y crear un controlador simple y archivos de application compilando eejcutando y actualizando el script de inicio.

Porque lo hice asi ?

Uy.

Aunque suene a texto de programador sufrido, no quiero que digas palabrotas al ver lo necesario para inicializar una version correcta de spring si solo has visto el frontend y no has instalado. No se a cual de las tribus de spring perteneces  tu lector JDBC , JPA / HPA ni que entiendes por Spring Security y que usas. Mis primeras dos semanas revisando un proyecto de java es ver que dicen los desarrolladores que es el spring security y el stack que estan usando. Es como cuando preguntas que versión de sistema operativo usas y te dicen linux o windows, no te sirve de nada.

Las Tres Tribus de Spring Boot

Cuando pregunto «¿qué stack de Spring usas?», las respuestas varían:

1. Tribu JDBC: Spring Boot + JDBC Template (el más ligero, ~120 MB)
2. Tribu JPA/Hibernate: Spring Data JPA (el estándar, ~180 MB)
3. Tribu Mixta: JDBC para lectura + JPA para escritura (el caos, ~200 MB)

( y te pueden responder groseramente dimelo tu, ya deberías saberlo, sabes o no sabes … o candidamente el de linux o el de siempre)

El problema: Cada tribu tiene su propia configuración de pools de conexión,
transacciones y cache. Mezclarlas sin estrategia es como tener 3 volantes en un auto.

A veces, para diagnosticar un puente, no necesitas un tráiler de 18 ejes (Spring Boot); necesitas una bicicleta para cruzar y ver si el pavimento aguanta. El Skeleton en Java puro es esa bicicleta.

Como lei en un libro : Si no sabes qué versión de Spring Security usas, no tienes seguridad, tienes una puerta cerrada de la que perdiste la llave.

• Los cambios de versión a 7 fueron brutales. Lo que encuentras actualemente es una mescolanza desfasada, y piensan que eso los vaa proteger de los problemas mas comunes de seguridad… Y por lo general no ysan jackson, y por lo mismo no entienden lasdiferencias de jackson2 a jackson3 y sus implicaciones en seguridad.
• Mi respuesta es super simple. «Te entiendo perfectamente. Te sugiero que pongas un token JWT y queda un poco mas claro»
  • Explicación: JWT hace lo mismo, mas rápido, sin cambios de versiónes, estandard internacional y una vez que tienes eso puedes empezar a entender a que llaman en ese lugar y proyecto «spring security»
  • Tienes que preveer contingencias legales. Equipo rojo. Doble ciego. Si usas datosconfidenciales mas. Para eso es jackson 2 y jackson 3 necesario.

Comentario experto :

El problema del @Autowired es que se ha convertido en la «droga» de los desarrolladores modernos: inyectan cosas sin saber qué están inyectando, quién las creó ni cuánta memoria están consumiendo. Es programación por «acto de fe». Un programador que solo sabe usar@Autowiredno es un arquitecto, es un ensamblador de piezas que no comprende. Los cambios de manejo de fechas cambian en jackson 2 a 3 y la visibilidad de campos personales afecta tu compliance con la ley, pero eso si obtienes vectores de ataque llamado /metrics /env /heapdump muy bonitos. (informas la memoria RAM a cualquiera que sepa la URL por defecto.)  Actuators =/ Compliance incluso Actuators <> Compliance incluso sin 853 paquetes de dependencias no auditables.

Cuando mencionas Jackson, tocas el nervio expuesto. La mayoría no entiende que Spring Boot no es magia, sino una serie de librerías trabajando juntas. No saben que si Jackson está mal configurado, su API es vulnerable a ataques de deserialización o que están enviando más información de la cuenta en el JSON porque no saben usar un @JsonView o un DTO.

Un resumen de porque no usar Springboot, para mi, en proyectos con datos sensibles y mucho menos cuando el software es  el activo principal de la empresa.

• Si vas a usar el tráiler de 18 ejes (Spring Boot), tienes que saber manejar Jackson y cerrar Actuators; si no sabes, mejor quédate en el LAMP (camioneta), donde el control es manual, directo y no hay ‘magia’ que te abra puertos por la espalda.
• Un activo que nadie entiende (3,000 archivos de Spring/React con dependencias desconocidas) tiene menos valor real que un sistema auditable, compacto y documentado. Es un pasivo en realidad, no un activo. Huye de quien te diga lo contrario.
• No puedes confiar el corazón del negocio a una serie de librerías (como Jackson) que no sabes configurar. Si no sabes configurarla o no sabes que existe, no dominas la herramienta, no eres dueño de tu activo; eres un rehén de la complejidad que trae mas problemas que beneficios.
• En estos casos la sobrevivencia depende de la suerte, de tu proveedor, y que no haya un equipo rojo ni daños en tus respaldos. No de los programadores.
• ¿quien eligió el stack? Pregunta Sobre jackson. Si no te sabe responder cambia de persona y de Stack YA.

Lo que hice yo al usar com.sun no es soportado oficialmente 100% pero está en el 95% de los servidores, tiene threading limitado, el json es manual, no tiene spring security (que a veces es una ventaja porque cambia de una versión a otra) la gestion de errores es manual y con system.out no tienes health checks pero usas 30 mb en lugar de 120 mb

Y muchas veces lo que me funciona, pero sabiendo lo que estoy haciendo es quitar spring security y usar com.sun.net.httpserver. En lo que arreglo el lio. La mayor parte de los sistemas reales de empresas medianas en méexico tienen en media noche usuarios cero así que puedes hacer revisiones en la madrugada con un .com.sun temporal

Actualizado 16 ene 2026. Razón : Nuevas instancias creadas en ovhcloud obligan a dar rodeos en pm2. 

ACTUALIZACIÓN CRÍTICA – 16 enero 2026

Nuevas instancias de OVHcloud (enero 2026) tienen problemas graves de inconsistencia. Un servidor levantado la semana pasada funciona con PM2, uno levantado hoy NO. Este manual funciona al 100% en Vultr. En OVHcloud solo es confiable para LAMP básico o para respaldo de archivos por el espacio de disco duro barato.

El Problema Real con OVHcloud

Las políticas de OVHcloud te obligan a usar un usuario intermedio llamado ‘debian’, no root directo. Esto significa:

• Tienes que usar nvm con permisos limitados
• Los módulos pueden bloquearse por el shell intermedio
• Pagas por un servidor pero no eres realmente root

Pero el problema crítico es otro: OVH maneja cambios en sus capas de abstracción de seguridad sin avisar y sin consistencia. Vultr te da una instancia desnuda. OVHcloud te da una caja negra que cambia cada semana.

Problemas verificados de OVHcloud:

1. Capas de seguridad inconsistentes entre servidores
2. Reputación de spammers (tus correos caerán en spam)
3. Panel de control confuso
4. Soporte técnico deficiente
5. Bloqueos arbitrarios de herramientas (PM2, permisos de NPM)

La pregunta que debes hacerte:

Si tu plataforma no es reproducible entre servidores del MISMO proveedor, ¿qué estás haciendo ahí?

OVHcloud te fuerza a usar systemd en lugar de PM2. Aunque técnicamente funciona, pierdes las ventajas críticas de PM2:

• Monitoreo en tiempo real con pm2 monit
• Reinicio automático inteligente
• Logs centralizados y fáciles de consultar
• Gestión de múltiples procesos Node con un comando

No usar PM2 es darte un tiro en el pie. Como dice el refrán en México: «es ir a la guerra sin fusil».

Tus opciones:

1. Cambiar de proveedor (recomendado) – Te tomará 6+ horas por el vendor lock-in que crean las abstracciones
2. Contratar a alguien que conozca las limitaciones específicas de OVH (caro e innecesario)
3. Usar OVHcloud SOLO para LAMP básico (WordPress, Laravel sin Node)
4. Regresar tu servidor actual a LAMP limpio (ver Anexo 3)

Este problema no eres tú. No es falta de conocimiento. Es la plataforma. Lo mismo pasa con Azure y es peor con RHEL.

Recomendación profesional:

• Usa OVHcloud para: WordPress, Laravel, aplicaciones PHP puras. Respaldos no criticos.
• NO uses OVHcloud para: Node.js, React con SSR, PM2, Spring Boot con gestión de procesos compleja

Si tienes dudas, sigue los pasos del Anexo 3 para borrar React, NPM, Vite y PM2, y úsalo como servidor LAMP tradicional. Es mejor un servidor simple que funciona que una «plataforma moderna» que falla aleatoriamente.

Las órdenes para regresar a servidor LAMP limpio y quitar todo lo relacionado con Node están en el Anexo 3.

En esta ocasión voy a levantar tres servidores LAMP con react y GITEA configurado, como base para springboot.

Siendo sinceros voy acorrer el proceso en dos servidores recién levantados y revisar que pasa con un tercero; los tres son de mi cliente, y van a ser uno ya existente en ovhcloud, uno nuevo en ovhcloud, y un tercero en vultr, con 8gb ,6gb y 4 gb respectivamente.

Quiero dejar claro que las politicas de ovhcloud son usar un usuario intermedio llamado debian, con lo cual debes correr ordenes nvm. Si funciona pero hay que moverle. En realidad estas pagando por algo que no es root. Si mas espacio. Pero si los modulos no se carga porque un shell los bloquea no es culpa de este manual. Si las imagenes nuevas te dan capas de seguridad inconsistente hay un problema serio. Tu plataforma no es reproducible.. entre el mismo proveedor.

En casos como Ovhcloud la abstracción te lleva a mejor usar como servicios de Systemd independientes en lugar de confiar en gestores de procesos de nivel de usuario como PM2. Systemd es agnóstico a las capas de shell de OVH y garantiza que el binario arranque con los privilegios correctos del sistema. Pero a veces tienes razones para no usar systemd. OVH te obliga. O te obligaa usar una versión de npm y nvm. O no te deja dar un apt update.

Las razones de tres instalaciones a la vez?

• a ) No van a usar el de 4gb en producción Probablemente uno de sus docker kubernetes es para pruebas. Lo pueden subir en memoria si quieren después
• b ) Spring/springboot ocupa relativamente mucha memoria, pero para lo que realmente lo usan la carga del peso debería ser mantener springboot funcionando y no tienen tantos clientes.
• c ) Mi lógica es que probablemente tampoco tienen optimizada la base de datos, y estoy casi seguro que el problema del servidor de 8 es que no le corren actualizaciones desde hace mucho. (Editado… si, el de 8gb todavía tiene debian 11)
• d ) Para su volumen de clientes no necesitan NGINX, y como tienen wordpress apache es mejor. Por cierto que ya puse por aqui un manual de LEMP o sea lo mismo pero con NGINX pero sin springboot y usando quarkus en su lugar.
• e ) OVHCloud no lo recomiendo por permitir spammers. Pero el cliente está a gusto con el, y ya tiene algunos servidores de apoyo y de python allí.

Base deseada:

• Parte 1
  • Servidor en debian 13 por ser una de las distros grandes y ya estan familiarizados con gestor de paquetes apt, además que es mi recomendación habitual.
  • Php 8.4 con librerias importantes
  • mariadb con seis bases de datos y usuario particular
  • Certbot SSL con auttorenovación de dry run
  • Node y react
  • Gitea sin cerrar
• Parte 2
  • Gitea Cerrado
    • Certbot SSL con autorenovación de dry run en subdominio .git
  • hacer un archivo simple en php que me muestre uso de servidor en ram y disco duro
  • Instalar spring boot
  • Verificar que springboot este funcionando
  • DESPUES verificar en el simple de php que me muestre uso de servidor en ram y disco duro
  • Probablemente un «hola mundo» en hibernate
• Parte 3 si me da tiempo
  • Cargar Quarkus Dev
  • Configurar un sistema en Gradle / Hibernate / Thymeleaf como prueba de concepto en una parte 4 sin maven y sin react

Preparativos.

• Para cada servidor:
  • Por sencillez Usaremos la clave de root que da el panel de control y la escribiremos
  • Configurar git.tu-dominio.com
  • Preparar una contraseña para root mariadb
  • Preparar una contraseña para usuario admin de sql, siempre sugiero usar usuario adminsql
  • Preparar una contraseña para usuario gitea2 que va a ser el admin

Empezaré usando como plantilla lo que hago en vultr, asi que usare vultre 80gb disco, 4 gb ram para el ejemplo.

Muy Importante:

cuando los proveedores intentan «simplificar» la seguridad creando capas de permisos extrañas, terminan rompiendo el flujo estándar de herramientas como React o Node.

Lo que mencionas del «usuario con mucho sudo sin ser root» es la receta perfecta para el desastre en despliegues. Muchas imágenes modernas intentan forzar políticas de seguridad que chocan con la forma en que los manejadores de paquetes (como npm) gestionan permisos en carpetas globales. Si el entorno no es limpio y el usuario no tiene la jerarquía clara, terminas peleando con el sistema operativo en lugar de programar.

Si no tienes root y tu terminal no tiene permisos no eres root. Punto. (eso pasa en 1and1 casi siempre y en ovhcloud 50% de las veces).

 

Nota: es posible que algun guion haya cambiado de forma, en curl. son guiones normales. Lo mismo con las comillas.

Costo? Como anoté en las tres primeras partes esto fue un encargo para cliente. Desde el momento enb que entré a terminal en máquina limpia, hasta que cloné en la parte 5 fueron poco menos de tres días y no dedicados a esto..

La eficiencia técnica se traduce directamente en agilidad económica: mientras que el costo operativo de este stack en Vultr es de apenas 20 USD al mes, el proceso completo de implementación, desde el inicio de la configuración hasta la generación y clonación de la imagen final para el cliente, representó un gasto ínfimo de tan solo 2.33 USD. Esta cifra no solo cubre el tiempo de cómputo, sino también la transferencia de datos entre servidores durante el despliegue de la imagen maestra.

Es la prueba de que un servidor de alta densidad, basado en Debian 13 y optimizado quirúrgicamente, permite realizar despliegues masivos y entregas de infraestructura crítica por una fracción del costo de los proveedores tradicionales. No es solo gastar menos, es la capacidad de replicar entornos profesionales de producción en cuestión de minutos y por el precio de un café, manteniendo la soberanía total sobre el sistema y los datos del cliente.

  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: Apache + 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.

Notas:

• Algunas partes de este manual por wordpress se cambian comillas debiendo ser ‘ comilla simple, noes error mio sin ode wordpress.
• Algunos hosts como ovhcloude te obligan a usarun alias no root, asi que todas las ordenes que siguen debes poner un «sudo» antes. Por simplicidad no la pongo en cada caso, y ya comente que recomiendo no usar ovhcloud (barato pero confuso su panel de control y poco soporte)

Voy haciendo en paralelo con el debian que ya subí de 11 a 13 en ovhcloud (previo respaldo claro). El enfasis lo pondré en vultr porque es lo que recomiendo y me interesa mas ver para entorno de pruebas del cliente ver como se comporta con poca memoria spring .Como tengo tres monitores, dejare para despues el de ovhcloud desde cero usando esta guia y si tengo que actualizar algo lo hago, pero la idea es vultr nuevo y debian 11/13 y wordpress abierto en cada monitor.

Por el stress, voy a poner un cambio eso si en el mysql para reducir memoria.  (  ajustar el innodb_buffer_pool_size a unos 512MB o 1GB máximo para dejarle aire a la JVM de Spring. )

• apt update && apt upgrade -y # Paso 1 instalar y actualizar
• apt install apache2 php8.4 php8.4-mysql mariadb-server -y # Paso 2 Instalamos stack LAMP
• apt install php8.4-curl php8.4-gd php8.4-mbstring php8.4-xml php8.4-zip -y # extensiones comunes  php
• apt install php8.4-bcmath php8.4-gd php8.4-xml -y # extensiones comunes  php parte 2
• # Habilitar módulos Apache
• a2enmod rewrite
• a2enmod ssl
• systemctl restart apache2
• # Reiniciar PHP-FPM
• systemctl restart php8.4-fpm # probablemente  te marque error ovhcloud revisa php -v
• systemctl enable php8.4-fpm
• apt install ufw -y # actualizamos firewall basico y lo hacemos dos veces por si las dudas …
• ufw default deny incoming
• ufw default allow outgoing
• ufw allow ssh
• ufw allow http
• ufw allow https
• ufw allow 22/tcp # SSH por si las dudas
• ufw allow 80/tcp # HTTP  por si las dudas
• ufw allow 443/tcp # HTTPS por si las dudas
• ufw enable
• apt install certbot python3-certbot-apache -y # instalamos certbot
• mysql_secure_installation # volvemos seguro maria db pero

Nota: Si el punto anterior nos da error, es porque es porque es modo puro debian y no es ubuntu. a manita. Anexo 1 que está hasta abajo.

Seguimos.

Tenemos que crear un directorio para la aplicación en este caso wordpress.

• mkdir -p /var/www/tu-dominio.com
• chown -R www-data:www-data /var/www/tu-dominio.com
• chmod -R 755 /var/www/tu-dominio.com

Tenemos que configurar el dominio en apache:

• nano /etc/apache2/sites-available/tu-dominio.com.conf

Usando tu propia direccion de correo…

<VirtualHost *:80>

    ServerName tu-dominio.com

    ServerAlias www.tu-dominio.com

    ServerAdmin admin@tu-dominio.com

   

    DocumentRoot /var/www/tu-dominio.com

   

    <Directory /var/www/tu-dominio.com>

        Options -Indexes +FollowSymLinks

        AllowOverride All

        Require all granted

    </Directory>

   # Bloque específico para la App de React
# Esto asegura que Apache busque primero los archivos físicos
<Directory /var/www/tu-dominio.com/public_html/app>
RewriteEngine On
RewriteBase /app/
RewriteRule ^index\.html$ – [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /app/index.html [L]
</Directory>

    ErrorLog ${APACHE_LOG_DIR}/tu-dominio-error.log

    CustomLog ${APACHE_LOG_DIR}/tu-dominio-access.log combined

</VirtualHost>

Una vez esto, recargar apache

• systemctl reload apache2

Te recomiendo por tu propio bien que pongas algo en index.html de tu directorio public_html y algo en el de app que luego pondremos react. la razón es verificar AHORA y no en dos horas, que estas viendo lo que debe ser y no es un error de configuracion de virtual host. Algo tan simple como <h1>Hola!</h1> Sirve.

Y preparamos los procesos de certificado y revisar que se autorenueve. Te sugiero correr uno por uno y no en lote bash

• a2ensite tu-dominio.com.conf
• systemctl reload apache2
• apache2ctl configtest
• # la siguiente linea puede ser necesario que quites el paramatro apache
• certbot –apache -d tu-dominio.com -d www.tu-dominio.com
• # Verificar timer activo
• systemctl status certbot.timer
• # Ver próxima ejecución
• sudo systemctl list-timers | grep certbot # hay muchas maneras esta esoslo una
• # Probar renovación
• certbot renew –dry-run

El error mas común es que haya un error en el contenido de virtualhost como .com.com o algo similar, como las comillas.

Ahora entra a tu sitio y NO debes ver la pagina de Debian sino la tuya propia de public_html.

Lo que sigue es configurar las seis bases de datos de ejemplo, y mi ejemplo particular modificado, por lo que pongo una base de datos llamada carrito. Ese ss un ejemplo modificado sobre algo que anda cicrulando en internet y lo veremos en otro tema.

NOTA que estamos creando un usuario de maria/mysql nuevo para no usar root.

Entra a Mariadb con mariadb <enter>

— Crear las 6 bases originales + la del ejemplo «carrito»
CREATE DATABASE db_principal;
CREATE DATABASE db_gitea;
CREATE DATABASE db_spring_test;
CREATE DATABASE db_extra1;
CREATE DATABASE db_extra2;
CREATE DATABASE db_extra3;
CREATE DATABASE carrito;

— Crear el usuario particular que mencionamos en los preparativos
CREATE USER ‘adminsql’@’localhost’ IDENTIFIED BY ‘TuClaveSeguraAqui’;

— Darle permisos sobre todas las bases (o solo las necesarias)
— Para administración cómoda, le damos sobre todo el servidor local:
GRANT ALL PRIVILEGES ON *.* TO ‘adminsql’@’localhost’ WITH GRANT OPTION;

FLUSH PRIVILEGES;

SHOW DATABASES;

EXIT;

puedes verificar desde fuera que este creado como :

mysql -u adminsql -p -e "SHOW DATABASES;"

Para aplicar el cambio de los 512MB/1GB que mencionamos, recuerda editar:

nano /etc/mysql/mariadb.conf.d/50-server.cnf (o el archivo equivalente en tu instalación):

[mysqld]
innodb_buffer_pool_size = 512M
# También podrías bajar el máximo de conexiones a 100 si el servidor de 4GB sufre
max_connections = 200 

Ya que hicimos el cambio

• systemctl restart mariadb
• Entra a maria
• SHOW VARIABLES LIKE ‘innodb_buffer_pool_size’;
• exit;

Lamento decirte que a veces hay mas archivos de configuracion que los esperados. Asi que tu cambio probablemente te diga el valor…134217728 que significa que no cambio nada. Revisa el anexo 2 si tienes problemas. El número debería ser 536,870,912 (si pusiste 512M). Por el momento puedes seguir así pero no es error mio.

Instalar Node react y gitea

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 Apache 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

• npm install pm2 -g # instalar pm2

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.

Consejo experto:

Si quieres ver qué está pasando realmente ‘bajo el capó’ de tu servidor sin complicaciones, ejecuta el comando pm2 monit. Se abrirá un panel de control en tiempo real directamente en tu terminal que te permite supervisar el consumo exacto de RAM y CPU de cada proceso. Para un entorno como el nuestro, donde tenemos un servidor de 4GB compitiendo con MariaDB, Gitea y pronto Spring Boot, esta herramienta es vital: te permite detectar fugas de memoria o procesos ‘rebeldes’ al instante, dándote la información necesaria para ajustar tus límites de la JVM o del pool de conexiones antes de que el sistema sufra.

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 # puede dar error por laruta

# 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 # sin sudo, este es comando interno

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

Antes de pasar a REACT tengo que contar la misma historia que ya puse en el stack LEMP. COnsidero que REACT es un mal necesario, y por eso te pagan. Pero no es normal que necesites 4 gb para un hola mundo. Si quieres brincarte la historia esta indexada a la derecha, pero mucha gente usa react, desde 2014, porque todo el mundo lo hace. Y si le sumas springboot consumes mucho mas memoria de la necesaria y que lo que pueden pagar empresas medianas.

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 Apache. Siguiendo el enfoque de orden:

• 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 create 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 # quiza te dice que no existe en el registro….

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 apache no tenga problemas de lectura
chown -R www-data:www-data /var/www/tu-dominio.com/public_html/app/

Opcional…. Ademas, como quieres usar apache y wordpress se necesita decirle a apache que, cuando alguien entre a /app, busque en esa carpeta y no intente cargar WordPress.

Puedes editar el virtual host pero de momento lo dejamos asi, el rendimiento no es tn importante

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

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
Apache 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 (Apache 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 (apache). 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 o la de gitea que mencioné.

Si no te acuerdas como le pusiste al base:

• mysql -u root -p
• Show databases;
• # lo masseguro es que sea db_reserva_1 o la de gotea que mencione

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 (Apache), 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 Apache como ‘puente’ (Proxy Inverso) para que cuando escribas tu-dominio.com/git, Apache 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

Si el archivo no existeo no tiene informacion

• cp /var/lib/gitea/custom/conf/app.ini /etc/gitea/app.ini # copia el default y repite linea anterior
  • Ojo.. si tienes quehacer esto, despuesde hacer las ediciones copia en sentido inverso despues de hacer la edicion
• cp /etc/gitea/app.ini /var/lib/gitea/custom/conf/app.ini # copia el default y repite linea anterior

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

• CUIDADO Si tuviste que copiar de un directorio a otro, ahora haz la segunda parte.
• cp /etc/gitea/app.ini /var/lib/gitea/custom/conf/app.ini # copia tu edicion al config normal

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

#  Apache 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 (Apache). 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
• Apache sirve archivos estáticos 100x más rápido que Node

Anexo 1 . Modo seguro mariadb / mysql bajo debian 13

Paso 0:  Entra a mariadb a su prompt (no olvides cambiar lascomillas que deben ser simples, wordpress a veces las cambia por otras.)

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’);

o lo mas recomendado

SET PASSWORD FOR 'root'@'localhost' = 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;

Anexo 2 . Editar el verdadero conf de  mariadb bajo debian 13

Lo que está pasando es que MariaDB no está leyendo tu cambio en el archivo 50-server.cnf o hay otro archivo que lo está sobreescribiendo. En Debian, esto es muy común porque MariaDB carga los archivos en orden alfabético/numérico.

Cómo solucionarlo:
Verifica la ubicación: Asegúrate de que editaste el archivo correcto. En Debian 13 suele ser: /etc/mysql/mariadb.conf.d/50-server.cnf

Busca duplicados: A veces hay un archivo llamado 60-galera.cnf o similares que pueden tener sus propias configuraciones.

La «fuerza bruta» elegante: Para asegurar que tome tus 512MB (o el valor que prefieras), te sugiero crear un archivo nuevo que se cargue al final de todo. Esto sobreescribe cualquier configuración previa:

Bash

nano /etc/mysql/mariadb.conf.d/99-ajustes-memoria.cnf
Pega esto dentro:

[mysqld]
innodb_buffer_pool_size = 512M
Reinicia y verifica:

systemctl restart mariadb
mysql -u root -p -e «SHOW VARIABLES LIKE ‘innodb_buffer_pool_size’;»
Ahora el número debería ser 536,870,912 (si pusiste 512M).

Anexo 3 Comandos de limpieza total usando el marcador tu-dominio.com para regresar a LAMP

Este bloque está diseñado para que cualquiera pueda copiarlo, reemplazar el dominio y limpiar el desorden de permisos que dejan Vite, NPM y PM2 en estas instancias.

Guía de Limpieza: «Reset» del Servidor a LAMP Puro
Ejecuta estos comandos si el shell de tu instancia (como en OVHcloud) está bloqueando la carga de módulos o si PM2 ha generado un conflicto de permisos entre el usuario intermedio y el servidor web.

1. Detener y purgar procesos de PM2
PM2 es el primero en fallar cuando las capas de abstracción de seguridad de la instancia cambian los dueños de los procesos en segundo plano.

Bash

# Matar cualquier proceso activo y el demonio de PM2
sudo pm2 kill || true

# Desinstalar el paquete global
sudo npm uninstall -g pm2

# Eliminar carpetas de configuración (limpia rastros de root y de usuario)
sudo rm -rf ~/.pm2 /root/.pm2 /home/debian/.pm2
2. Eliminar el entorno de Node y React (NVM/NPM)
Si Vite o NPM te dan errores de «Not Found» o «Permission Denied» por las restricciones del usuario intermedio:

Bash

# Borrar la carpeta del proyecto de React/Vite
sudo rm -rf /home/git/proyectos

# Eliminar NVM y todas las versiones de Node instaladas
rm -rf ~/.nvm ~/.npm ~/.bower

# Limpiar las variables de entorno del shell (.bashrc)
sed -i ‘/nvm/d’ ~/.bashrc
sed -i ‘/NVM_DIR/d’ ~/.bashrc
source ~/.bashrc
3. Limpiar el Directorio de Producción en Apache
Elimina la subcarpeta de la app para que no queden archivos con permisos cruzados que provoquen errores 403 o 404.

Bash

# Borrar la carpeta física de la aplicación
sudo rm -rf /var/www/tu-dominio.com/public_html/app

# Reestablecer permisos: Asegurar que Apache sea el único dueño de lo que queda
sudo chown -R www-data:www-data /var/www/tu-dominio.com
sudo chmod -R 755 /var/www/tu-dominio.com
4. Resetear la configuración de Apache
Si modificaste el VirtualHost para intentar que React funcionara, es mejor dejarlo limpio para PHP/Composer:

Bash

# Editar el archivo de configuración
sudo nano /etc/apache2/sites-available/tu-dominio.com.conf

# (Dentro del editor, asegúrate de que el DocumentRoot sea el correcto
# y elimina los Alias o RewriteRules que pusiste para React)

# Reiniciar Apache para aplicar la limpieza
sudo systemctl restart apache2

He comentado que recientemente me buscaron de una startup con problemas. No para ofrecerme un puesto, sino para dar una plática. Que tienen ciertos problemas, sí. Y ciertos es poco. Solo con saber la estructura es suficiente.

Me llamaron por recomendación de dos personas con las que he trabajado: uno de los administradores de dinero y uno de los desarrolladores. Tienen unas siete personas en desarrollo que yo haya visto. Tienen stacks PHP, Hibernate, parte JDBC (creo) y unas cosas en Python. Y para ellos una instancia MÍNIMA es de 8 GB.

Además, tuvieron un problema fenomenal que les resolví hace como dos meses y medio, que era un Snap o atajo de Ubuntu. Yo les comenté entonces que era mejor migrar a Debian 13 o AlmaLinux. Pero por detalles técnicos, lo mejor es una de las distribuciones básicas de Linux, y por eso estamos hablando aquí de Debian. Ya no tengo ninguna otra distro en los propios, pero un cliente tiene un AlmaLinux.

Tiene sentido. Por lo que me dijeron estudiantes del IPN y de la UNAM el año pasado, en servicio social, les dan 8 GB de su tiempo gratis u horarios gratis. Y los servidores Linux de gobierno que manejé el año pasado eran de 8 GB de RAM infame bajo Azure, Rocky Linux y Red Hat sin root.

Solo que los costos de respaldo de Amazon son un problema real. ¿Solución? No respaldan. Por lo que sé, decidieron pedirme dar la plática después de la última caída de la zona principal de Amazon, us-east-1.

Mi primera computadora en 1991 tenía 1 MB de RAM. Al terminar el año creo que tenía seis computadoras. Algunas de 512 y 640 KB, no estoy seguro. Pero aprendí a respetar la RAM y los procesadores.

Revisando costos en este momento, sabiendo lo que haces y sabiendo levantar tu servidor en VPS unmanaged, estos son los costos a 5 de enero de 2026.

Nota: Estoy seguro de que hace dos o tres semanas busqué suempresa.com, que era un proveedor mexicano, y primero pensé que ya había desaparecido. Un punto a favor de por qué no usar proveedores mexicanos. Resulta que no; hicieron un rediseño tan malo que pensé que era una parking page o «se vende este dominio». No lo recomiendo, pero pongo ejemplos aquí.

Voy a calcular costos de 8 y 4 GB de RAM con alrededor de 60 a 80 GB de disco duro con proveedores en México:

• Suempresa.com: 600 pesos mensuales pagando tres años por anticipado, más IVA por 4 GB de RAM y 80 de disco duro. Por 800 más IVA mensuales, y solo AlmaLinux. Lo descarto porque es mejor pagar mes por mes por si cambia la calidad y porque requiero Debian 13.

• Neubox.com: 1090 al mes más IVA = 1264 en lo que llaman opción C, sin haber opción B, con 6 GB y 192 de disco duro, con Debian 12 como opción, pero tres nuevas opciones de servidores que son marketing. Veo varios problemas, principalmente porque el espacio se excede de lo razonable. Si estuvieran usando RAID 5 o RAID 0, tendrían que ofrecer menos disco duro. Suena razonable, pero no, gracias; y no voy a tratar de entender las otras dos opciones de servidores.

• Hostinger.com.mx: Dice tener VPS manejados por IA, por costo que bajó de 315 MXN a 136 MXN mensuales a 8 GB RAM con 100 GB de espacio en disco NVMe. Demasiado barato. Deben sobrevender y tener servidores saturados.

Explico: no puedes poner la supervivencia de tu empleador, de tu trabajo o tu reputación profesional en proveedores que no cuentan con reseñas internacionales. Por «reseñas internacionales» y un sitio de referencia que uso, solo usaría Hostinger, pero los precios son… simplemente… raros. Sobrevenden. Supongo que por esto muchos se van a Amazon, Azure o Google Cloud.

Ahora viene el momento de espantarnos. En términos de «servidores de alguien más» o nube, estos son los equivalentes:

• Google Cloud: Instancia n2, lo mínimo es 375 GB de disco duro, 8 GB de RAM, 101.90 USD mensuales y buena suerte con hablar con un humano. Hay descuentos por uso frecuente o continuado, pero esto te lo dan varios proveedores de USA con soporte técnico. La falta de soporte de Google Cloud es para mí un «no, no». Conozco tres proveedores por lo menos en USA, reconocidos internacionalmente, que te dan un poco menos de disco duro, pero te manejan el servidor. Esto simplemente es excesivo y en la instancia menor n1 o e2, que es un poco mayor, puedes ahorrarte 20 USD o subir a 336 USD mensuales solo en costos iniciales. Descartado por «no humanos».

• Azure: Pues… siendo sinceros, vi un papel en la oficina de uno de los socios que me hace pensar que contrataron el paquete preconfigurado Cloud-native apps on Kubernetes. Mis cálculos eran de 900 USD al mes, pero ya viendo son 1077. 100 GB de egress, lo que significa que no puedes atender clientes y sacar respaldos. Configurando a mano la instancia simple es más simple o peor. Todo gratis el primer año si no te pasas de ciertos límites. Pero al tratar de ver que tienen sus Data Factory o el uso de SQL Server, a simple vista es muy poco para una solución de trabajo real como varias bases de datos que manejo en Debian de más de 18 GB de SQL en MariaDB : son simplemente inmanejables en costo. La mejor metáfora que se me ocurre es cuando vas a preguntar cuánto cuesta una casa o un coche y te dan como 80 respuestas de los accesorios, pero no cuánto cuesta la casa en efectivo más el pago del notario. Tengo la fuerte sospecha de que muchas personas que parecen ser «administradores» tienen uno de esos paquetes de Kubernetes, no tienen ni idea y rezan mucho. (Update: al pasarle a leer esto a mi conocido desarrollador, me dice que son tres paquetes Kubernetes. 60 mil pesos mensuales que él sepa. ¡Ay, Dios!).

• Amazon (AWS): Para empezar, Amazon no te deja usar el estimador de precios hasta que creas una cuenta, y para continuar te cobran hasta por estornudar. Literalmente te cobran todo lo que no estaba contemplado allí, así que una vez que tienes tu presupuesto lo mejor es multiplicar por 1.3, y eso en el mejor de los casos. Uso a veces esta calculadora en línea: https://learnaws.io/aws-calculator/ec2. Pero en terminología AWS necesitas por lo menos instancia EC2 y un S3 porque no vas a usar Lightsail. Solo puedo decir que un estimado mínimo y conservador son 59 USD por la EC2 y una S3 de 4 USD; pero una vez que ves un Memcached de 120 USD, yo diría que por estimado conservador para 8 GB de RAM son 200 USD mensuales. Menos que Azure, pero con más puntos de error y menos tolerancia al descuido. Creo que varios casos han sido problemas donde el administrador no es precavido y los dueños lo ven como sabotaje o estupidez. Si usas taxi a diario o un Uber a diario vas a pagar mucho. Que te lo explican, sí, pero después de cada viaje.

  • Me han pagado dinero desde hace unos 7 años para traducir a español las facturas de AWS.

¡Qué horror, ¿no? Hay cuatro situaciones que quiero destacar:

1. La mayor parte de los clientes medianos en México no pueden pagar esto. Y si pueden, mejor que te lo paguen a ti que a Azure o Amazon.

2. No me meto a arreglar AWS o Azure ajenos. Si me pasan la responsabilidad, me deben dar una autoridad y eso es DINERO. No se necesita ser un genio para entender que si de servidores pagan 20 mil y no sirve, no necesitas una ronda de financiación de capital, sino reducir costos.

3. El estándar en México paraprogramadores no .net, hace tres años era Laravel. Ahora Spring Boot y React, que en otros países van de salida ambos, pero llevamos siete años de atraso contra otros países.

4. «Traigo mi iPhone 24 pero ya salió el 25, este trabajo no me paga lo suficiente» es el equivalente para un programador a «tenemos siete timoneles y un remero, hay que poner un timonel más para mejorar al remero».

   • El equivalente a nivel organizacional es: tenemos siete directores y un programador. Y la solución que proponen los directores para que el programador rinda más es poner un octavo director que lo supervise, en lugar de darle un servidor que no sea un pantano de Snaps y complejidad innecesaria.

Es menos peligroso para los directores meterle más dinero a la nube que aceptar que su estructura es basura. Y siendo sinceros, el principal problema es que no solo el hardware es excesivo, sino que usan un stack innecesario sobre código no optimizado. Lo resuelves con simplificaciones graduales. Pero empieza verificando cuántos usuarios reales tienes y cuántos hace un año; los bots de Google no cuentan.

Viendo este panorama, queda claro que el problema no es la falta de dinero, sino el gasto de dinero a lo tonto y el exceso de complejidad. Voy a demostrarles que podemos tener control, respaldos y rendimiento con Debian 13 en una instancia de 4 GB, gastando menos de lo que Azure cobra por un simple error de configuración.

¿Cuál es el problema? Si te va bien, tienen dinero en el trabajo para meter en Amazon como escudo de impunidad para los directores. Y si quieres hacer respaldos te van a regañar. Y no falta quien quiere pagar 1500 USD al mes o menos a un «Senior» que además administre la nube.

Pero esta moda lleva solo unos dos años. Y no puede durar mucho. No vamos a regresar a Laravel y CodeIgniter, pero sí vamos a regresar a los servidores intermedios de costo fijo.

Me encuentro en una situación donde el administrador de dinero de la startup me pide alternativas «no nube». Y tengo que lidiar con tres equipos de programadores:

1. Spring Boot revueltos en tres modos con stacks. Algunos están tratando de migrar a Quarkus o Javelin.

2. PHP puros con algo de Laravel.

3. Python. (ese lo levanto en un server aparte y sobrado de 25 USD al mes mientras lo migran a otro lenguaje o un proveedor que els recomendé de 40 USD al mes)

Por eso di la plática del otro día. (Luego pongo la presentación de PowerPoint). El objetivo de este tutorial que haré es demostrar que hay proveedores como Vultr o VPS de terceros donde puedes configurar servers de 4 GB sin problema, pudiendo sacar respaldos y coexistiendo sus tres entornos de trabajo.

Premisas:

• Sabes dónde contratar un VPS decente.

• Para resolver problemas Puedes hacer como el barco de los Argonautas: cambiar una pieza y mejora gradual en todo, incluyendo CI/CD.

• Buscas costos fijos y predecibles para gerencia.

• Hay servicios intermedios como Vultr, Linode y DigitalOcean, así como Heroku, que te dan la escalabilidad y además te cobran por hora. Usamos Vultr porque es el mejor y porque Linode fue comprado recientemente por Akamai.

Para fines prácticos soy autodidacta en sistemas. Empecé a programar hace 34 años, en 1991, a los 19 años, leyendo manuales y especificaciones de lenguaje. Sí he tomado algunos cursos: Visual Basic Fundamentals y Visual Basic en New Horizons, allá por 1997. Estudié LSCA en 1995 en una universidad ya desaparecida; no vimos mucho de programación, salvo algo de lenguaje C.

He tomado cursos de bases de datos y he leído y programado mucho. Se dice que dominas un tema a las 10,000 horas. Eso equivale a unos cinco años de semanas de 8 horas diarias. Yo calculo que en mis primeros años trabajé, en promedio, de 80 a 90 horas semanales, llevando el manejo de personal al mismo tiempo y programando en mi casa los fines de semana. Así que puedo decir que en 1993, a los 21 años, probablemente ya tenía las 10,000 horas.

Mientras yo acumulaba horas reales de programación, las universidades seguían atrapadas en ejercicios desconectados de la práctica. Los planes de estudio suelen ser enseñados por personas que jamás pudieron ejercer. Por ejemplo, mi hijo estaba pensando en estudiar sistemas; el plan de UNITEC tenía solo TRES materias de programación: una era Base de Datos y la otra Programación Orientada a Objetos. Además de ser caro e inútil, le recomendé irse por la escuela pública a una Licenciatura (no Ingeniería, porque está negado para las matemáticas) y estudiar por fuera los temas importantes.

Mi trabajo me ha hecho interactuar con dos de las tres universidades públicas más grandes de México. He manejado servidores en la nube para dos de ellas; no creando para terceros, sino siendo el administrador de mis propios servidores y atendiendo a los usuarios. Esa experiencia me confirma que la brecha entre la práctica real y la enseñanza académica sigue siendo enorme. De plano, a veces no tengo idea de por qué los clientes con problemas usan lo que usan. Los programadores se van delos trabajos por lo no manejable, sea tecnología o factor humano. Muchas veces es el stack de tecnologías, y ahí es donde suena el teléfono y me llaman, o recibo un correo electrónico.

Tengo mi propia empresa (medida que tomé por ataques de una secta destructiva para proteger mi patrimonio), pero he pasado por unos quince trabajos de desarrollo. Los últimos quince años han sido con unos tres clientes fijos (incluyendo una de las universidades) y otro que recibía gente de servicio social para tratar de sustentar con «becarios» el costo de no contratar personal. Yo, sinceramente, los usaba para que hicieran videos y cosas así, lo mismo que con sus prácticas profesionales. Les enseñaba a levantar servidores y cómo manejar ciertos problemas con el recurso humano.

La Informática es el manejo de información; la Ingeniería está más enfocada en hardware; y la Licenciatura, en los procesos de negocios. Pero eso sí: casi todos los planes de estudio, a pesar de las calificaciones de 9.x, les dan la teoría pero no la práctica. También les enseñaba a los que querían cómo pasar exámenes en entrevistas de trabajo, así como los exámenes psicológicos. El mejor programador que vi de esos treinta muchachos tronó el psicológico inicial que le apliqué. Ni siquiera lo hubiera pasado a entrevista en el mundo real. Su trabajo fue regular: no entregó el esquema de base de datos, fue grosero con su compañera de clases y no supo decirme qué servicio de Java usaba, pero eso sí, estaba en Azure. ¿Autodidacta? Probablemente.

En mi experiencia, la universidad no prepara ni en lo técnico ni en lo humano. Me encuentro entonces con dos problemas principales:

1. Desarrolladores que aprenden algo impulsado por la moda y no saben que hay versiones o que el software cambia.

2. Personas que usan lo que usan solo porque es lo que hay donde están.

La universidad no enseña a evaluar el costo de mantenimiento. Los desarrolladores jóvenes eligen React porque es tendencia, pero si el core de la aplicación maneja datos complejos, muchas veces el costo de Azure o la memoria requerida salen más allá de los límites de estabilidad de una empresa mediana. Ahí entran desde aseguradoras con su propia empresa de software (el lugar más infame en ambiente y contradicciones que me tocó ver en 33 años de trabajo). También he visto casos donde prefieren pagar horas extra a alguien de planta que se la pasa usando Duolingo en yidish, esperanto y alemán en horas de trabajo, que pagar en tiempo y forma a la persona que saca el trabajo (que en este caso era yo, por honorarios).

Pero el costo de mantenimiento es también el costo de la continuidad de negocio. La deuda técnica. Si $2+2=4$ y $1+1+1+1=4$, pero el segundo método es más lento y propenso a errores, eso es lo que hace la mayor parte de las empresas. El enfoque universitario te impone ese $1+1+1+1$, pero el sentido común te dice otra cosa. No es normal que una cajera que gana casi el salario mínimo gaste el 20% de su sueldo en Uber por los días que estuvo a punto de llegar tarde. El tema es la relación con la continuidad de negocio, el «negocio en marcha» como decimos en contabilidad, y ese costo de mantenimiento.

En los últimos tres años nos hemos metido en una situación inmanejable. Ahora vamos por un $((1+1)+2)/2 \times 2$ para programar. Nuestras opciones de ecosistema de stack están mal. No solo por lo que enseñan. Así como las licencias de SQL Server son carísimas (sobre todo para México), tenemos capas en React y Java Spring Hibernate que son inmanejables y consumen mucha memoria costosa. El equivalente a los costos de SQL es querer Azure y AWS cuando tu lista de clientes no llega a 50 grandes y menos de 200 chicos.

Uno de los problemas que encontré entre 2014 y 2015 fue mi primer desastre ajeno a resolver de React. El cliente tenía una corrupción de Maven (el gestor de dependencias de Java, equivalente al Composer de PHP). Tenía un caché corrupto en la PC de alguien despedido. Normalmente habría descargado de nuevo Maven y santo remedio, pero no podía hacerlo por restricciones de permisos. En ese entonces React tendría unos tres o cuatro años y ya presentaba casi todos los problemas actuales. Mis opciones eran: a) llorar, b) formatear o c) hacer otra cosa.

Hice otra cosa. Aunque las incompatibilidades de Java son una razón para no usarlo en mis proyectos propios, eso no significa que no lo sepa. Terminé usando Gradle (que en 2025 sigue vigente) para limpiar el desastre. Explico, de años antrás en Java yo conocía Gradle y sabía que era similar a Maven. En lenguaje simple, el problema parecía ser Maven, y lo que acabé haciendo fue usar otro ‘configurador’ llamado Gradle (para simplificar, diré que es una alternativa a Maven pero más robusta).

¿Cómo identificas qué usa el usuario? Yo uso una bitácora MySQL que, con dos líneas de código en PHP o unas siete en Java, guarda en la base de datos si entraron a /app, /users, /ventas, etc. Tras cuatro días analizando el código infumable de React, mi base de datos me mostró 40 «puntos de entrada». Eso me dio una idea del problema.

Puse Gradle y empecé a migrar. Estaban implementando Spring Boot. Al universitario de hoy, doce años después, le enseñan Maven si bien le va; o si es autodidacta, aprende a buscar librerías (que pueden causar problemas de compliance). La mayoría no busca alternativas. Yo conozco varios modos de hacer las cosas. En un cliente de gobierno tuve que probar siete métodos antes de que uno funcionara por los puertos cerrados y la red inestable. Considerar alternativas no te lo dan en la universidad.

El problema en aquel proyecto era que la dependencia A llamaba a la librería XYZ v1.3 y la dependencia B usaba la v2.0. No podían coexistir. Usé un proceso llamado shadow para decidir qué dependencia usar. Pero el proceso que tampoco te enseñan en la escuela es SIMPLIFICAR, como diría Thoreau en Walden.

Simplificar es lo que salva los proyectos. Meter una dependencia innecesaria es, como diría Bulwer-Lytton en Zanoni: «El que echa agua en un lodazal no hace más que ensuciar el agua». Si tienes un buen elemento, págale. Si necesitas un proveedor, págale. Si quieres seguridad, saca tres respaldos diarios. Es simple.

Finalmente, en aquella ocasión, convertí el proyecto a Gradle en semana y media, quité React y usé Bootstrap con Thymeleaf (que venía por defecto en Spring Boot). Fue hace diez años y ya era un problema. React mete complejidad innecesaria con sus useEffects y la dependencia de componentes de terceros. Si eres responsable, no puedes hacer eso; por compliance, la responsabilidad es tuya si algo falla, especialmente en sectores de salud o financiero.

Un programador arriba del promedio sabe qué es Thymeleaf, aunque sea tecnología de hace diez años. ¿Por qué el 90% de las ofertas de empleo son sobre React y Spring Boot? El problema es que para muchos la curva de aprendizaje se quedó en lo primero que aprendieron. Si quiero un proyecto propio en Java, uso Quarkus. Si quiero que sea mantenible para otros, uso JDBC o Hibernate con Thymeleaf. Y les digo: NO usen Express del stack MEAN como si fuera la espada láser de los Jedi.

Desde 2014 enfrento servidores sobredimensionados en REACT y personas que no saben hacer un «Hola Mundo» sin llamar a quince dependencias. Se trata de buscar alternativas y simplificar. Como parte de lo que haré para mi cliente, levantaré desde cero un servidor Debian 13 con Spring Boot, Gitea y Thymeleaf (además de React para su migración). Su costo anual entre empleados y AWS es de 90,000 USD; ya no pueden pagarlo. Esta solución simplificada cuesta 35,000 USD anuales, solo por salirse de AWS y dejar React a mediano plazo.

Todo porque no buscan alternativas. Como ejemplo, dejaré una adaptación de un programa de terceros de un «carrito de ventas» en Spring Boot / Thymeleaf. El siguiente tutorial tratará sobre Debian y cómo:

• Instalar LAMP con PHP 8.4.

• Instalar MariaDB.

• Instalar Node.js y React.

• Instalar Gitea y cerrar puertos.

• Dejar andando Spring Boot bajo Thymeleaf y modo React.

La universidad y autdidactas estándard enseñan a acumular dependencias, pero la práctica exige simplificar para sobrevivir.

Lo más raro es que no solo cobraré por ello, sino que un programa que haga de cero lo que ellos hacen, lo terminaría yo en menos de un mes con Thymeleaf, o en 15 días con PHP puro.

Otros títulos:

• El espejismo de NPM contra la arquitectura
• Backend sabe programar y levantar servidores
• Full stack que no levanta su entorno es frontend junior

Introducción

Durante años,desde 2015 a 2020 el paradigma fue el stack MEAN. Hoy, en 2026, casi nadie menciona Express en las ofertas de empleo (la letra E); el discurso se ha simplificado a “Node.js + React”. Con eso, miles de programadores se autodenominan Full Stack. Pero la realidad es otra: el 80% de quienes ostentan ese título son frontends con pretensiones. Son capaces de correr un npm build y consumir APIs, pero son totalmente incapaces de debuggear un proceso en el servidor o levantar una infraestructura desde cero. Quizá saben un poco de Express. O consideran LEMP mejor que solo es un LAMP con Nginx en lugar de Apache.

Un fullstack que no puede levantar su propio servidor es solo un frontend con pretensiones.

El mito del Full Stack npm

Hagamos una distinción quirúrgica. En 2025-2026, la industria ha confundido la herramienta con la capacidad:

• npm build ≠ Full Stack: Compilar un frontend es empaquetar, no diseñar arquitectura.
• Consumir APIs ≠ Backend: Llamar endpoints ajenos es ser cliente, no creador de lógica de negocio.
• Express básico ≠ Arquitectura: Montar un app.get() siguiendo un tutorial no es diseñar un sistema robusto.
• Librerías Ajenas ≠ Compliance: Si usas entornos de gobierno, air gapped, de salud, o de dinero no puedes depender de módulos, librerías o dependencias de otros y mucho menos que se actualicen cada vez que les da la gana porque tienes que re certificarte. En estos sectores, cada cambio exige una re-certificación que implica tiempo y dinero. Si tu stack se actualiza solo y rompe la normativa, la responsabilidad (pero rara vez la autoridad) cae sobre ti.

La mayoría depende de conexión constante a internet, tutoriales y librerías externas que no comprenden. Son Full Stacks de teléfono descompuesto: repiten lo que otro hizo, con rendimiento y seguridad degradados en cada copia.

Que si hay un manual en línea para ver desde el celular la orden linux que necesitas si, pero npm o acceso a internet no lo tienes o esta prohibido. Composer y NPM con latencia en sierra de Puebla o en una dependencia de gobierno configurado el dns y firewall con las patas ? Se vale soñar.

Tienes que considerar estas posibilidades del mundo real Mexico 2025:

• Latencia extrema: Donde un npm install se queda colgado al 10% durante tres horas.
• Firewalls incompetentes: Donde las reglas de red son tan arbitrarias que nada sale ni entra de forma predecible.
• Aislamiento: Donde tu única herramienta es lo que ya está instalado en el servidor y lo que traes en la cabeza.
• No tienes Npm reciente instalado…. No tienes root ….Google es un dominio que no existe segun  el firewall….

Lo que he aprendido es que el «fullstack npm» (react  mas tantito express) no sobrevive fuera de condiciones ideales.

En proyectos serios de 2026, React no vive solo. Es lo que se ve, pero el motor debe ser sólido, corporativo e independiente. El mercado se ha polarizado:

• Spring Boot (Java): El estándar absoluto, con sus tres modos (Spring JDBC, JPA, Spring Data JDBC y si quieres puedes considerar WebFlux como un cuarto).
• Quarkus (Java): La evolución ligera y eficiente, ya presente en solicitudes reales.
• PHP: Contra todo pronóstico, sigue vigente en México: reproducible y soberano en entornos medianos, por COSTO.
• .NET (C#): Ecosistema aparte, fuerte en corporativos Microsoft.

Mientras tanto, lenguajes como Go o Python brillan en nichos, y otros como Angular o Jakarta EE han perdido tracción. Kotlin, Jakarta EE y Angular (ya de salida) han perdido fuerza en el mercado mexicano. Javelin es de nicho.  El verdadero Full Stack entiende que no se trata de usar la moda, sino la herramienta que garantice que el sistema sea mantenible y lo mas simple posible.

En mi punto de vista un devops actual debe poder levantar de cero:

• Infraestructura: LAMP / LEMP

• Front end: REACT o PHP

• Back end: Quarkus, Spring Boot, o PHP (con o sin frameworks)

Todo lo demás es de nicho. Y si quieren que configures por 1500 USD  Azure o AWS, hay un problema de fondo porque:

1. Alguien no sabe instalar de cero
2. Estan casados con aws azure o google cloud
3. estan sobredimensionados
4. Esperan crecer y en México a menos que seas empresa muy grande matas moscas a cañonazos
5. Esperan que lo hagas gratis y le reduzcas costos y se hagan respaldos solos (opuestos en AWS, los respaldos externos cuestan por egress)
6. Todas las anteriores.

Cuando piden un perfil que domine ocho tecnologías distintas, lo que buscan no es un arquitecto, es un chivo expiatorio barato, o no quieren pagar o estan perdidos en el espacio. Casi nunca quieren que les soluciones el problema. Quieren palabras bonitas como usar un Nissan 2007 para Uber black.

Aquí surge el gran cáncer corporativo de sistemas: darte la responsabilidad pero no la autoridad. Si tú eres el responsable de que el servidor no se caiga, debes tener la autoridad para decidir el stack. Si otro “mete mano” en AWS y el sistema falla, el Full Stack es quien paga por errores ajenos. El arquitecto real exige control sobre su búnker.

Independencia en entornos Air‑Gapped

Cualquiera es Full Stack cuando Stack Overflow está a un clic y las LLM igual. El experto de 2026 se demuestra cuando se cae el internet o cuando el entorno es Air‑Gapped (sin conexión externa). O cuando no tienes acceso a Root.

Si tu despliegue depende de descargar 2GB de dependencias de un servidor en California para funcionar, no tienes soberanía. El verdadero Full Stack tiene el conocimiento en la cabeza y el código en su propio servidor (Gitea), no en la nube de alguien más.

La independencia tecnológica se demuestra cuando se cae el internet y si te piden que te cases con azure o aws.

Definición razonable de Full Stack en 2026

Un Full Stack real es un arquitecto de soluciones que:

• Configura servidores como DevOps: domina Apache, Nginx, PM2, Gitea y el hardening de bases de datos.
• Une mundos: levanta un frontend en React que conviva con un backend sólido (Quarkus, Spring Boot o PHP).
• Domina el debugging: entiende los logs del sistema, no solo los errores rojos del navegador.
• Garantiza la independencia: sabe que lo simple tiene valor de supervivencia.
• PROGRAMA !!!!
• Es proactivo. No falta el que se tarda una semana en poner un certificado SSL y se llama administrador de Red

Mi punto de vista:

El término Full Stack está desgastado. Si no puedes levantar tu propio servidor desde una terminal limpia, no eres Full Stack; eres un frontend con acceso a una API. Por eso digo que soy Devops.

En 2026, el éxito no es saber usar todas las herramientas del mercado, sino saber cuáles sobran para que el sistema sea robusto, privado y eterno.

El verdadero Full Stack en 2026 no es quien sabe todas las tecnologías, sino quien sabe decir no a pedidos contradictorios (react native para web es mezclar mostaza con mermelada) y hace algo simple, que funciona, y es sólido.

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

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,