[{"data":1,"prerenderedAt":551},["ShallowReactive",2],{"blog-es-\u002Fes\u002Fblog\u002Fheroctl-vs-coolify":3,"blog-es-surround-\u002Fes\u002Fblog\u002Fheroctl-vs-coolify":539},{"id":4,"title":5,"author":6,"body":7,"category":520,"cover":521,"date":522,"description":523,"draft":524,"extension":525,"lastReviewed":521,"meta":526,"navigation":527,"path":528,"readingTime":529,"seo":530,"sitemap":531,"stem":532,"tags":533,"__hash__":538},"blog_es\u002Fes\u002Fblog\u002Fheroctl-vs-coolify.md","HeroCtl vs Coolify: cuando el panel de un servidor no basta","Equipo HeroCtl",{"type":8,"value":9,"toc":508},"minimark",[10,14,17,22,25,28,42,53,56,60,63,66,69,85,88,91,95,98,101,104,107,124,127,130,134,137,140,143,146,149,153,156,308,311,314,318,321,328,334,340,346,352,355,359,362,368,374,380,386,389,392,396,402,408,414,420,426,432,438,444,448,451,454,457,460,494,501,504],[11,12,13],"p",{},"La pregunta nunca fue \"¿Coolify es bueno?\". Es bueno, sí. La pregunta es \"¿hasta cuándo Coolify es suficiente?\".",[11,15,16],{},"Este post no es sobre desbancar nada. Es sobre dibujar una línea — donde el panel en un servidor único deja de ser la respuesta correcta y empieza a ser una trampa silenciosa que aparece en el peor momento posible: en la primera reunión con el primer cliente que pregunta el número del SLA.",[18,19,21],"h2",{"id":20},"por-que-coolify-gano-el-segmento","Por qué Coolify ganó el segmento",[11,23,24],{},"Vale la pena empezar reconociendo lo que Coolify acertó, sin ironía.",[11,26,27],{},"Instalación de cinco minutos en una VPS de US$10 al mes. Panel limpio, con un vocabulario familiar para cualquier persona que ya tocó Heroku o Vercel. Plugin ecosystem activo, comunidad comprometida, lanzamientos frecuentes. El contrato gratuito para self-hosting nunca cambió.",[11,29,30,31,36,37,41],{},"Para un indie hacker en abril de 2026, con un servidor de 4 GB de RAM ejecutando un SaaS de US$5 mil de MRR, Coolify es la mejor opción que existe en el mercado. Mejor que Dokku, mejor que Caprover, mejor que ",[32,33,35],"a",{"href":34},"\u002Fes\u002Fblog\u002Fheroctl-vs-dokploy","Dokploy"," en madurez — e infinitamente mejor que orquestar la misma carga en Kubernetes gestionado, que cobraría US$73 al mes solo por el plano de control, antes de NAT, balanceador y cualquier cosa que entregue valor — asunto que destrozamos en ",[32,38,40],{"href":39},"\u002Fes\u002Fblog\u002Fkubernetes-overkill-cuando-no-lo-necesitas","Kubernetes es overkill: cuando no lo necesitas",".",[11,43,44,45,49,50,52],{},"La categoría \"",[32,46,48],{"href":47},"\u002Fes\u002Fblog\u002Fheroku-auto-hospedado-2026","Heroku auto-hospedado simple","\" fue inventada por esa generación de herramientas. Coolify, ",[32,51,35],{"href":34},", Caprover dividen ese podio. Coolify lidera en adopción, en comunidad y en ritmo de release. No es por casualidad.",[11,54,55],{},"El punto de este artículo es específico: existe una pared que aparece cuando tu producto crece, y esa pared no tiene solución elegante dentro de Coolify. Es un límite arquitectural, no un bug que se vaya a arreglar.",[18,57,59],{"id":58},"la-pared-invisible-el-servidor-unico","La pared invisible: el servidor único",[11,61,62],{},"Coolify fue diseñado en torno a un servidor central. El panel vive ahí. La base de configuración vive ahí. Las decisiones de deploy parten de ahí.",[11,64,65],{},"Eso es una elección de diseño coherente — para quien está en una sola VPS, esa centralización es exactamente lo que vuelve el producto tan simple. No hay red de cluster que debuguear, no hay certificado entre nodos, no hay replicación de estado que entender. Enciendes una máquina, instalas, deployas. Cinco minutos.",[11,67,68],{},"La cuestión es lo que sucede en los escenarios siguientes:",[70,71,72,76,79,82],"ul",{},[73,74,75],"li",{},"El disco de la VPS empieza a presentar errores de I\u002FO. El proveedor agenda mantenimiento para \"remediar\". La máquina queda indisponible por tres horas en una madrugada de miércoles. Todo lo que corría en ella está fuera.",[73,77,78],{},"Un update del kernel es empujado por el proveedor y la máquina reinicia sola. El panel de Coolify vuelve — pero tres contenedores entran en loop de restart porque dependen de un volume mount que aún está siendo remontado. Lo descubres cuarenta minutos después, por el Twitter de un cliente.",[73,80,81],{},"El datacenter entero del proveedor tiene un incidente de red regional. Sucede en enero de 2024 con un gran proveedor europeo, en octubre de 2024 con un proveedor americano, en febrero de 2026 con un proveedor latinoamericano. Tu máquina ni siquiera está con defecto — solo quedó inalcanzable.",[73,83,84],{},"Un deploy malo consume toda la memoria de la máquina, el OOM killer empieza a tirar procesos, y el propio panel de Coolify entra en loop. No tienes dónde clicar para revertir porque la interfaz que controla el cluster está dentro de la máquina que necesita ser controlada.",[11,86,87],{},"En todos esos escenarios, la respuesta operacional es la misma: rezar para que la máquina vuelva, o abrir un ticket, o subir una nueva máquina y restaurar backup. No hay failover automático. No hay otra réplica del panel para asumir. No hay elección de coordinador entre servidores sobrevivientes — porque solo existe un servidor.",[11,89,90],{},"Cuando tu primer cliente serio pregunta \"¿cuál es el SLA?\", la respuesta honesta es \"best-effort, nuestra máquina principal tiene tres nueves de uptime histórico del proveedor\". Es una respuesta que funciona para algunos clientes. No funciona para clientes que tienen el propio SLA por honrar. Y son justamente esos clientes los que pagan contratos anuales.",[18,92,94],{"id":93},"multi-servidor-en-coolify-no-es-alta-disponibilidad-real","Multi-servidor en Coolify no es alta disponibilidad real",[11,96,97],{},"La confusión más común en esta conversación es el feature \"remote servers\" de Coolify.",[11,99,100],{},"Coolify permite, sí, conectar máquinas adicionales como destinos de deploy. Registras un IP, configuras una clave SSH, y el panel pasa a saber que puede subir contenedores en aquella máquina remota. Para quien necesita separar staging de producción, o colocar workers en una máquina más barata, es útil de verdad.",[11,102,103],{},"Pero eso no es alta disponibilidad. Es distribución de carga.",[11,105,106],{},"La diferencia está en dónde vive el cerebro del sistema. En Coolify, el cerebro es la máquina principal — donde el panel corre, donde la base SQLite o Postgres de Coolify vive, donde las colas internas están. Las máquinas remotas son brazos. Si el cerebro se cae, los brazos siguen sosteniendo lo que tenían en las manos en el momento de la caída — los contenedores ya en ejecución no mueren. Pero pierdes:",[70,108,109,112,115,118,121],{},[73,110,111],{},"El panel web, integralmente.",[73,113,114],{},"La capacidad de hacer deploys, revertir, cambiar variable de entorno, leer log centralizado.",[73,116,117],{},"La capacidad de redirigir tráfico entre réplicas si una se cae.",[73,119,120],{},"Renovación automática de certificados (si la máquina principal era la que respondía al desafío ACME).",[73,122,123],{},"Health checks que reiniciarían contenedores con problema.",[11,125,126],{},"Quedas en un estado zombi: el sitio del cliente puede seguir respondiendo por algunas horas, pero perdiste el control del orquestador. Reencender la máquina principal se vuelve la única operación útil — y si la razón de la caída fue disco corrupto, estás restaurando backup a las cuatro de la mañana.",[11,128,129],{},"Eso no es fallo de Coolify. Es una consecuencia directa del diseño arquitectural — diseño que tiene total sentido para quien nunca va a necesitar nada además de eso. El problema es cuando tu empresa crece y las expectativas del cliente cambian. La herramienta no crece junto.",[18,131,133],{"id":132},"el-paso-siguiente-natural","El paso siguiente natural",[11,135,136],{},"HeroCtl empieza exactamente donde Coolify para. Misma promesa de instalación simple — un comando, cinco minutos, panel web listo. Pero el cerebro del sistema es replicado entre tres o más servidores desde el primer momento.",[11,138,139],{},"En términos prácticos: instalas el mismo binario en tres máquinas Linux con Docker. Los tres servidores combinan estado entre sí por consenso entre servidores. Decisiones importantes (qué contenedor va a qué nodo, qué versión está activa, qué certificado está renovado) son grabadas en el log replicado y confirmadas solo después de que la mayoría concordó. Si uno de los tres se cae — kill -9, caída de energía, partición de red — los dos que sobraron eligen un nuevo coordinador en unos siete segundos y siguen sirviendo tráfico.",[11,141,142],{},"No es magia. Es una técnica conocida hace veinte años, usada en producción por bancos, por sistemas de mensajería, por bancos de datos distribuidos. La novedad de HeroCtl es empaquetar eso en un paquete que instalas en cinco minutos, con panel web embebido y sin exigir un operador especializado.",[11,144,145],{},"El router integrado distribuye el tráfico entrante entre las réplicas saludables automáticamente. Si un servidor está fuera, deja de recibir peticiones — sin que necesites tocar el DNS, sin que necesites despertarte de madrugada. Los certificados Let's Encrypt viven en el log replicado, así que cualquier servidor sobreviviente puede renovarlos y servirlos; no hay \"máquina principal\" responsable del TLS.",[11,147,148],{},"La batería de tests de caos cubre los escenarios reales: kill -9 del coordinador (elección en siete segundos, sin pérdida de petición de lectura), partición de red de 30 segundos (cluster reconverge solo), pérdida momentánea de quórum (sistema entra en modo solo-lectura preservando el tráfico existente, retoma escrituras cuando el quórum vuelve), wipe de disco en un nodo (rejoina el cluster y baja el estado del log replicado), drain forzado (workloads migran a los nodos sobrevivientes en segundos). Los cinco escenarios sobrevividos en el cluster público que sirve este blog.",[18,150,152],{"id":151},"lado-a-lado-sin-floritura","Lado a lado, sin floritura",[11,154,155],{},"La tabla siguiente es la versión honesta. No hay columna sin reservas — toda herramienta de orquestación es un conjunto de tradeoffs, y HeroCtl también.",[157,158,159,175],"table",{},[160,161,162],"thead",{},[163,164,165,169,172],"tr",{},[166,167,168],"th",{},"Criterio",[166,170,171],{},"Coolify",[166,173,174],{},"HeroCtl",[176,177,178,189,200,211,222,233,244,255,266,276,287,297],"tbody",{},[163,179,180,184,187],{},[181,182,183],"td",{},"Tiempo de instalación",[181,185,186],{},"5 minutos",[181,188,186],{},[163,190,191,194,197],{},[181,192,193],{},"Panel web",[181,195,196],{},"Sí, central",[181,198,199],{},"Sí, embebido en todos los servidores",[163,201,202,205,208],{},[181,203,204],{},"Certificados automáticos",[181,206,207],{},"Sí (en la máquina principal)",[181,209,210],{},"Sí, replicados entre servidores",[163,212,213,216,219],{},[181,214,215],{},"Multi-servidor",[181,217,218],{},"Sí, como destinos de deploy",[181,220,221],{},"Sí, como cluster de plano de control",[163,223,224,227,230],{},[181,225,226],{},"Alta disponibilidad real",[181,228,229],{},"No — panel es punto único de fallo",[181,231,232],{},"Sí — sobrevive a la pérdida de servidores",[163,234,235,238,241],{},[181,236,237],{},"Elección de coordinador",[181,239,240],{},"No aplicable",[181,242,243],{},"Sí, ~7s tras caída",[163,245,246,249,252],{},[181,247,248],{},"Criptografía entre servicios",[181,250,251],{},"No embebida",[181,253,254],{},"Embebida",[163,256,257,260,263],{},[181,258,259],{},"Métricas persistentes",[181,261,262],{},"Plugin\u002Fintegración externa",[181,264,265],{},"Job interno",[163,267,268,271,273],{},[181,269,270],{},"Logs centralizados",[181,272,262],{},[181,274,275],{},"Escritor único embebido",[163,277,278,281,284],{},[181,279,280],{},"Modelo comercial",[181,282,283],{},"Open-source con nube paga opcional",[181,285,286],{},"Plan gratuito permanente + Business\u002FEnterprise pagados",[163,288,289,292,295],{},[181,290,291],{},"Equipo mínimo para operar",[181,293,294],{},"1 dev part-time",[181,296,294],{},[163,298,299,302,305],{},[181,300,301],{},"Franja de aplicación ideal",[181,303,304],{},"1 servidor (hasta 3 con remote servers)",[181,306,307],{},"3 a 500 servidores",[11,309,310],{},"La línea que más importa para esta conversación es la quinta — alta disponibilidad real. Las demás son consecuencias de ella. Sin consenso entre servidores, no se puede tener panel resiliente. Sin panel resiliente, no se puede prometer SLA. Sin SLA, algunos clientes no cierran contrato.",[11,312,313],{},"La última línea también merece atención. Coolify es increíble con un servidor. HeroCtl es increíble con tres a quinientos. No son productos de la misma franja — son productos que cubren franjas adyacentes del mismo problema.",[18,315,317],{"id":316},"cuando-quedarse-en-coolify","Cuándo quedarse en Coolify",[11,319,320],{},"Esta sección existe porque la honestidad es el mecanismo de defensa de una herramienta nueva. Si decimos \"todo el mundo debería usar HeroCtl\", estamos errando. Hay cinco perfiles en los que recomendamos firmemente continuar en Coolify.",[11,322,323,327],{},[324,325,326],"strong",{},"Tienes un solo servidor y no pretendes tener más.","\nSi tu arquitectura cabe entera en una VPS de 4 u 8 GB de RAM, y tu modelo de negocio no exige SLA contractual, Coolify es la respuesta correcta. HeroCtl ejecutándose en un servidor único funciona, pero estás pagando el overhead de una capa de coordinación que nunca va a necesitar coordinar con nadie. Es como comprar un coche de cinco plazas para hacer solo viajes solo — no está mal, solo es innecesario.",[11,329,330,333],{},[324,331,332],{},"Estás ejecutando aplicaciones internas o de desarrollo.","\nEntornos de staging, dashboards internos, herramientas que solo usa tu equipo, side-projects experimentales — todos esos casos no justifican multiplicar servidores. Una caída de dos horas en un staging no cuesta nada más allá de la molestia. Coolify entrega el mejor coste-beneficio para ese tipo de workload, y lo recomendamos abiertamente.",[11,335,336,339],{},[324,337,338],{},"Eres hobby developer.","\nProyectos personales, blogs, portfolios, experimentos con APIs nuevas — quédate en Coolify. El coste mental de operar un cluster de tres servidores es mayor que la ganancia percibida. Quieres publicar cosa, no administrar infraestructura. Coolify fue diseñado para ese perfil. No vamos a intentar empujar una herramienta con más ceremonia operacional de la que el caso pide.",[11,341,342,345],{},[324,343,344],{},"Tienes dependencia fuerte de plugins del ecosistema Coolify.","\nSi tu flujo depende de tres plugins específicos de Coolify para integrar con servicios terceros que aún no tenemos integración nativa, migrar ahora es prematuro. Espera a que HeroCtl madure esas integraciones o evalúa si la integración específica vale el trabajo de reescribir. Preferimos que esperes a que la integración exista que migrar y descubrir un agujero a mitad de camino.",[11,347,348,351],{},[324,349,350],{},"No estás sintiendo dolor.","\nEse es el criterio más importante y el más subestimado. Si Coolify nunca falló para ti, si tu máquina principal tiene tres años de uptime, si ningún cliente tuyo ya cobró SLA — no migres por moda. Migración de herramienta de orquestación tiene coste real (una a dos semanas de un ingeniero senior, más ajustes). Paga ese coste solo cuando el dolor lo justifique. Migrar antes de sentir dolor es una forma elegante de quemar tiempo de ingeniería que podría estar volviéndose producto.",[11,353,354],{},"La regla mental simple: si la frase \"si esa máquina se cae a las tres de la mañana, tengo problema serio con cliente\" describe tu situación, es hora de evaluar. Si la frase \"si esa máquina se cae a las tres de la mañana, me despierto mañana, reenciendo, y todo sigue\" describe, quédate donde estás.",[18,356,358],{"id":357},"como-migrar-cuando-tiene-sentido","Cómo migrar cuando tiene sentido",[11,360,361],{},"La migración no necesita ser un big bang. El camino que recomendamos es gradual, en cuatro etapas, y mantiene Coolify funcionando todo el tiempo.",[11,363,364,367],{},[324,365,366],{},"Etapa 1 — Subir el cluster HeroCtl en paralelo."," Tres servidores nuevos, en la misma región, sin tocar el Coolify existente. Corre el instalador en cada uno, los junta en el cluster, abre el panel. Validación básica: el panel responde en los tres IPs, certificado de prueba es emitido, un contenedor \"hello world\" sube y responde. Tiempo medio: una tarde.",[11,369,370,373],{},[324,371,372],{},"Etapa 2 — Migrar una aplicación de bajo riesgo."," Elige una aplicación interna o de bajísimo tráfico. Algo que, si queda fuera por diez minutos, no causa pánico. Reescribe el archivo de configuración en el formato de HeroCtl (en general, cincuenta líneas sustituyen lo que era un conjunto de campos en el panel de Coolify). Súbela en el cluster nuevo. Apunta un subdominio de prueba. Valida por una semana.",[11,375,376,379],{},[324,377,378],{},"Etapa 3 — Migrar workloads con tráfico real, una a la vez."," Para cada aplicación migrada, haz blue-green: sube la versión en HeroCtl, apunta el DNS a HeroCtl, mantén Coolify ejecutando la versión antigua por 24 a 72 horas como fallback. Si algo sale mal, rollback es cambiar el DNS de vuelta. Cuando todo se estabilice, apaga la aplicación en Coolify.",[11,381,382,385],{},[324,383,384],{},"Etapa 4 — Apagar Coolify."," Cuando todas las aplicaciones migraron y se estabilizaron por una semana o dos, apaga la máquina del Coolify. Mantén el backup de la base del Coolify por un trimestre más, por garantía. Ahí sí, encierra la VPS.",[11,387,388],{},"El punto alto de ese camino es que en ningún momento te quedas sin opción de rollback. Coolify sigue ejecutándose hasta el último día. Si la migración sale mal en alguna etapa, vuelves un paso, ajustas, lo intentas de nuevo. No hay \"punto de no retorno\" forzado por arquitectura.",[11,390,391],{},"Tiempo total típico, para un portfolio de diez a veinte aplicaciones: dos a tres semanas, con un ingeniero dedicando la mitad del tiempo. Para portfolios mayores, escala linealmente.",[18,393,395],{"id":394},"preguntas-que-recibimos","Preguntas que recibimos",[11,397,398,401],{},[324,399,400],{},"Coolify deploya en N servidores también. ¿Cuál es la diferencia real?","\nCoolify deploya contenedores en N servidores. HeroCtl ejecuta el orquestador en N servidores. La diferencia es dónde vive el cerebro. En Coolify, el cerebro vive en la máquina principal — máquinas remotas son brazos. En HeroCtl, el cerebro es distribuido: tres o más servidores combinan estado por consenso, y cualquiera puede asumir el rol de coordinador si el actual se cae. Es la misma diferencia entre \"tener copias de un documento en varios ordenadores\" y \"tener un documento colaborativo en tiempo real\". Los dos tienen múltiples máquinas; solo el segundo sobrevive a la pérdida de una de ellas sin perder control.",[11,403,404,407],{},[324,405,406],{},"¿Puedo usar Coolify y HeroCtl juntos?","\nSí, y durante una migración es la recomendación. Los dos ejecutan Docker como runtime, así que no disputan recursos en el nivel del contenedor. Lo que cambia es qué orquestador mira a qué conjunto de máquinas. Técnicamente, se puede mantener aplicaciones antiguas en Coolify para siempre y usar HeroCtl solo para workloads nuevos con requisito de HA — algunos equipos eligen ese enfoque y nunca llegan a apagar Coolify. No hay acoplamiento forzado.",[11,409,410,413],{},[324,411,412],{},"¿Cuánto cuesta migrar?","\nEl coste directo es tiempo de ingeniería: dos a tres semanas de medio tiempo para un portfolio típico. El coste indirecto es la curva de aprendizaje del archivo de configuración nuevo — generalmente medio día para un ingeniero senior agarrarle la onda. No hay coste de licencia para migrar (HeroCtl Community es gratuito permanente, sin límite de servidores o de jobs), ni coste de salida del Coolify (simplemente paras de usar). El coste de oportunidad es el ingeniero no estar haciendo otra cosa en aquellas dos semanas.",[11,415,416,419],{},[324,417,418],{},"¿Qué pierdo de Coolify?","\nLa interfaz visual de Coolify es más amigable para quien nunca vio nada de orquestación — es un trade real. Algunos plugins del ecosistema Coolify aún no tienen equivalente en HeroCtl, especialmente integraciones con servicios de nicho. La comunidad de Coolify es mayor en volumen — foros tienen más respuestas para preguntas específicas. Y ciertas conveniencias de UI (templates pre-configurados para aplicaciones famosas) aún no están en la misma paridad. Esos puntos son reales y los reconocemos.",[11,421,422,425],{},[324,423,424],{},"¿Y los plugins de Coolify que uso?","\nCada uno se vuelve un análisis individual. Para integraciones con bases gestionadas (Postgres, Redis), HeroCtl ejecuta esos servicios como jobs comunes — sin necesidad de plugin específico. Para integraciones con servicios externos (envío de email, observabilidad SaaS), en general es una variable de entorno apuntando a la API del proveedor — replicable en cualquier orquestador. Para plugins muy específicos, vale escribirnos — en algunos casos, equivalente nativo ya está en el roadmap.",[11,427,428,431],{},[324,429,430],{},"Solo tengo un servidor ahora. ¿Vale la pena ya empezar con HeroCtl?","\nHonestamente: no. Si tienes un solo servidor y ninguna intención de añadir más en los próximos seis meses, Coolify es mejor para tu caso. HeroCtl ejecutándose en un único servidor funciona, pero estás pagando overhead de coordinación que no tiene con quién coordinar. La hora correcta de empezar con HeroCtl es cuando sabes que vas a tener tres o más servidores — sea porque el tráfico creció, sea porque el cliente pidió SLA, sea porque quieres dormir mejor. Antes de eso, quédate en Coolify.",[11,433,434,437],{},[324,435,436],{},"¿Cuándo salen los precios de Business y Enterprise?","\nYa están publicados en la página de planes, sin \"habla con ventas\". Business añade SSO\u002FSAML, RBAC granular, auditoría detallada, backup gestionado y soporte con SLA — para equipos con requisitos formales de plataforma. Enterprise añade escrow de código fuente, contrato de continuidad y soporte 24×7. El contrato es congelado para clientes existentes — no hay cláusula de cambio retroactivo. Community sigue gratuita permanente, sin límite de servidores, sin límite de jobs, sin feature gates artificiales. Individuos y equipos pequeños nunca necesitan salir de Community.",[11,439,440,443],{},[324,441,442],{},"¿Y si quiero volver a Coolify después de migrar?","\nPosible. Los contenedores ejecutan Docker en ambos casos — las imágenes son las mismas. Lo que cambia es el archivo de configuración y el panel. Volver significa recrear las configuraciones en Coolify y reapuntar el DNS. Nunca trancamos a nadie: el binario de HeroCtl no tiene phone-home obligatorio, no hay kill-switch remoto, y el cluster instalado sigue funcionando offline para siempre. Si tu decisión es apagar y volver, es solo apagar y volver. La libertad de salida es lo que vuelve la confianza honesta.",[18,445,447],{"id":446},"cierre","Cierre",[11,449,450],{},"La elección entre Coolify y HeroCtl no es técnica, es situacional.",[11,452,453],{},"Coolify es la respuesta correcta para una fase específica del crecimiento de un producto: solo dev, MRR inicial, un servidor, sin presión de SLA. HeroCtl es la respuesta correcta para la fase siguiente: equipo pequeño, MRR creciente, tres o más servidores, primeros contratos con SLA, primeros clientes que cobran disponibilidad. Las dos herramientas atienden perfiles adyacentes del mismo problema.",[11,455,456],{},"Si estás en la primera fase, instalas Coolify y eres feliz. Si estás entrando en la segunda fase y sientes la pared llegando, HeroCtl te encuentra del otro lado.",[11,458,459],{},"Para empezar, en cualquiera de los tres servidores Linux con Docker:",[461,462,467],"pre",{"className":463,"code":464,"language":465,"meta":466,"style":466},"language-bash shiki shiki-themes github-dark-default","curl -sSL https:\u002F\u002Fget.heroctl.com\u002Finstall.sh | sh\n","bash","",[468,469,470],"code",{"__ignoreMap":466},[471,472,475,479,483,487,491],"span",{"class":473,"line":474},"line",1,[471,476,478],{"class":477},"sQhOw","curl",[471,480,482],{"class":481},"sFSAA"," -sSL",[471,484,486],{"class":485},"s9uIt"," https:\u002F\u002Fget.heroctl.com\u002Finstall.sh",[471,488,490],{"class":489},"suJrU"," |",[471,492,493],{"class":477}," sh\n",[11,495,496,497,41],{},"La instalación corre en cinco minutos, el panel sube en cada uno de los servidores, y el cluster está listo para recibir jobs. Para más sobre por qué HeroCtl existe y qué problema intenta resolver, ",[32,498,500],{"href":499},"\u002Fes\u002Fblog\u002Fpor-que-creamos-heroctl","lee el post de fundación",[11,502,503],{},"La intención es simple: orquestación de contenedores, sin ceremonia — ahora con cluster.",[505,506,507],"style",{},"html pre.shiki code .sQhOw, html code.shiki .sQhOw{--shiki-default:#FFA657}html pre.shiki code .sFSAA, html code.shiki .sFSAA{--shiki-default:#79C0FF}html pre.shiki code .s9uIt, html code.shiki .s9uIt{--shiki-default:#A5D6FF}html pre.shiki code .suJrU, html code.shiki .suJrU{--shiki-default:#FF7B72}html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}",{"title":466,"searchDepth":509,"depth":509,"links":510},2,[511,512,513,514,515,516,517,518,519],{"id":20,"depth":509,"text":21},{"id":58,"depth":509,"text":59},{"id":93,"depth":509,"text":94},{"id":132,"depth":509,"text":133},{"id":151,"depth":509,"text":152},{"id":316,"depth":509,"text":317},{"id":357,"depth":509,"text":358},{"id":394,"depth":509,"text":395},{"id":446,"depth":509,"text":447},"comparison",null,"2026-01-13","Coolify resuelve solo dev brillantemente. Cuando el cliente pide SLA y el servidor único se vuelve punto único de fallo, la historia cambia. Comparativo honesto.",false,"md",{},true,"\u002Fes\u002Fblog\u002Fheroctl-vs-coolify","13 min",{"title":5,"description":523},{"loc":528},"es\u002Fblog\u002Fheroctl-vs-coolify",[534,535,536,537],"coolify","alta-disponibilidad","comparativo","auto-hospedado","XRlKGGGn4F19VkBpXmt7D5MAdreMx1DRju7tiPhdpnE",[540,546],{"title":541,"path":542,"stem":543,"description":544,"date":545,"category":520,"children":-1},"GitHub Actions vs GitLab CI vs Drone: qué CI\u002FCD elegir para startup","\u002Fes\u002Fblog\u002Fgithub-actions-vs-gitlab-ci-vs-drone","es\u002Fblog\u002Fgithub-actions-vs-gitlab-ci-vs-drone","GitHub Actions ganó mindshare pero tiene costes de minutos. GitLab CI es más completo pero pesa más. Drone (y Woodpecker) auto-hospedado corre en VPS pequeño. Comparación práctica.","2026-05-15",{"title":547,"path":34,"stem":548,"description":549,"date":550,"category":520,"children":-1},"HeroCtl vs Dokploy: comparativo honesto","es\u002Fblog\u002Fheroctl-vs-dokploy","Dokploy es la apuesta del segmento auto-hospedado tras el crecimiento de Coolify. Comparativo honesto: dónde se solapan, dónde divergen.","2026-01-22",1777362218275]