Cómo reducir los costes de alojamiento de tu app

Para reducir los costes de alojamiento, averigua qué está funcionando realmente y por qué, y luego deja que todo duerma cuando nadie lo usa. En los alojamientos que escalan a cero, una app inactiva y una base de datos dormida cuestan muy poco, así que los mayores ahorros suelen venir de eliminar lo que las mantiene despiertas —casi siempre código que consulta la base de datos cada pocos segundos— y después de reducir el ancho de banda y borrar las apps que nadie usa.

La mayoría de las apps pequeñas no tienen un problema de tráfico. Tienen un problema de «algo está siempre encendido». Esta guía muestra cómo encontrarlo y corregirlo, con indicaciones que puedes dar a un creador de apps con IA.

Lo que realmente pagas

Las facturas de alojamiento de las apps pequeñas vienen de unos pocos conceptos. Saber cuál es el grande te indica dónde mirar.

Muchos alojamientos actuales, incluido Mythex, escalan a cero: cuando nadie usa la app, el servidor se detiene y no cuesta nada en cómputo, y se reactiva con la siguiente visita. Eso cambia la pregunta de «¿qué tamaño tiene mi servidor?» a «¿por qué mi servidor está despierto?».

Paso 1: Mira a dónde va el dinero

Antes de cambiar nada, abre la página de uso de tu alojamiento y busca:

• Qué proyecto cuesta más. A menudo una sola app es la mayor parte de la factura.
• Qué categoría: cómputo, base de datos, ancho de banda o almacenamiento.
• Cuándo gasta. Una línea plana durante la noche, cuando no tienes usuarios, es la pista de que algo mantiene la app despierta.

En Mythex, Detalles de uso muestra los últimos 30 días divididos en Build (el agente de IA) y Run (alojamiento, ancho de banda, base de datos y almacenamiento de archivos), con un desglose por proyecto.

Paso 2: Deja dormir las apps y bases de datos inactivas

Esta es la palanca real para la mayoría de las apps pequeñas. Una base de datos que se duerme cuando está inactiva y se despierta con la siguiente petición cuesta casi nada en las horas tranquilas. Una base de datos a la que se consulta cada pocos segundos nunca queda inactiva, así que pagas todo el día.

Los límites de alojamiento de Mythex explican cómo funciona esto en las apps publicadas: una app dormida no gasta nada en cómputo, y la base de datos arranca en su tamaño más pequeño, crece cuando está ocupada, se duerme tras 5 minutos inactiva y se cobra por su tamaño multiplicado por el tiempo que estuvo despierta. Así que una app que consulta su base de datos aunque sea una vez cada pocos minutos, de día y de noche, se factura como si estuviera siempre ocupada, mientras que la misma app sin actividad de fondo cuesta muy poco.

Cosas habituales que mantienen una app despierta:

• Sondeo. Una página que pregunta al servidor «¿hay algo nuevo?» cada 2–5 segundos. Si dejas esa pestaña abierta en un portátil, la base de datos nunca se duerme.
• Paneles que se recargan solos con un temporizador, aunque nadie los esté mirando.
• Monitores de disponibilidad que hacen ping a la app cada minuto.
• Bucles de fondo en el código del servidor: un setInterval que limpia o sincroniza datos para siempre.
• Peticiones programadas de «mantener activo» que alguien añadió para evitar una primera visita lenta. Funcionan impidiendo que la app duerma, que es exactamente lo que cuesta dinero.

Pide a la IA que los encuentre:

Revisa el código en busca de cualquier cosa que se ejecute con un temporizador o que consulte la base de datos repetidamente: sondeo, setInterval, recarga automática, bucles de fondo. Enumera cada uno, con qué frecuencia se ejecuta y si se ejecuta cuando nadie tiene la página abierta. Todavía no cambies nada.

Después corrígelos uno a uno:

El panel consulta /api/orders cada 3 segundos. Cámbialo para que se actualice solo mientras la pestaña del navegador está visible, y cada 60 segundos en lugar de cada 3. Añade un botón manual de Actualizar.

Si tu app necesita actualizaciones en directo (un chat, un marcador en vivo), pregunta si puede enviar actualizaciones solo cuando algo cambia, en lugar de pedirlas constantemente. En muchas apps, «actualizar cuando el usuario vuelve a la pestaña» es suficiente.

Paso 3: Ajusta el tamaño del servidor

Las máquinas más grandes cuestan más por hora. Muchas apps creadas con IA empiezan con un tamaño por defecto que basta; los problemas aparecen cuando se pide «más potencia» para arreglar una lentitud que en realidad era una consulta lenta.

• Mantén el tamaño más pequeño que atienda tu tráfico sin errores.
• Si ves caídas por memoria, pregunta primero a la IA si la app carga demasiado en memoria (una tabla entera en lugar de una página de resultados).
• Añade máquinas solo si tienes un tráfico medido que las necesite.

En Mythex, el tamaño de la máquina se elige al publicar según lo que necesite la app, y las máquinas extra se activan solo cuando el tráfico es alto y vuelven a dormir cuando baja. El coste sigue al tamaño, así que pide en el chat un tamaño menor si crees que está sobredimensionado.

