Reemplazar una factura de Heroku de 3,000 dólares al mes con un servidor de 55 dólares al mes

• La plataforma sin fines de lucro de búsqueda de empleo Idealist migró a un servidor dedicado de bajo costo para resolver el problema del alto costo de los entornos de staging en Heroku
• En Heroku, debido a un esquema de cobro por entorno, cada entorno de staging generaba un costo de alrededor de 500 dólares al mes
• Como alternativa, montaron varios entornos en un solo servidor Hetzner CCX33 (55 dólares al mes) y, con Disco, mantuvieron la misma experiencia de git push y automatización que tenían en Heroku
• En un solo servidor funcionan de forma estable 6 entornos de staging, con uso de CPU del 2% y uso de memoria de 14 GB de 32 GB, dejando margen de sobra
• Con esto, los entornos de staging pasaron de ser un “factor de carga de costos” a un “recurso que se puede crear libremente”, mejorando mucho la cultura de experimentación y despliegue del equipo de desarrollo

---

Experiencia práctica con una estrategia para reducir costos de Heroku

El problema: entornos de staging de 500 dólares al mes

• Idealist.org es una gran plataforma sin fines de lucro de búsqueda de empleo, con millones de visitantes al mes, por lo que necesita entornos de staging casi idénticos al entorno real de producción
• En Heroku, un solo entorno de staging que combinaba los dynos web y worker con los add-ons necesarios como Postgres costaba cerca de 500 dólares al mes
• Mantener solo dev y main ya generaba un costo fijo de más de 1,000 dólares
• El modelo de precios de Heroku es un esquema de cobro por entorno; incluso si se reducen dynos, el ahorro es pequeño, y a medida que crecen las aplicaciones los costos se disparan

El experimento: migrar a un solo servidor

• Para lograr una reducción de costos ideal, comenzaron el experimento alquilando un servidor Hetzner CCX33 único (55 dólares al mes)
• Usaron la solución Disco para llevar la forma de despliegue con git push de Heroku directamente al servidor
• Todos los entornos de staging aprovechan una instancia compartida de Postgres en el mismo servidor, reduciendo drásticamente la carga de costos de bases de datos administradas
• Desde la perspectiva de pruebas, esto también resulta adecuado porque permite reinicializar fácilmente bases de datos separadas por desarrollador

Por qué usar Disco: diferencias frente a Docker Compose

• Simplemente ejecutar docker-compose up en un servidor no ofrece una experiencia de desarrollador suficiente
• Disco aporta ventajas como las siguientes
  • El mismo proceso de despliegue con git push que en Heroku
  • Soporte automático para despliegues sin tiempo de inactividad en todos los despliegues
  • Emisión y renovación automáticas de certificados SSL para URLs por rama
  • Una interfaz web intuitiva para logs y gestión de entornos
• Así, pueden conservar la comodidad para desarrollo sin tener que construir ni mantener su propia automatización de gestión de despliegues

Explosión de entornos de staging y eficiencia de recursos del servidor

• Con Disco, es muy fácil ampliar los entornos de staging
• En un solo servidor operan al mismo tiempo entornos como estos
  • La rama principal
  • La rama feature-freeze
  • Entornos desechables temporales para PR
  • Entornos de larga duración para desarrollo de funcionalidades grandes, entre otros
• En total, mantienen 6 entornos de staging independientes sin problemas
• En Heroku esto habría requerido 3,000 dólares al mes, pero en Hetzner funciona con una estructura de bajo costo que consume solo 2% de CPU y 14 GB de memoria (de 32 GB)

Trade-offs y consideraciones realistas

• No es una alternativa perfecta y agrega cierta carga operativa
• Las tareas de infraestructura como configuración de DNS y CDN para cada entorno nuevo no están automatizadas
• Aparece la responsabilidad operativa de monitoreo del servidor, actualizaciones de seguridad y respuesta ante fallas
• Como Hetzner tiene regiones limitadas en Estados Unidos, puede no ser adecuado para servicios de producción dirigidos a usuarios en EE. UU.
• Existe el trade-off de disponibilidad de aceptar una reinstalación en caso de falla del servidor
• También hizo falta alrededor de un día de trabajo de ingeniería para adaptar la aplicación al networking de Docker

