Autohospedar el stack de tu estudio en un solo servidor

TL;DR — Corremos todo el stack de nuestro estudio — gestor de contraseñas, sincronización de archivos, automatización, git, CRM, firma electrónica, facturación — en un solo servidor bien dimensionado. Un host Proxmox, una docena de VMs aisladas en una red privada, todo accesible únicamente a través de un único edge con proxy inverso detrás de un túnel de Cloudflare. El beneficio es la propiedad de los datos, un coste recurrente casi nulo y un conocimiento profundo de nuestra propia infraestructura. El precio es real: es trabajo de operaciones, y ahora el ingeniero de guardia eres tú.

La mayoría de los estudios pequeños alquilan toda su cadena de herramientas. Una suscripción para contraseñas, otra para almacenamiento de archivos, otra para automatización, otra para el CRM. Es cómodo, se cobra por asiento y, sin hacer ruido, dispersa los datos de tus clientes entre una docena de proveedores que nunca vas a auditar. Nosotros tomamos el camino contrario. Un servidor lo corre todo, los datos viven en hardware en una sala que podemos señalar con el dedo, y la factura mensual se redondea al coste de la electricidad. Esta es la arquitectura, y los compromisos contados con honestidad.

Una máquina, muchos muros

El host es una sola máquina de clase workstation — un Xeon, un buen montón de RAM, discos en espejo — corriendo Proxmox, un hipervisor que permite que una máquina física aparente ser muchas. Cada servicio tiene su propia máquina virtual o contenedor, y ese aislamiento es justamente el objetivo. Vaultwarden no comparte sistema de archivos con el CRM. El runner de CI que ejecuta pasos de build no confiables vive en su propia VM, amurallado de cualquier cosa que importe.

Esto es, a grandes rasgos, lo que corre en la máquina:

• Vaultwarden — gestor de contraseñas autohospedado (compatible con Bitwarden)
• Nextcloud — sincronización y compartición de archivos, con el grueso de los datos en un disco dedicado
• n8n — automatización de flujos, editor restringido, webhooks públicos en un hostname aparte
• Forgejo + un runner de CI — hosting git privado e integración continua
• Un CRM, un servicio de firma electrónica y facturación — la capa de negocio de cara al cliente
• Authentik — inicio de sesión único y forward-auth con MFA
• Monitorización — chequeos de uptime y métricas por host

Todo se asienta sobre una red interna privada — 10.10.10.0/24, invisible desde la internet pública. No hay nada con port-forwarding. La única entrada es a través de una sola VM edge que corre un proxy inverso, y la única manera en que ese edge habla con el mundo exterior es un túnel de Cloudflare: una conexión solo de salida, así que no hay ningún puerto entrante abierto que escanear o atacar.

El objetivo no es construir un muro impenetrable. Es asegurar que cuando algo salga mal, el radio de impacto sea un servicio — no el estudio entero.

Mínimo privilegio, en todas partes

La segmentación solo ayuda si las reglas entre segmentos son estrictas. Algunos principios que sostenemos:

Autenticación en el edge, acotada al servicio. Las superficies de administración — el panel admin de Vaultwarden, el editor de automatización — solo son accesibles por nuestra VPN mesh privada, nunca por el túnel público. Las apps de negocio van detrás de inicio de sesión único con MFA obligatorio. Los endpoints públicos reciben un allowlist explícito de rutas en el proxy; todo lo demás devuelve un 404 antes de siquiera llegar a la aplicación.

Credenciales acotadas, no root. Cuando un servicio necesita almacenamiento de objetos, recibe una credencial limitada a su propio bucket — no la clave de administrador del almacenamiento. Cuando los backups necesitan leer el disco, el token tiene exactamente un permiso: lectura para backup. El radio de impacto de un secreto filtrado debería ser un solo bucket, no toda la finca.

Los secretos viven en exactamente dos sitios. En la VM que los necesita (permisos de archivo bloqueados) y en el gestor de contraseñas. Nunca en git. Un .gitignore no protege lo que ya commiteaste, así que la regla está aguas arriba del error: los secretos no entran al repo en primer lugar.

Backups, monitorización y estar de guardia

Autohospedar sin backups no es autohospedar; es una cuenta atrás. La regla que nunca rompemos: sin backup, no hay cambio. Antes de tocar nada en producción, hay un snapshot y un dump lógico de la base de datos, y una manera escrita de revertir.

La estrategia de backup es de dos niveles. Un servidor de backup local mantiene retención completa y restauraciones rápidas. Una copia offsite separada va a almacenamiento de objetos en la nube, cifrada, para que un incendio o un robo no se lleve los datos con él. El nivel offsite es deliberadamente pequeño — guarda solo el último snapshot — porque una restauración que nunca has probado es solo una esperanza. Hemos hecho el simulacro.

Un disparador manual de una línea vive junto al cron nocturno, para cuando queremos una copia fresca antes de un cambio arriesgado:

ssh host "/root/restic-b2-backup.sh"   # snapshot offsite cifrado

La monitorización es la otra mitad. Cada host reporta métricas; los chequeos de uptime vigilan los endpoints públicos. Una capa de detección de intrusiones lee los logs del proxy y banea hosts que se portan mal. Nada de esto es exótico — es simplemente la diferencia entre enterarte de que un servicio está caído por un dashboard, en lugar de enterarte por un cliente.

Y ese es el verdadero compromiso. Alquilar tu stack significa que otra persona está de guardia a las 3 de la mañana. Ser dueño de él significa que lo estás tú. Harás actualizaciones de una versión major a la vez, con un rollback listo, porque la alternativa es descubrir un cambio incompatible un sábado. Fijarás versiones de imagen en lugar de perseguir latest. Mantendrás un runbook para cada servicio para que tu yo del futuro, o un asistente, pueda arreglarlo sin re-deducir todo desde cero.

¿Vale la pena?

Para nosotros, sí — pero el cálculo es específico. Somos un estudio de diseño y automatización; entender la infraestructura es adyacente al trabajo, no una distracción. La soberanía de los datos importa porque guardamos archivos y contactos de clientes, y preferimos no tener que explicar la brecha de un tercero. Y el coste recurrente de una docena de asientos SaaS, compuesto a lo largo de los años, da para mucho servidor.

Si facturas por hora y nunca quieres pensar en una actualización de kernel, alquila tu stack y sigue adelante. Pero si quieres de verdad entender los sistemas sobre los que corre tu negocio — y mantener los datos de tus clientes en hardware que controlas — un solo servidor llega notablemente lejos.

Para llevar: Empieza con un servicio que ya pagas, ponlo en una máquina detrás de un proxy inverso, y haz que los backups funcionen antes de migrar nada real. La arquitectura escala a partir de ahí. La disciplina — backup primero, mínimo privilegio, secretos fuera de git — es lo que la hace sostenible.