Paso 4: Reduce el ancho de banda

El ancho de banda es lo que descargan los visitantes. Las imágenes suelen ser la parte más grande.

• Comprime las imágenes y sirve formatos modernos como WebP o AVIF.
• Redimensiona las imágenes al tamaño con el que se muestran. Una foto de 4.000 píxeles mostrada como miniatura de 400 píxeles desperdicia casi todo lo que se descarga.
• Carga las imágenes de forma diferida cuando están por debajo de la primera pantalla.
• Pon en caché los archivos estáticos (scripts, estilos, imágenes) para que los visitantes que vuelven no los descarguen otra vez. Consulta qué es la caché.
• No dejes que la app entregue archivos grandes en cada vista de página.

Revisa cada imagen de la app. Redimensiónalas al tamaño más grande con el que se muestran, conviértelas a WebP y carga de forma diferida todo lo que quede debajo de la primera pantalla. Dime el tamaño total antes y después.

Páginas más rápidas y menos ancho de banda suelen ir de la mano; consulta cómo hacer tu sitio web más rápido.

Paso 5: Limpia lo que nadie usa

• Despublica las apps antiguas: despliegues de prueba, experimentos terminados, la web del evento del año pasado.
• Borra subidas, registros y exportaciones antiguos que no necesites.
• Elimina los enlaces de vista previa compartidos que ya no uses. En Mythex, abrir un enlace de vista previa despierta el proyecto y funciona con tus créditos, así que un enlace olvidado que alguien sigue abriendo sigue costando.
• Quita los servicios sin uso: un servidor de API o un worker que la app ya no llama.

Paso 6: Considera un sitio estático

Si tu sitio no tiene inicios de sesión, ni datos guardados de usuarios, ni lógica de servidor —una web de marketing, un portfolio, una carta de restaurante—, puede ser un sitio estático: archivos planos servidos desde una CDN. No hay servidor ni base de datos que mantener en marcha. En Mythex, los sitios estáticos no consumen créditos mientras están ahí.

Este sitio no tiene inicios de sesión ni datos guardados. ¿Se puede reconstruir como sitio estático sin servidor? ¿Qué perderíamos?

Paso 7: Vigila las llamadas de API de pago

Para las apps que llaman a modelos de IA, mapas o SMS, las facturas de terceros pueden superar con creces al alojamiento.

• Exige inicio de sesión para todo lo que cueste dinero por llamada.
• Añade un límite por usuario (consulta qué es la limitación de peticiones).
• Guarda en caché las respuestas que no cambian, como geocodificar la misma dirección.
• Define límites de gasto o alertas en cada proveedor.

Errores habituales

• Adivinar en lugar de medir. Revisa primero el desglose de uso; la parte cara suele no ser la que esperabas.
• Comprar un servidor más grande para arreglar la lentitud. Un índice de base de datos que falta o cargar demasiados datos suele ser la causa real.
• Sondear todo. Cada temporizador de pocos segundos es un motivo para que la base de datos siga despierta.
• Hacer ping a la app para mantenerla «caliente». Eso elimina el ahorro que te da escalar a cero. Acepta un breve arranque en la primera visita, o paga por tenerla siempre encendida de forma deliberada.
• Olvidar despliegues antiguos. Las apps sin uso con bases de datos y tareas de fondo suman costes en silencio.
• Imágenes sin comprimir. A menudo es el mayor coste de ancho de banda en sitios pequeños.

Lista de comprobación

• Sé qué proyecto y qué categoría (cómputo, base de datos, ancho de banda, almacenamiento) cuesta más.
• Nada consulta la base de datos cada pocos segundos cuando nadie está mirando.
• Los paneles se actualizan con un intervalo razonable o solo mientras la pestaña está visible.
• Ningún monitor de disponibilidad ni bucle de fondo mantiene la app despierta sin motivo.
• El servidor es el tamaño más pequeño que funciona.
• Las imágenes están redimensionadas, comprimidas y con carga diferida; los archivos estáticos están en caché.
• Las apps antiguas están despublicadas, los archivos antiguos borrados y los enlaces de vista previa sin uso eliminados.
• Los sitios sin datos ni inicios de sesión son estáticos.
• Las APIs de pago tienen inicio de sesión, límites por usuario y alertas de gasto del proveedor.

Reducir costes en Mythex

Mythex usa un único saldo de créditos para construir y para alojar, así que los ahorros de alojamiento dejan más créditos para construir. Algunos puntos específicos de Mythex:

• Las apps publicadas y sus bases de datos se duermen cuando están inactivas y se despiertan con la siguiente visita. La base de datos se duerme tras 5 minutos inactiva, así que eliminar el sondeo constante suele ser la mayor mejora.
• Pro paga la mitad de la tarifa de Free por alojamiento, bases de datos, ancho de banda, almacenamiento de archivos y el entorno de vista previa; la IA cuesta lo mismo en ambos planes. Consulta Créditos.
• Recibes un correo antes de que un saldo bajo pausara una app publicada, y las apps pausadas conservan su base de datos y sus archivos.

Para la visión general de los costes de funcionamiento, consulta cuánto cuesta crear una app y qué es el alojamiento web.

Preguntas