Aprendizajes y cambios obtenidos

• Tras más de 6 meses de operación, esta infraestructura se consolidó como una estructura permanente
• El mayor cambio no fue solo el ahorro de costos, sino que el propio staging pasó a verse como un recurso abundante y libre
• Ahora los desarrolladores pueden crear libremente entornos por pull request cada vez que lo necesitan, sin pedir aprobación ni preocuparse por el costo
• Dentro del equipo, la lección fue que no solo el costo era una carga, sino que la propia reticencia a usarlo era la verdadera pérdida
  • "La carga económica había estado limitando la velocidad de desarrollo y la experimentación"

[GN⁺]

Opinión de Hacker News

• Al ver la captura de htop, me llamó la atención que no hubiera swap, así que recomiendo activar earlyoom para evitar que se caiga todo el servidor cuando un servicio empieza a tragarse memoria de forma anormal; el OOM killer del kernel de Linux normalmente actúa demasiado tarde. También se puede activar zram para comprimir la RAM y sobreaprovisionar como un profesional. El software de larga ejecución suele tener fugas de memoria con frecuencia, y comprimirla resulta bastante eficiente. Dejé en un gist cómo aplicarlo con Ansible en servidores bare metal de Hetzner; funciona igual en VM.

  • No estoy nada de acuerdo: cuando llegas a usar swap, la mayoría de las apps ya empiezan a sufrir problemas serios. Esto es algo bien conocido, y por eso las instancias AWS EC2 también traen el swap desactivado por defecto. Claro, AWS quiere vender más RAM, pero aun así el swap no encaja con las expectativas actuales. En los 90 era normal esperar 2 o 3 segundos por un clic; hoy, si algo no responde, la gente asume que murió y lo reinicia de inmediato.

  • Otra alternativa es agregar más memoria y ajustar el oom_score por aplicación, dando un peso de kill más alto a las apps no críticas y un peso negativo a las importantes. Por ejemplo, OpenSSH ya trae oom_score_adj en -1000. También es muy útil desactivar en la práctica el overcommit en servidores de staging/producción. Según la capacidad de RAM, se calculan y configuran con una fórmula los valores de min_free y reserve. Lo vimos funcionar en producción durante más de 10 años operando 50,000 servidores físicos sin swap. Los OOM solo ocurrían cuando se calculaban mal los requisitos de memoria durante un despliegue de código. También pasa cuando no se siguen las buenas prácticas de Java, pero esa es otra historia. Otra opción es poner límites de memoria por aplicación con cgroup, pero omito la explicación. Si es un servidor completamente en memoria que no necesita escribir a disco, también recomiendo impedir por completo que ocurra OOM y dejar que se autorrecupere automáticamente. También son útiles los reinicios por pánico (kernel.panic, vm.panic_on_oom, etc.) para dar tiempo a capturar mensajes de crash por DRAC/iLO. Como dato adicional, en sistemas diskless con NFS esto incluso puede usarse intencionalmente para disparar el reinicio de toda la granja durante una contingencia.

  • Gracias por la buena información. Yo lo estoy controlando con límites del sistema (systemd) usando umbrales de RAM, pero me pregunto si earlyoom sería una mejor opción para evitar que toda la instancia quede sin respuesta cuando un proceso se comporta mal.

  • Creo que sí es buena idea dejar una cantidad muy pequeña de swap por si acaso, por ejemplo 1 GB.

  • No uso swap desde 2010.

