Managed hosting vs self hosting exige contar el trabajo

Veinte herramientas pequeñas rara vez necesitan mucha capacidad de cómputo. Sí crean veinte ocasiones para que caduque un certificado, falle una copia sin avisar, una actualización rompa el acceso o una alerta no llegue a nadie. Por eso, comparar solo la factura mensual del servidor da una respuesta equivocada.

Para una cartera de este tamaño, el hosting gestionado suele costar menos cuando se valora el tiempo del personal y las interrupciones. El alojamiento propio puede ganar si las herramientas comparten una plataforma ordenada, el equipo ya la opera y el control o la ubicación de los datos justifican el trabajo. La decisión necesita un modelo de coste total, no una captura de dos páginas de precios.

Compara un servicio operativo, no una máquina virtual

La unidad justa es un servicio al que los usuarios pueden entrar y que alguien puede recuperar, no una máquina virtual con memoria suficiente para arrancar el código. Un servidor barato excluye gran parte de lo que mantiene útil una aplicación después del despliegue.

Define el mismo límite para ambas opciones. Incluye ejecución, base de datos, archivos persistentes, DNS, terminación TLS, secretos, registros, métricas, alertas, almacenamiento de copias, recuperación, despliegue, reversión, actualizaciones de seguridad y una persona que responda. Si el plan gestionado incluye algo, anótalo. Si te lo delega, añádelo también al lado propio.

Se suelen confundir la gestión de infraestructura y la propiedad de la aplicación. El proveedor puede parchear el host y sustituir hardware, pero no decide si la migración de ayer perdió una columna o si una autorización generada por IA está mal. El alojamiento propio amplía tu responsabilidad al sistema operativo, red, base de datos y supervisión. No elimina el trabajo de aplicación.

El modelo de responsabilidad compartida de AWS marca el mismo límite: en infraestructura, el cliente gestiona el sistema invitado, sus parches, el software y el cortafuegos. Alquilar una máquina virtual a un gran proveedor no convierte la aplicación en gestionada. Solo deja la capa física en sus manos.

Empieza con una tabla de responsables. En cada fila escribe una persona o proveedor y la respuesta prometida. Una fila que diga «automático» está incompleta hasta saber quién detecta que la automatización se detuvo.

La tabla evita comparar un servicio completo con un servidor vacío. También descubre planes que parecen completos pero dejan la recuperación o la respuesta fuera de horario al cliente.

Usa un modelo que cobre las interrupciones

Un modelo útil separa efectivo recurrente, trabajo previsto e imprevistos. Mezclarlos en una cifra mensual optimista oculta la parte más variable.

Usa este cálculo para cada opción:

Annual cost = 12 x recurring monthly cash
            + planned engineering hours x loaded hourly rate
            + expected incident hours x loaded hourly rate
            + expected outage impact
            + one-time migration or platform work amortized over its useful life

El efectivo incluye cómputo, bases de datos, almacenamiento, copias, salida de red, supervisión, retención de registros, DNS, certificados de pago y soporte. El trabajo previsto incluye lanzamientos, parches, revisión de copias, pruebas de restauración, accesos, dependencias, capacidad y documentación. Las horas de incidente abarcan diagnóstico, reparación, recuperación, comunicación y prevención de recaídas.

Usa el coste laboral completo, no el salario neto. Debe incluir sueldo o contrato y gastos reales. Si el fundador trabaja de noche, el coste no es cero: vale el trabajo de producto, ventas o clientes que desplaza. El trabajo «gratis» es donde mienten las hojas de cálculo de alojamiento propio.

No finjas una previsión exacta de incidentes. Modela tres casos: tranquilo, esperado y malo. El tranquilo tiene mantenimiento y un fallo menor. El esperado incluye un despliegue fallido, una restauración, alertas ruidosas y varias actualizaciones urgentes. El malo contempla recuperación prolongada o credenciales comprometidas. El rango dice más que una cifra pulida.

Son ejemplos, no referencias universales. Sustitúyelos por tu frecuencia de despliegue, historial de guardias, objetivo de recuperación y tarifa interna. Sin historial, conserva un rango amplio y revísalo en tres meses.

