¿Por qué mi app de Replit se duerme? Tipos de despliegue
Por qué una app de Replit deja de responder o tarda en despertar, en qué se diferencian Autoscale, Reserved VM, Static y Scheduled, y cómo elegir el correcto.
Read in English →
Una app de Replit "se duerme" por una de dos razones. O la gente está usando la URL de desarrollo (replit.dev), que solo funciona mientras tú estás trabajando en el proyecto, o la app está publicada como Autoscale, que baja a cero servidores cuando nadie la usa y tiene que arrancar de nuevo con la siguiente visita. La solución es compartir la URL publicada y elegir el tipo de despliegue que corresponde a cómo funciona tu app.
En esta guía te explicamos los cuatro tipos de despliegue sin tecnicismos, qué síntomas produce cada uno y qué cambiar para que la app responda cuando tus usuarios la necesitan.
¿Por qué mi app deja de funcionar cuando cierro Replit?
Si mandaste un enlace del tipo algo.replit.dev, eso es una URL de desarrollo. La documentación de Replit las describe como enlaces temporales para probar: solo están activas mientras trabajas en la app, y la dirección puede cambiar cuando vuelves a abrir el proyecto.
O sea, la app no se cayó: nunca estuvo desplegada. Publícala desde el panel Publishing y comparte la dirección publicada (o tu dominio propio). Si la publicación en sí falla, revisa nuestra guía sobre errores al desplegar con Replit Agent.
¿Qué tipos de despliegue tiene Replit?
Replit ofrece cuatro formas de correr una app publicada. Cambian en si hay un servidor siempre encendido y en cómo pagas.
| Tipo | Cómo funciona | Cobro | Sirve para |
|---|---|---|---|
| Autoscale | Suma servidores con el tráfico y baja a cero sin uso | Pagas mientras atiende peticiones | La mayoría de apps web y APIs |
| Reserved VM | Una máquina virtual dedicada que nunca se duerme | Costo mensual fijo | Bots, tareas en segundo plano, servidores siempre activos |
| Static | Solo sirve archivos, sin código de servidor | Replit la presenta como la opción económica | Landing pages, sitios solo de frontend |
| Scheduled | Arranca tu programa a las horas que eliges | Revisa la página de precios de Replit | Reportes, limpiezas, sincronizaciones diarias |
Autoscale es la opción por defecto de Replit y la correcta para casi todas las apps. El "sueño" viene incluido con ella.
¿Por qué la primera visita es tan lenta?
Con Autoscale, cuando pasa un rato sin peticiones, la cantidad de servidores puede bajar a cero para que no pagues por el tiempo muerto. El siguiente visitante provoca un arranque desde cero: la plataforma levanta tu app, corre su código de inicio y recién entonces responde. Esa primera respuesta es claramente más lenta que las siguientes. Replit no publica una cifra fija para esa demora, y depende mucho de tu propia app.
Lo que hace tu app al arrancar pesa más que cualquier ajuste. Las apps generadas por un agente de IA suelen:
- Correr migraciones o scripts de datos cada vez que arranca el servidor.
- Cargar archivos grandes o datasets en memoria antes de empezar a escuchar.
- Importar librerías pesadas que la primera página no necesita.
- Llamar a una API externa (un modelo de IA, un CRM) durante el arranque.
¿Cómo hago que despierte más rápido?
- Primero escucha, después haz lo opcional. Un servidor que responde en una fracción de segundo y carga lo demás después se siente mucho más rápido.
- Saca las migraciones del comando de inicio. Ejecútalas como un paso deliberado al publicar, no en cada arranque.
- Carga los datos cuando se piden y guárdalos en caché, en vez de leer todo al iniciar.
- Mira en los logs de publicación cuánto pasa entre el arranque y la primera petición atendida. Mide antes y después de cada cambio.
Un arranque rápido también te aleja del chequeo de salud de Replit, que puede hacer fallar una publicación si la página principal tarda más de cinco segundos en responder.
¿Por qué dejan de correr mis tareas programadas y temporizadores?
Una app que baja a cero no tiene ningún servidor encendido entre visitas. Todo lo que depende de que el proceso siga vivo también se detiene:
- Temporizadores con
setIntervalo estilo cron dentro del servidor web. - Colas que se procesan en memoria.
- Conexiones WebSocket y bots de chat que deben seguir conectados.
- Datos guardados en una variable en vez de en una base de datos (se pierden al reiniciar).
Si tu app hace trabajo con horario, pasa ese trabajo a un despliegue Scheduled que corra a horas fijas, o mueve la app completa a una Reserved VM, que Replit describe como una máquina dedicada que nunca se duerme, pensada para bots de chat y servidores de API siempre activos.
¿Conviene hacerle ping a la app para que no se duerma?
Vas a encontrar el consejo de visitar tu app en Autoscale cada pocos minutos desde un monitor externo para que nunca baje a cero. Puede funcionar, pero piensa en lo que implica: en Autoscale pagas mientras se atienden peticiones, así que estarías pagando por mantenerla ocupada, y convertirías un despliegue de pago por uso en una versión peor de uno siempre encendido.
Una regla mejor: si tus usuarios no toleran una primera petición lenta, o la app necesita hacer trabajo en segundo plano, elige Reserved VM y paga un monto mensual conocido. Si una pequeña demora en la primera visita del día no molesta, quédate en Autoscale y haz que el arranque sea rápido.
Un monitor de disponibilidad igual vale la pena, pero por otra razón: te avisa cuando la app está caída de verdad. Lo explicamos en la guía de monitoreo y errores en producción.
¿Cómo elijo el tipo de despliegue correcto?
Hazte tres preguntas:
- ¿La app tiene código de servidor? Si no lo tiene (solo HTML, CSS y JavaScript que llama a servicios externos), Static es lo más barato y no hay servidor que despertar.
- ¿Algo tiene que correr cuando nadie la visita? Temporizadores, bots, conexiones abiertas o procesadores de colas apuntan a Reserved VM, o a un despliegue Scheduled aparte para las tareas con horario.
- ¿Cuánto te cuesta una primera petición lenta? Una página de reservas que pierde clientes si duda no es lo mismo que una herramienta interna que usan tres personas.
Puedes cambiar el tipo de despliegue después desde el panel de publicación. Los costos cambian según el tipo, así que revisa los precios vigentes de Replit para tu plan, y mira nuestra guía sobre cuánto cuesta alojar tu app.
Respuestas rápidas
¿Por qué mi app de Replit se apaga cuando cierro el navegador? Seguramente compartes la URL de desarrollo replit.dev, que solo funciona mientras estás en el proyecto. Publica la app y comparte la URL publicada.
¿Autoscale de Replit se duerme? Baja a cero servidores cuando no hay uso, así que la primera petición después de un rato tiene que arrancar la app de nuevo.
¿Cómo dejo una app de Replit siempre encendida? Con un despliegue Reserved VM, que corre en una máquina dedicada que nunca se duerme.
¿Por qué se detuvo mi bot de Discord o mi tarea en segundo plano? En Autoscale no corre nada entre peticiones. Pasa el bot a Reserved VM y las tareas con horario a un despliegue Scheduled.
¿Necesitas ayuda para elegir o arreglar la configuración?
Si tu app tarda en despertar por lo que hace al arrancar, eso se arregla en el código, no cambiando de plan. Nuestro servicio para arreglar apps de Replit revisa las dos cosas, y para ayuda continua está el mantenimiento de software. Puedes empezar con la revisión gratuita de tu app o contarnos qué pasa.