• Ayer vi que Nate Berkopec escribió algo parecido sobre rendimiento de Rails: decía que Heroku cuesta entre 25 y 50 veces más por unidad de rendimiento. De verdad parece que no tienen la menor intención de competir en precio, y si al menos licenciara todo el stack a un precio razonable, como Sidekiq, sería muchísimo mejor aunque el hardware fuera aparte. Que en 2025 un dyno de 1 GB de RAM cueste $50 es casi un robo, sobre todo cuando una app estándar de Rails no ha aumentado mucho en consumo de recursos y hasta se ha vuelto más eficiente; sin embargo, el precio subió y la calidad bajó. Es hasta ridículo que tantos desarrolladores operen apps en Heroku pagando cientos de dólares al mes para correrlas en máquinas más lentas que sus propias MacBook de desarrollo. Al final, como en tantas otras cosas hoy en día, en vez de ofrecer un buen producto a precio razonable para todos, se enfocan solo en los clientes más adinerados y nada más suben los precios.

  • No es solo un problema de aumentos de precio. Creo que Heroku y los proveedores cloud se benefician del efecto de anclaje psicológico en precios: cuando un usuario empieza a usar el servicio fija un punto de referencia, y a partir de ahí sus expectativas solo cambian de forma lineal. El hardware real mejora de forma exponencial, pero el usuario lo percibe linealmente. Los precios de Heroku no han cambiado en al menos 7 años, pero el hardware sí avanzó muchísimo. Por eso se siente como una estafa: en realidad estás comparando el punto de referencia de 2025 contra precios de mediados de los 2010. Los grandes proveedores cloud ponen obstáculos como desbloquear rendimiento en hardware nuevo o actualizar SKU. Heroku, al no tener ese tipo de competencia, dejó el precio fijo; y este tipo de post aparece cada vez que una nueva generación de ingenieros nota cuánto rinde realmente el hardware.

  • Dijiste que un dyno de 1 GB RAM por $50 es un robo, pero AWS no es muy distinto: por $50/mes te dan un m7a.medium, que trae 1 vCPU y 4 GB de RAM. Sí, tiene más memoria, pero se entiende por qué AWS gana tanto dinero.

  • Me identifiqué con la idea de que ojalá existiera un modelo tipo Sidekiq que licenciara todo el stack de software a bajo costo, así que hicimos canine.sh open source. Pensábamos que no había razón para que los proveedores PaaS agregaran otro margen excesivo encima de un cloud que ya viene con margen.

  • Esto se parece a decir que cambiar el aceite en el taller del barrio o pedir un steak en un restaurante es más caro que hacerlo tú mismo en casa.

• La nube te hace olvidar cuántas cosas se pueden hacer con un solo servidor. Incluso para un entorno de staging me cuesta entender por qué subirlo a una nube cara, aunque sí entiendo que hoy la nube mezcla muchos factores complejos y por eso termina pareciendo necesaria.

  • Enseñar fundamentos de cloud a varios desarrolladores y tener unos pocos especialistas suele ser rentable por bastante tiempo. Si mantienes staging y producción parecidos, también detectas errores más rápido. Más adelante terminas pagando más en cloud que en personal, y ahí sí salirte de la nube empieza a dar beneficios reales. Creo que llega un punto en que cambiar a servidores propios supera el costo combinado del equipo y el hardware.

  • Siento que la nube ha hecho que muchos desarrolladores le tengan miedo al servidor Linux como tal. Gran parte del margen se cobra sobre esa ansiedad del desarrollador. Pero el self-hosting en realidad es fácil y divertido. Nunca me atrajeron Heroku ni Vercel, y sigo creyendo que no hay mejor experiencia que levantar tu propio servidor desde el principio. Se lo recomendaría a cualquier desarrollador.

  • Ayuda mucho replicar por completo el entorno de producción para que se parezca lo más posible a la operación real. Como el proceso de despliegue también se parece, ahorras tiempo y además pruebas en condiciones mucho más similares a producción.

  • Sería divertido montar un sitio para aprender infraestructura basado en esto: te dan X recursos en la nube y tienes que configurarlos para soportar cierta carga, con una puntuación de rendimiento para competir contra otras personas.

  • Por ahí de 2006, la máquina más pequeña de AWS tenía un tamaño comparable al de una buena desktop de desarrollo, así que había que alquilarla más de dos años para que se justificara. Hoy las máquinas de AWS están al nivel de un celular o una laptop barata, y con rentarlas entre 3 y 6 meses ya sale mejor comprar el hardware. A menos que te den 75% de descuento, on-prem termina ahorrando tanto personal como dinero frente a la nube.