Añade costes fijos. Construir una plataforma reutilizable puede exigir mucho trabajo una vez y servir después a muchas aplicaciones. Reparte el coste entre las aplicaciones y el periodo de uso. No lo cargues entero a la primera herramienta ni lo hagas desaparecer de las veinte.

Veinte herramientas multiplican superficies antes que cómputo

Las aplicaciones pequeñas consolidan bien CPU y memoria, pero sus superficies operativas no bajan al mismo ritmo. Un servidor puede ejecutar veinte contenedores y cada herramienta conservar dominio, secretos, usuarios, esquema, calendario, dependencias y objetivos de recuperación.

Ahí cambia la economía. Una tarea manual de seis minutos por aplicación consume dos horas en la cartera antes de investigar fallos. Una revisión trimestral suma ocho horas al año. Con coordinación, ejecuciones fallidas y documentación, deja de ser trivial.

Consolidar baja el gasto y amplía el radio de fallo. Un parche del kernel, disco lleno, proxy roto o credencial perdida puede parar las veinte. Separarlas reduce ese fallo común pero eleva facturas y parches. Una plataforma gestionada reparte este trabajo entre clientes; un equipo propio diseña y paga su equilibrio.

Agrupa por clases: prototipos desechables, herramientas internas con datos reproducibles, sistemas de negocio con datos oficiales y servicios públicos. Cada clase recibe entorno, copia, supervisión, recuperación y retirada estándar. Una herramienta cambia solo cuando cambia su riesgo.

Una máquina virtual por herramienta es popular porque el aislamiento se explica fácil. Para veinte herramientas pequeñas suele ser un mal valor inicial: duplica parches, agentes, certificados, configuración y capacidad ociosa. Reserva aislamiento fuerte para dependencias incompatibles, cargas sensibles u objetivos distintos. Para el resto encajan contenedores o una plataforma común.

El extremo opuesto, meter todo en un archivo compose sin documentar, también ahorra en falso. Necesitas límites, volúmenes persistentes con nombre, comprobaciones de salud, rutas previsibles y propiedad de datos. Si no, una exportación llena el disco y convierte un fallo menor en una caída de toda la cartera.

Cuenta también las herramientas retiradas. La IA abarata su creación y acumula experimentos abandonados. Un inventario mensual debe encontrar servicios sin dueño, usuarios o despliegues recientes. Borrarlos reduce mejor la superficie de ataque y el trabajo que ahorrar céntimos afinando contenedores.

Las copias cuestan poco hasta que toca restaurar

Una copia es recuperable y tiene un camino probado de vuelta al servicio. Un trabajo programado que sube archivos solo prueba que se ejecutó un comando.

Escribe objetivos de pérdida y tiempo en lenguaje normal. «Podemos perder un día laborable de cambios y volver en cuatro horas» basta para diseñar. Un formulario que reenvía datos tolera otra ventana que un CRM con el registro oficial.

Hay cuatro costes: crear copias, almacenarlas, guardar historial suficiente y probar la restauración. El cuarto suele dominar el trabajo. La prueba requiere destino limpio, credenciales, descarga, arranque, comprobaciones y una decisión sobre el estado recuperado.

La documentación de PostgreSQL distingue pg_dump, que restaura objetos y datos lógicos, de la archivación continua, que combina copia base y archivos WAL para recuperar un momento. También advierte que la secuencia WAL debe estar completa desde la copia base. Llamar «copia diaria» a ambos oculta capacidades distintas.

Para bases pequeñas, un volcado cifrado puede bastar si se acepta perder un día. Guarda varias generaciones fuera del host, anota quién posee la clave y restaura de verdad. Si necesitas volver justo antes de un borrado, usa una base gestionada con esa función u opera bien el archivo WAL. Una carpeta de volcados nocturnos no cumple esa promesa.

service: inventory-tool
backup_object: inventory-tool/2026-07-12T020000Z.dump
restore_started: 09:14 UTC
restore_finished: 09:31 UTC
application_check: login, search, create and delete test record passed
recovery_point: 02:00 UTC
operator: initials

Este formato deja constancia de la copia y de lo comprobado. Guárdalo con la documentación operativa, no solo dentro de la supervisión que puede faltar durante el fallo.

