Cómo reducir los costes de alojamiento de tu app

Para reducir los costes de alojamiento, averigua qué está realmente en marcha y por qué, y después deja que todo se duerma cuando nadie lo usa. En los hosts 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 arreglarlo, con prompts 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 unas pocas cosas. Saber cuál es la más grande te indica dónde mirar.

Muchos hosts modernos, incluido Mythex, escalan a cero: cuando nadie usa la app, el servidor se detiene y no cuesta nada en cómputo, y se activa en 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 host 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 las 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 que recibe consultas cada pocos segundos nunca se queda inactiva, así que pagas todo el día.

Los límites de alojamiento de Mythex explican cómo funciona esto para las apps publicadas: una app dormida no gasta nada en cómputo, la base de datos arranca en su tamaño más pequeño, crece mientras está ocupada, se duerme tras 5 minutos inactiva y se cobra según su tamaño multiplicado por el tiempo que estuvo despierta. Así, 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 comunes que mantienen una app despierta:

• Polling. 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 con actualización automática que recargan datos con un temporizador, aunque nadie los esté mirando.
• Monitores de disponibilidad que hacen ping a la app cada minuto.
• Bucles en segundo plano en el código del servidor: un setInterval que limpia o sincroniza datos para siempre.
• Peticiones programadas de «keep-alive» que alguien añadió para evitar una primera visita lenta: funcionan impidiendo que la app duerma, que es justo lo que cuesta dinero.

Pide a la IA que los encuentre:

Revisa el código y busca cualquier cosa que se ejecute con un temporizador o consulte la base de datos de forma repetida: polling, setInterval, actualización automática, bucles en segundo plano. Enumera cada uno, con qué frecuencia se ejecuta y si se ejecuta cuando nadie tiene la página abierta. No cambies nada todavía.

Después arréglalos uno a uno:

El panel hace polling a /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 vivo (un chat, un marcador en directo), pregunta si puede enviar actualizaciones solo cuando algo cambia, en lugar de preguntar 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 funciona bien; 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 tráfico medido que lo requiera.

En Mythex, el tamaño de la máquina se elige al publicar según lo que necesita la app, y las máquinas extra solo arrancan cuando el tráfico es alto y vuelven a dormirse 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 mayor parte.

• 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 del primer pantallazo.
• Cachea los archivos estáticos (scripts, estilos, imágenes) para que los visitantes que regresan no los vuelvan a descargar. Consulta qué es el caché.
• No dejes que la app entregue archivos grandes en cada visita a la página.

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

Páginas más rápidas y menor 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 consume tus créditos, así que un enlace olvidado que alguien sigue abriendo sigue costando dinero.
• Elimina los servicios no usados: 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, no guarda datos de usuarios y no tiene lógica de servidor —una web de marketing, un portafolio, una carta de restaurante—, puede ser un sitio estático: archivos simples 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 a APIs de pago

Para las apps que llaman a modelos de IA, mapas o SMS, las facturas de terceros pueden superar 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).
• Cachea las respuestas que no cambian, como geocodificar la misma dirección.
• Configura límites de gasto o alertas en cada proveedor.

Errores comunes

• Adivinar en lugar de medir. Revisa primero el desglose de uso; la parte cara a menudo no es la que esperarías.
• 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.
• Hacer polling de todo. Cada temporizador de pocos segundos es un motivo para que la base de datos se quede despierta.
• Hacer ping a la app para mantenerla «caliente». Eso elimina el ahorro que da escalar a cero. Acepta una breve espera 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 trabajos en segundo plano 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 en segundo plano 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 cargadas de forma diferida; los archivos estáticos están cacheados.
• 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 en 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 en la siguiente visita. La base de datos se duerme tras 5 minutos inactiva, así que eliminar el polling constante suele ser la mayor mejora.
• El plan Pro paga la mitad de la tarifa Free por alojamiento, bases de datos, ancho de banda, almacenamiento de archivos y el sandbox 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 una visión general de los costes de funcionamiento, consulta cuánto cuesta crear una app y qué es el alojamiento web.

Preguntas