• Hola, estoy desarrollando un PaaS open source llamado Disco junto con mi amigo Antoine Leclair. Últimamente se está hablando mucho de self-hosting y de salir de la nube. Si tienen preguntas, feliz de conversar cuando quieran.

  • Lo que dijiste de que “el uso de recursos del servidor era muy bajo” impresiona aún más si recuerdas que el load average en htop es por núcleo de CPU. Por ejemplo, si son 8 cores, un load average de 0.1 equivale a más o menos 1.25% de la capacidad total de CPU. Me gustó mucho leer el post; yo también he aprendido bastante viendo este tipo de patrones.

  • Me da curiosidad qué ofrece Disco específicamente frente a herramientas como Coolify. Ya tengo la mayoría de mis servicios alojados en un VPS de Hetzner, así que si Disco tiene una ventaja particular, me gustaría conocerla.

• En Hack Club tuvimos una experiencia parecida. Nuestra organización sin fines de lucro se enfoca en ayudar a estudiantes de preparatoria a iniciarse en programación y electrónica. Antes usábamos Heroku, pero no era solo por el costo: también nos hacía preguntarnos si estas pequeñas apps utilitarias realmente valían $15 al mes. Este año nos pasamos a self-hosting con Coolify y estamos corriendo 300 servicios en un solo servidor de Hetzner de $300 al mes. Como resultado, hemos podido desplegar muchísimo más código. La gran lección fue que, si no necesitas 99.99% sino solo 99% de uptime, el mundo se vuelve mucho más amplio. La mayoría de las herramientas para desarrolladores están obsesionadas con el 99.99%, pero si 99% te basta, puedes operar de forma mucho más eficiente. Disco me llamó la atención y definitivamente pienso probarlo.

  • Gracias; si tienes cualquier duda sobre el servicio Disco, con gusto te respondemos por Discord cuando quieras. Tenemos dos casos parecidos: una escuela/bootcamp de Puerto Rico hizo que todos los proyectos finales de sus estudiantes se desplegaran en un único VPS, y en Recurse Center están alojando 75 proyectos web en una sola Raspberry Pi (enlace).

  • Y si de verdad necesitas 99.99%, creo que lo correcto es evitar a los hyperscalers; el caso reciente fue la caída de varias horas en AWS.

  • ¿300? Me da curiosidad qué hace cada uno de esos servicios.

• Viendo la situación actual, creo que el self-hosting sí es una solución muy atractiva, pero quiero comentar algo sobre el texto en sí. Este artículo da la impresión de haber sido fuertemente editado por IA y, de hecho, la sección “Bridging the Gap: Why Not Just Docker Compose?” es una copia 1:1 del “Powerful simplicity” de la landing page del producto Disco. Además, este post del blog también es el único caso de estudio que muestran en su página principal.

  • Tienes toda la razón. Quisiera dar tres razones (es broma), pero nuestra librería es open source y me enorgullece que Idealist haya podido ahorrar costos. Si presumir cuenta como promoción, entonces sí, lo presumo con gusto.

  • Dices que el problema es que sea un texto de marketing, pero me gustaría entender por qué lo ves como problema. ¿Está prohibido por las reglas de Hacker News, o crees que todo marketing debería ir etiquetado? Casi nada en el mundo deja de ser marketing.

  • Están escribiendo un post de marketing sobre competir en precio, pero en su propia web no publican los precios y solo te dejan agendar una reunión; para mí esa es la mayor red flag posible en temas de precio.

  • Yo también fui a buscar enseguida cómo monetizan, pero solo me quedó la impresión de que pronto lo van a publicar.

  • No es la primera vez que aparece un artículo con algo de marketing detrás, y me pregunto qué tiene de malo el marketing a través de textos centrados en casos. Este me pareció un caso relativamente moderado y, aun con su tono promocional, me resultó interesante y útil.