Revisa también las copias gestionadas: retención, región, cifrado, exportación, borrado y si restaurar crea otra base o sobrescribe la actual. Confirma si las instantáneas incluyen archivos y secretos. La plataforma ahorra mecánica, pero el cliente aún elige la política y verifica una restauración real.

SSL y supervisión son automatización con dueño

Los certificados TLS pueden ser gratuitos y generar trabajo. DNS debe apuntar bien, los retos deben pasar, el proxy debe cargar el material renovado y una alerta debe llegar antes de caducar.

Let's Encrypt explica que sus plazos cortos buscaban impulsar la automatización. Tiene sentido, pero «usamos Let's Encrypt» no es un procedimiento. Debe nombrar cliente ACME, calendario, tipo de reto, permisos DNS, recarga, alerta y responsable del fallo.

Con veinte dominios, la gestión manual es indefendible. Automatiza emisión y renovación, y comprueba el resultado desde fuera. Así detectas un certificado renovado en disco que el proxy no cargó, además de DNS roto o servidor caído.

Prometheus recomienda alertar por síntomas ligados al dolor del usuario y evitar avisos sin acción. En una cartera pequeña, copiar alertas de CPU, memoria, contenedor, base y proxy puede producir cientos de mensajes sin decir si alguien está bloqueado.

Empieza con disponibilidad externa, errores, latencia, capacidad de disco, frescura de copias y caducidad del certificado. Despierta a una persona solo cuando deba actuar pronto. Lleva capacidad y mantenimiento a horario laboral. Cada aviso necesita dueño, diagnóstico breve y forma de silenciarlo.

Supervisa al supervisor. Si todas las pruebas viven en el host, su caída elimina la alarma. Al menos una comprobación y su canal deben estar fuera del dominio de fallo. Comprueba si la plataforma gestionada prueba la ruta real de tu aplicación y si sus avisos sirven a tu respuesta.

Incluye la retención de registros. Veinte herramientas generadas por chat pueden emitir peticiones verbosas, avisos y trazas repetidas. Retén según uso, filtra secretos y datos personales. Retención ilimitada cuesta y arriesga; ninguna retención alarga el primer incidente.

El código generado se convierte en código propio al actualizarlo

Desplegar software generado por IA transfiere su mantenimiento al operador. El modelo no parchea paquetes, prueba el entorno ni explica una dependencia que desaparece meses después.

Cuenta cada capa que posees: sistema, imagen base, lenguaje, framework, paquetes, base de datos, proxy, supervisión y despliegue. Una plataforma gestionada puede quitar host y entorno de la cola, no las dependencias. Exportar código permite salir, pero el código no se opera solo.

Define un contrato de compilación: dependencias bloqueadas, pocas pruebas automáticas, endpoint de salud, migraciones explícitas y una versión anterior conocida. Sin él, cada actualización exige excavar en código generado.

Reserva una ventana recurrente. Agrupa actualizaciones de bajo riesgo, reconstruye imágenes, despliega una herramienta representativa y recorre su clase. Los arreglos de seguridad van más rápido. Mantén una vista de entornos y paquetes sin soporte para ver deuda antes de la urgencia.

Instantáneas y reversión acortan la recuperación, pero no sustituyen el plan de base de datos. Volver al código anterior tras una migración destructiva puede enfrentar código viejo a esquema nuevo. Haz cambios compatibles: añade campo, despliega código para ambos estados, migra datos y retira después el campo antiguo.

El modo de planificación permite revisar alcance, datos y componentes antes de cambiar una aplicación generada. Koder.ai combina planificación, despliegue, hosting, dominios, instantáneas y reversión, y conserva la exportación del código como salida. Aun así, el modelo necesita una partida de mantenimiento porque ninguna opción elimina la responsabilidad sobre lo publicado.

Un comando de despliegue correcto no completa una actualización. Prueba acceso, una lectura, una escritura, tareas de fondo y la función afectada. Cinco comprobaciones concretas superan una suite verde sin dueño.

Los incidentes facturan en el peor momento

El coste incluye la interrupción, no solo los minutos con comandos. Una herramienta interna puede bloquear finanzas, retrasar a veinte personas u obligar a usar hojas propensas a errores. Una aplicación pública genera soporte aunque no facture.

