Detrás de esto hay una sola persona.
Empezó con un par de portátiles que nunca apagaba, y una factura de AWS que no podía justificar.
Desde entonces, básicamente todo ha sido aprender a las malas.
Esto empezó en un dormitorio, no en una sala de servidores: un portátil que se quedaba encendido todo el tiempo, con el ventilador zumbando bajo una lámpara de escritorio. Algunas noches lo reiniciaba en Windows para algo que no tenía nada que ver, y lo que estuviera corriendo en él simplemente se paraba — sin aviso, me daba cuenta más tarde. No había presupuesto ni un plan real, solo tozudez y una larga racha de malas decisiones que poco a poco fueron mejorando. Las preguntas de abajo son la versión honesta de cómo eso se convirtió en lo que estás viendo ahora.
¿En qué estabas pensando cuando empezaste a construir Albgott?
Sobre todo, lo que ya tenía por casa. La primera versión eran un par de portátiles que nunca apagaba — uno de ellos con arranque dual a Windows, así que cada vez que lo necesitaba para otra cosa, lo que estuviera corriendo en él se caía con él. Lo que realmente me empujó a arreglarlo fue una factura de AWS de unos 300 € por máquinas que había dejado encendidas y olvidadas, además de estar cansado de depender de Google Drive, de un Jenkins alojado por otra persona, y de cualquier otro SaaS que no controlaba. Así que empecé a construir el mío propio — mal al principio, un poco mejor cada vez que aprendía algo. Nunca hubo un plan maestro. He tirado todo abajo y lo he reconstruido más de una vez, cada vez sobre una base más sólida.
¿Por qué no usar simplemente AWS, o cualquier proveedor cloud?
Lo hice, hasta esa factura. Desplegar un container en una plataforma gestionada es la parte fácil — cualquiera puede hacerlo en una tarde. Diseñar los segmentos de red, escribir las reglas del firewall, ser quien recibe la alerta a las 3 de la madrugada cuando algo se rompe — esa es la parte que una plataforma gestionada hace por ti en silencio, y también la parte que realmente quería aprender.
¿No es esto excesivo para una sola persona?
Sí, probablemente. Ocho segmentos de red aislados, tres nodos, observability completa, su propio pipeline de CI, todo para los side projects y el trabajo de cliente de una sola persona. Podría llevarlo todo en un único VPS. No lo hago, porque el objetivo es demostrar que puedo operar esto como lo haría un equipo de verdad, no que lo necesite.
¿Qué es lo peor que se ha roto?
Sobre todo los primeros años. Mi ISP nunca me dio una IP estática, así que durante un tiempo la actualizaba a mano en media docena de sitios cada vez que cambiaba, hasta que finalmente configuré DDNS y dejé de hacerlo manualmente. Peor todavía: mi servidor DNS se cayó una vez, y me enteré porque un cliente llamó para preguntar por qué su web no funcionaba — no por ningún dashboard mío. Eso me llevó a montar un segundo servidor DNS por redundancia, y me enseñó a no confiar en un sistema del que no puedo ver el interior.
¿Cómo sabes ahora, de verdad, cuándo algo va mal?
Durante mucho tiempo, mirando. Revisaba a mano un puñado de dashboards y esperaba que nada se hubiera muerto en silencio desde la última vez, y si algo se rompía, muchas veces ni siquiera recordaba por dónde empezar, porque nada estaba escrito. Los dos problemas se arreglaron de la misma forma, aunque más despacio de lo que deberían: las alertas ahora van directas a Telegram, y cada servicio tiene documentación interna que se actualiza el mismo día que la toco, no en algún momento indefinido.
¿Por qué hacer pública alguna parte de esto?
Porque un homelab privado no le demuestra nada a nadie más que a mí. En cuanto los diagramas de red, el roadmap y las carencias reales quedaron a la vista de todos, ya no podía seguir ignorando en silencio lo que tenía sin terminar. Es sobre todo presión autoimpuesta — prefiero pasar vergüenza en público por una estrategia de backup sin terminar que fingir que no existe.
¿Qué decisión temprana tomarías completamente distinta hoy?
No segmentar la red desde el primer día. Al principio todo vivía en el mismo broadcast domain, porque dividirlo parecía excesivo para un proyecto sin usuarios. No era excesivo — solo significó que cada cambio posterior tenía que empezar deshaciendo una decisión que había tomado en una tarde sin pensarlo demasiado.
¿Entonces ya está? ¿Albgott ha terminado de evolucionar?
Ni de lejos. Los backups son más escasos de lo que me gustaría, buena parte de la configuración sigue siendo manual en vez de automatizada, y lo siguiente es un NAS — no para más almacenamiento, sino para tener copias de backup reales del servidor y almacenamiento compartido entre nodos, el tipo de redundancia que realmente hace las cosas más fiables, no solo más grandes. También llevo tiempo queriendo correr IA en local — nada sofisticado, solo algo lo bastante privado como para no tener que mandar mis datos a través de la API de otro para probarlo. La versión aburrida y concreta de esta lista vive en el roadmap →. Siendo realistas, probablemente lo más interesante de todo esto todavía está por llegar.
¿TIENES ALGO QUE TIENE QUE FUNCIONAR?
Si trabajas en infraestructura, plataformas o servicios donde la fiabilidad importa más allá del primer día, nos gustaría saber qué estás construyendo.