• Los precios de Heroku están completamente locos. Hace como 10 años, en una startup donde trabajé, me impactó ver que gastaban más de $10,000 al mes solo para correr un servicio que generaba códigos QR en una tabla HTML y los mostraba en un correo. Salía como a $0.15 por unidad. El líder técnico ni siquiera había perfilado el código, así que lo bajé a $0.01 por unidad, pero aun así seguía siendo absurdo.

  • No entiendo por qué generar un solo código QR tendría que costar tanto si no tiene nada de especial. Incluso con hosting edge en la nube se podría hacer gratis.

• No termino de entender por qué harían falta 6 servidores de staging (de $500 cada uno). Si es por tener un equipo grande, ¿entonces $3,000 de infraestructura no es insignificante comparado con más de $100,000 al año en sueldos? Vi idealist.org y al final solo es un portal de empleo; se siente exagerado.

  • Los 6 servidores de staging existen para main, dev y varias ramas, de modo que QA no técnico pueda revisar directamente. Cada despliegue de staging empieza a sumar rápido entre dynos Performance-M, varios dynos Standard, RabbitMQ, base de datos, etc. El servicio de Idealist llega a 100,000 usuarios diarios, así que hay mucho trabajo técnico detrás de esa confiabilidad y velocidad.

  • Al leerlo, entendí que necesitaban varios servidores de staging porque los usaban como entornos de desarrollo donde cada desarrollador levantaba varios servicios al mismo tiempo.

  • En los cálculos reales de costos, todos tienden a pasar por alto el costo humano (man-days).

• Quiero reemplazar Heroku, pero solo para un sitio Django y su base de datos, y preferiría algo que no me obligue a administrar el sistema directamente. ¿Cuál sería la mejor opción?

  • Render.com es probablemente lo más parecido y de verdad me ha dejado muy satisfecho. El flujo de trabajo es igual al de Heroku, cuesta menos, y tanto los reinicios nocturnos como el soporte para versiones recientes de Python me han funcionado muy bien.

  • También te recomendaría aprender Docker Swarm. Desplegar es tan simple como hacer push del contenedor y correr un solo comando. Yo mismo hice rove.dev, una herramienta CLI gratuita que sirve tanto para despliegues como para ver el diff de servicios. Si no, también valen la pena PaaS basados en VM como Semaphore, Dokku o Dokploy.

  • Puedes elegir el VPS que quieras según precio/rendimiento/ubicación/soporte y luego montarle la herramienta de despliegue que prefieras, como Coolify o Dokploy. Hace poco migré Django/Postgres desde Google App Engine usando Coolify y Mythic Beasts, y aun con mis habilidades bastante oxidadas fue una migración realmente fácil.

  • Creo que con levantar un solo servidor en Hetzner y configurar nginx más algunos servicios con systemctl basta.

  • PythonAnywhere (enlace) también está bien.

• Gran proyecto. Viendo la documentación, me pareció que la integración con GitHub es un requisito obligatorio para Disco; ¿es así? Y además, ¿se pueden desplegar directamente imágenes Docker ya existentes en mi propio registro, sin un proceso de build aparte, algo parecido a --skip-push --version latest de Kamal?

  • Sí, por ahora la integración con GitHub es necesaria. Pero Disco también puede tomar y desplegar directamente imágenes Docker ya existentes (nosotros alojamos RabbitMQ de esa forma). Como ejemplo, puedes ver cómo desplegar una imagen de Meilisearch aquí y en este tutorial. Me da curiosidad si normalmente haces build y luego push al registro, y me gustaría conocer más a fondo tu proceso de despliegue.