Imagina un fallo propio: una exportación escribe archivos enormes; la alerta del disco llega a un buzón viejo; el disco se llena de noche; PostgreSQL y otros contenedores dejan de escribir. Por la mañana se libera espacio, se reinicia y aparece un archivo incompleto. El volcado nocturno existe, pero nadie lo restauró en nueve meses y la clave pertenecía a un contratista que se fue.

La factura del servidor casi no cambia. Cuestan el diagnóstico entre capas, la duda sobre la copia, el tiempo del personal, la recuperación, mensajes y correcciones. El hosting gestionado puede evitar parte del disco y base según el alcance. No corrige una mala exportación ni habla con usuarios.

Asigna roles: quién recibe alertas fuera de horario, cuánto tarda, quién puede cambiar DNS, restaurar, rotar secretos y comunicar estado, y qué pasa en vacaciones. Si es «el desarrollador», confirma acceso, documentación y tiempo pagado.

Veinte herramientas no siempre justifican guardia continua, pero sí una ventana de servicio. Algunas internas pueden esperar al siguiente día. Dilo y configura avisos. Reserva urgencia para lo que realmente la necesita.

Carga a cada opción las correcciones posteriores. Si el alojamiento propio repite limpiezas, certificados o mantenimiento del monitor, esas horas son parte del precio. Si el proveedor causa despliegues rotos o soporte lento, cuéntalo allí. El modelo debe recordar el dolor.

El alojamiento propio gana con plataforma compartida y motivo

Puede costar menos si ya existe una plataforma mantenida, capacidad operativa libre y requisitos que un producto gestionado no satisface bien. Rara vez gana solo porque una máquina es barata.

El plan creíble tiene plantillas, despliegue automático, secretos centrales, supervisión externa, TLS automático, copias separadas, restauraciones probadas, dueño de parches, límites y retirada documentada. Si cada herramienta necesita un diagrama nuevo, la plataforma no amortiza su coste.

Residencia, aislamiento, entornos inusuales, carga alta previsible o un límite de cumplimiento pueden justificar control. Pon valor o requisito obligatorio junto a él. «Preferimos control» no se puede comparar con una factura.

El hosting gestionado es el valor inicial más fuerte para equipos pequeños, uso irregular, creación frecuente o falta de responsable. Convierte trabajo incierto en suscripción visible. Antes de considerarlo completo, revisa límites, copias, registros, regiones, dominios, reversión, exportación y soporte.

self_hosting_saving = managed_annual_cash - self_hosted_annual_cash
hours_available = self_hosting_saving / loaded_hourly_rate

Si ahorra 6.000 dólares y la hora cuesta 100, compra 60 horas al año, cinco al mes para veinte herramientas. Ahí deben caber parches, monitorización, copias, pruebas, fallos e incidentes. La cuenta no elige, pero muestra un plan imposible.

Duplica las horas de incidente, añade un segundo operador o exige recuperación puntual en tres herramientas. Si un cambio pequeño invierte el resultado, decide por tolerancia al riesgo y control, no por una ventaja de coste supuestamente estable.

Decide con una prueba operativa de 90 días

La decisión más defendible usa trabajo medido en tu cartera. Opera 90 días un grupo representativo, registra dinero y tareas, y proyecta a veinte herramientas.

Incluye un prototipo desechable, una herramienta interna con base y una aplicación externa. Despliega cambios, renueva certificados, restaura en limpio, revierte una versión, rota un secreto, dispara una alerta y retira una herramienta. Medir solo tiempo tranquilo no sirve.

Separa tiempo activo y espera. Puedes hacer otra cosa durante una descarga, pero una interrupción de quince minutos también cuesta cambio de contexto. Usa la misma regla para ambas opciones.

En el día 90 anualiza lo recurrente, separa el inicio y compara los tres casos. Marca como desconocida cualquier responsabilidad no probada, como recuperación DNS, ubicación regional o escalado de soporte.

Para la mayoría de equipos, el cómputo será el número menos interesante. El hosting gestionado gana si su sobrecoste compra más tiempo del que consume la responsabilidad restante. El propio gana si una plataforma reutilizada mantiene el trabajo bajo el punto de equilibrio y el control tiene un propósito nombrado.

No apruebes el plan aparentemente barato hasta que alguien firme restauraciones, parches, alertas e incidentes. Los servidores son mercancía. La responsabilidad fiable es el recurso escaso.