Cómo se aloja DevQuake
Por ProxySys3 min de lectura
Este artículo contiene un enlace de referido a Hostinger. Si te registras a través de él podemos recibir una comisión, sin coste adicional para ti. Nuestro alojamiento lo pagamos nosotros, y todo lo que sigue nos ha pasado de verdad.
Quienes crean sitios pequeños suelen preguntar qué hace falta realmente para mantener algo como DevQuake. Esta es nuestra configuración, incluida la parte que salió mal.
Qué se ejecuta y dónde
DevQuake es una aplicación Next.js con apps independientes, cada una en su propio subdominio: darts.devquake.com, utilities.devquake.com, etc. Funciona en un plan Node.js gestionado de Hostinger, con bases de datos MySQL en el mismo plan.
El sitio y cada subdominio de app ejecutan su propia copia de la aplicación. Este único hecho determina casi todas las demás decisiones, como verás.
Publicar es sencillo: un merge en la rama principal inicia una compilación, que publica un paquete listo para ejecutar, y el proveedor lo vuelve a desplegar. En el servidor no se compila nada.
Qué mirar en el precio
Los anuncios y referidos del blog ayudan a pagar el alojamiento, para que las apps sigan sin anuncios.
El alojamiento no es la única factura. El dominio y el servicio de voz detrás de las voces naturales del entrenador se pagan aparte. Mira el precio actual antes de decidir, porque los planes suelen ser mucho más baratos el primer periodo que al renovar.
El día en que nos quedamos sin recursos
El 22 de octubre de 2026 nuestro plan se quedó sin recursos. Las páginas empezaron a responder con la página de error 503 del proveedor o simplemente se quedaban colgadas.
La causa fueron los hilos. Un plan como el nuestro limita los procesos e hilos que puedes ejecutar, 120 en nuestro caso. Cada copia de la aplicación necesitaba unos siete hilos, y con más de una docena de copias estábamos cerca del límite antes de que llegara el primer visitante.
Qué cambiamos
- Las copias inactivas se cierran. Un subdominio que nadie usa se apaga y vuelve a arrancar en la siguiente visita. Una app poco usada casi no cuesta nada, a cambio de una primera página más lenta.
- Menos hilos por copia. Node.js puede funcionar con grupos de hilos más pequeños que los predeterminados, y los nuestros ahora están limitados.
- Sin tareas siempre activas. El trabajo programado se hace en una sola ejecución común, no en temporizadores dentro de cada proceso.
- El trabajo pesado se hace en el navegador. Leer la foto de un contador o reducir una imagen ocurre en el dispositivo del visitante, no en nuestro servidor.
- Los archivos van en la base de datos. Un despliegue sustituye la carpeta de la aplicación, así que lo guardado en disco se perdería.
- Cada función nueva pasa una revisión de costes: hilos, memoria, tareas y espacio.
A quién le conviene
Funciona bien si tienes un sitio o unas pocas apps pequeñas, tráfico moderado, quieres un solo panel para dominios, SSL, bases de datos y correo y no quieres ocuparte de un servidor.
No te conviene si necesitas procesos en segundo plano de larga duración, módulos nativos con hilos propios o muchos procesos siempre activos. Alcanzarás el límite de procesos, y te irá mejor con un VPS.
Lo que nos diríamos a nosotros mismos
- Averigua el límite de procesos antes de añadir la décima app. Mira la página de recursos del panel, no solo el espacio en disco.
- Cuenta los hilos, no solo la memoria.
- Incluye el apagado por inactividad desde el principio.
- Consigue el certificado SSL de un subdominio nuevo antes de abrirlo, sobre todo si tu sitio envía HSTS con subdominios incluidos: sin él, los navegadores lo rechazan.
Si quieres probarlo
Si esta configuración encaja con lo que estás construyendo, puedes registrarte con nuestro enlace de referido: ver los planes de Hostinger. No te cuesta nada más y ayuda a pagar DevQuake. Si no encaja, un VPS pequeño es la alternativa honesta.
Etiquetas:#alojamiento web#hosting Node.js#Hostinger
También en:DeutschEnglishMagyarItalianoRomână
Comentarios
Todavía no hay comentarios. ¡Empieza la conversación!