Por qué elegimos el self-hosting: dependencia, costes y control

Hubo un momento en que usábamos GitHub, Notion y Slack de pago. Hoy una parte importante de lo que sostiene nuestro trabajo corre en servidores propios.

No fue una decisión ideológica. Fue práctica, y conviene decirlo así, porque el self-hosting suele contarse como una cruzada o como una moda, y para nosotros no es ninguna de las dos. Este artículo explica el razonamiento: por qué empezamos a mirar hacia dentro y qué criterios usaríamos para decidir si te conviene a ti. Qué nos ha ido pasando desde entonces, con el mantenimiento incluido, lo contamos aparte en infraestructura propia para una pyme.

El detonante: crecer y depender

Somos una consultora técnica con más de diez proyectos simultáneos para clientes. A medida que crece la infraestructura de trabajo, crece también la factura de servicios de terceros. Y, más importante que la factura, la dependencia: plataformas que pueden cambiar precios y condiciones cuando les convenga, y que tú ya no puedes abandonar sin un coste enorme porque todo tu trabajo está dentro.

Esa palabra, dependencia, es el centro del asunto. Una cuota que sube es molesta. Un sistema donde no puedes sacar tus datos con facilidad, o cuyas reglas cambian sin que puedas opinar, es un riesgo del negocio. Para una consultora que vive de lo que construye, que el código de sus proyectos viva en el servicio de otro es una decisión que merece pensarse dos veces.

Lo que montamos para sostenerlo

El conjunto, sin entrar en detalles de cómo está conectado:

• Gitea para el control de versiones, incluidos nuestros proyectos de FileMaker.
• Headscale con Tailscale para la red privada entre máquinas, de modo que no hay que exponer nada a internet. Está explicado en Headscale y Tailscale: una VPN en malla.
• Arcane para gestionar contenedores Docker.
• Un clúster Proxmox de tres nodos como servidor central, con copias automáticas.
• Zabbix para la monitorización.

Gitea es un buen ejemplo del criterio: es un servicio de control de versiones ligero y de código abierto, muy fácil de alojar, que cubre lo que necesitamos sin que el código de nuestros clientes viva en una plataforma ajena.

Qué ganamos

• Control total sobre los datos. Sabemos dónde están y quién llega a ellos.
• Sin sorpresas en la factura. Los costes pasan a ser sobre todo de hardware y de nuestro tiempo, previsibles en lugar de variables.
• La capacidad de conectarlo todo entre sí. Al ser nuestro, podemos enlazar las piezas mediante servidores MCP, el protocolo que permite que una herramienta de IA acceda de forma controlada a otras. Hemos hablado de ello en MCP, el puente entre la IA y tus herramientas. Si cada pieza vive en un servicio cerrado, esa integración depende de lo que ese servicio permita.

Qué cuesta

Tiempo de mantenimiento. No es un matiz: es el precio. Actualizar, vigilar, documentar y reaccionar cuando algo se rompe es trabajo continuo, y alguien tiene que hacerlo. Por eso vigilamos con avisos y probamos que las copias se restauran, como explicamos en copias, monitorización y nube para una pyme.

Lo que no alojamos

Self-hosting no quiere decir alojarlo todo, y nosotros tampoco lo hacemos. Seguimos usando Slack, porque es donde hablamos y no nos aporta nada tenerlo en casa. Y seguimos usando GitHub para lo que lo necesita: las aportaciones a proyectos de código abierto, que viven allí, y algunos proyectos que dependen de él, como el editor con el que publicamos esta misma web.

La regla que aplicamos es sencilla. Lo que se despliega y funciona dentro de nuestra red va a nuestro Gitea. Lo que tiene que estar fuera, porque es público o porque una herramienta lo exige, va donde haga falta. El remoto se elige por lo que necesita cada proyecto, no por principio. Lo que no negociamos es que el núcleo, el código de los clientes y lo que sostiene nuestro día a día, no dependa de las condiciones de otro.

Para quién tiene sentido y para quién no

No es para todos. Para una consultora técnica como la nuestra, con gente que sabe y quiere llevar sus propios sistemas, tiene sentido completo. Para otras empresas, lo razonable es hacerse tres preguntas antes de empezar:

1. ¿Hay alguien dentro con capacidad y ganas de mantenerlo, de forma sostenida y no solo el primer mes?
2. ¿Qué pasa si esa persona no está? Si la respuesta es que nadie sabe cómo funciona, aún no está listo.
3. ¿Qué parte de lo que usas es realmente crítica? No hace falta alojar todo. Se puede empezar por lo que más te duele que dependa de otro (en nuestro caso, el código) y dejar lo demás en servicios gestionados.

Y si la respuesta a las dos primeras es no, apoyarse en un proveedor es la decisión sensata. Un servicio gestionado bien elegido es mejor que una infraestructura propia mal mantenida.

Lo que nos llevamos

Elegimos el self-hosting por una razón práctica: no queríamos que el núcleo de nuestro trabajo dependiera de las condiciones de otros. Nos da control y previsibilidad, y nos cuesta tiempo. Si ese intercambio te sale a cuenta depende de tu equipo, no de la herramienta.

Si estás valorando qué conviene tener en casa y qué dejar en manos de un proveedor, en sistemas y cloud explicamos cómo lo planteamos, y puedes contarnos tu caso en contacto.