Respuesta corta
- No, cada cliente no necesita un servidor. El panel de concesionarias ya está hecho para atender a varios clientes desde una sola instalación. Es un edificio con departamentos, no una casa por persona.
- El servidor aguanta, pero hay un momento peligroso: cuando se compila la aplicación. Eso es lo que puede tirar todo. Se resuelve compilando afuera y con un tope de memoria.
- Lo que sí hay que pagar por cliente no es un servidor: son los mensajes de WhatsApp y el uso de inteligencia artificial de ese cliente.
Foto del servidor, ahora mismo
Esto no es una estimación: es lo que contestó la máquina hace un rato.
| Medida | Valor real | Qué significa |
|---|---|---|
| Memoria total | 7.751 MB (7,6 GB) | Es el tamaño de la casa |
| En uso | 3.213 MB | Lo que ya están usando tus 35 sistemas |
| Libre de verdad | 4.538 MB (4,5 GB) | El cuarto que le queda al panel |
| Memoria de auxilio (swap) | 0 MB | No hay red de contención. Esto hay que arreglarlo |
| Disco libre | 30 GB | Sobra para el panel y sus fotos |
| Procesadores | 4 | Suficiente para lo que hace |
41 % de la memoria ocupada por todo lo que ya corre (Gestor Obra, QM, el portal, los bots).
59 % disponible para el panel de concesionarias. Del lado de la memoria, hay lugar.
Lo que gasta cada cosa
| Qué | Memoria |
|---|---|
| El panel andando (Next.js) | 300 a 450 MB |
| Compilarlo (el momento peligroso) | 1.500 a 2.500 MB de golpe |
| El navegador automático cuando busca precios | 300 a 500 MB por cada búsqueda |
| Cada bot de WhatsApp de un cliente | 80 a 150 MB |
| Todo lo que ya corre hoy | 3.213 MB |
El riesgo real no es "andar", es "compilar"
Un programa andando tranquilo es como un auto en marcha: gasta poco. Compilarlo es como levantarlo con el gato hidráulico: necesita fuerza de golpe, por unos minutos.
Ahí es donde tu miedo tiene fundamento. Si compilamos dentro del servidor, ese pico de 2.500 MB puede chocar con los 4.500 disponibles, y como no hay memoria de auxilio, el sistema empieza a apagar cosas para sobrevivir: puede matar el Gestor Obra, o QM, o el portal. No porque sean débiles, sino porque el sistema elige a quién sacrificar.
Las tres defensas
Compilar afuera, no adentro.
El código se compila en GitHub, que tiene máquinas propias y gratis para repositorios privados. Al servidor solo llega el paquete ya armado, listo para andar. Así el pico de memoria ocurre en otra casa.
Ponerle red de contención al servidor.
Se agregan 4 GB de memoria de auxilio en el disco. Si algo se pasa de golpe, el sistema se frena un segundo en vez de apagar el Gestor Obra. No cuesta nada y es para siempre.
Ponerle techo al panel.
El panel corre con un tope de 1 GB: si algún día se descontrola, se frena él solo y no arrastra al resto. Es como ponerle un disyuntor a una sola habitación.
La pregunta del millón: ¿cada cliente, un servidor?
No. Y esta es la parte más importante del informe.
Tu panel de concesionarias ya está construido para eso. Adentro tiene una tabla de clientes (se llama tenants), y cada concesionaria vive en su propio espacio dentro de la misma base, con sus datos aislados. Lo dice el propio manual del proyecto: cada cliente tiene su nombre, su dirección web y sus datos separados.
La comparación: es un edificio de departamentos, no una casa por cliente. Cada concesionaria tiene su puerta, su timbre y su llave. Pero el edificio, la luz del pasillo y el portero son uno solo. Vos cobrás el alquiler del departamento; no construís una casa nueva para cada inquilino.
Entonces, ¿qué costaría cada cliente nuevo?
| Concepto | Modelo edificio (recomendado) | Modelo una casa por cliente |
|---|---|---|
| Servidor | US$0 (ya está) | US$11 a 13 por mes cada uno |
| Base de datos | Compartida, un departamento más | Una base nueva por cliente |
| Tu trabajo por cliente | Crear la ficha y su dirección: 10 minutos | Instalar, configurar, respaldar y actualizar: horas |
| Si se rompe algo | Lo arreglás una vez y sirve para todos | Lo arreglás en cada servidor, uno por uno |
| Con 10 clientes | 1 servidor | 10 servidores y 10 respaldos |
Con 10 clientes en el modelo de una casa por cliente tendrías 10 servidores para cuidar, 10 lugares donde se puede cortar la luz, 10 facturas y 10 actualizaciones. Para una sola persona eso no se sostiene.
Lo que sí se paga por cliente (y está bien cobrarlo)
- Mensajes de WhatsApp: los cobra Meta, por conversación. Ese gasto es del cliente y se le pasa en la factura.
- Uso de inteligencia artificial: si el bot de ese cliente responde con IA, cada respuesta cuesta monedas. Ahí conviene poner un tope por cliente.
- Fotos y videos que sube: ocupan disco. Mucho volumen, algún día, sí pide un disco más.
¿Cuántos clientes aguanta este servidor?
Con 4,5 GB libres y el panel usando unos 400 MB, quedan cerca de 4 GB. Cada cliente con bot de WhatsApp ronda los 100 MB. La cuenta gruesa da entre 15 y 25 clientes con bot, sin tocar nada.
Ojo: es una cuenta estimada, no medida, porque todavía no hay clientes reales adentro. En cuanto haya tres o cuatro, se mide de verdad y se sabe el número exacto.
Cuando se acerque el techo, las salidas —en orden de conveniencia— son:
- Ampliar este mismo servidor de 8 a 16 GB: unos 8 euros más por mes, y no se muda nada.
- Separar los bots a un segundo servidor chico, dejando el panel donde está.
- Un servidor nuevo por línea de producto (concesionarias por un lado, Gestor Obra por otro), pero nunca uno por cliente.
Y lo del Gestor Obra que te dije antes
Son dos cosas distintas y conviene no mezclarlas:
- Vender el acceso (SaaS): el cliente entra por internet a tu sistema. No necesita servidor propio. Vos le cobrás el uso. Es lo mismo que el edificio.
- Vender la aplicación instalada en su casa (licencia): ahí sí el cliente quiere el sistema adentro de su propia infraestructura, con sus datos en su servidor. Eso es otra cosa, y sí necesita un servidor propio —los 11 a 13 dólares— o que él lo pague.
Cuando te dije "para vender el Gestor Obra hace falta otro servidor", me refería a la segunda: una instalación privada para un cliente que quiere todo adentro de su empresa. No a cada cliente nuevo del modelo normal.
Próximo paso
Te propongo hacerlo con las tres defensas puestas: compilado afuera, 4 GB de red de contención y tope de 1 GB para el panel. Así el riesgo de tirar el sistema abajo queda prácticamente en cero.
Decime "dale" y arranco por la red de contención y el compilado afuera, antes de tocar el panel. En el camino te aviso cuánto gasta de verdad, medido, no estimado.
Medido hoy en tu servidor (46.224.217.146) con free, docker stats y top. Los consumos del panel son estimaciones de referencia de una aplicación de su tamaño y se confirmarán midiendo después de instalarlo.