bedrock
Homelab de Kubernetes en metal con NixOS y Flux GitOps. Controla un cluster de tres nodos, una red privada con Cloudflare Tunnel y Tailscale, almacenamiento replicado con Longhorn y secretos cifrados.
Ficha actualizada 22 sept 2026, 21:24 · upstream 22 sept 2026, 20:55 · release sin release detectada
Qué es bedrock
Descripción editorial construida a partir del repositorio, su documentación y sus señales de mantenimiento.
bedrock es el único repositorio de verdad para un pequeño cluster local. Tres mini-PCs con NixOS y un Raspberry Pi como router/gateway/DNS se declaran en este repositorio. Todo, desde la disposición del disco hasta los workloads, está declarado. La configuración se aplica con nixos-rebuild y el estado del cluster se reconcilia con Flux v2 desde kubernetes/clusters/home, de modo que un cambio en main sea una actualización del cluster sin necesidad de comandos manuales.
El cluster ejecuta una pila de LLM auto-alojada, automatización de flujos de trabajo, monitorización y servicios auxiliares. Algunos servicios son públicos a través de Cloudflare Tunnel; los demás se acceden solo vía Tailscale o la red local. La capacidad está limitada a los tres nodos locales y nada más.
La arquitectura es zoned: el cluster y servidores están en VLAN 20 (10.20.0.0/24), un DMZ en VLAN 30 (10.30.0.0/24) para hosts no confiables, y la red firewall del router deniega tráfico DMZ hacia el cluster y la red doméstica por defecto. El acceso público nunca llega directamente a la LAN: Cloudflare termina TLS en su borde y envía solo chat, rancher y lucawalz.dev a través de un tunnel. Los servicios internos permanecen fuera de internet y se acceden vía Tailscale o la LAN mediante DNS split-horizon, donde AdGuard reescribe los nombres de host de los servicios internos.
El estado del cluster fluye en sentido inverso: una push a main es pullida por Flux que aplica las manifestos en orden dependiente. No existe ningún camino adicional para añadir capacidad más allá de los tres nodos locales. El operador horizon sigue ejecutándose y mantiene la recolección de nodos orphans, pero carece de proveedor para alquilar nuevos nodos.
La infraestructura física se compone de tres Lenovo ThinkCentre m920q en VLAN 20, con un Raspberry Pi como router/gateway/DNS. El TP-Link TL-SG108PE actúa como switch port-to-power y alimenta el Pi por puerto 2, por lo que el router funciona desde una sola conexión cableada. Se asigna un IP estática al router en la red doméstica y su mapeo de puertos se registra en ADR 0050.
NixOS no gestiona firmware de dispositivos, por lo que los parches de firmware son manuales: rpi-
- Automatización de infraestructura local con NixOS flakes declarativos
- Entornos de desarrollo reproducibles sin dependencias externas
- Laboratorios de pruebas de Kubernetes en metal sin configuración manual
- Infraestructura GitOps con Flux v2 para clusters pequeños y autónomos
- Servicios de red local seguros mediante Cloudflare Tunnel y Tailscale
- Hospedaje declarativo completo con NixOS flakes, incluyendo particionamiento de disco (disko) y secretos por host (agenix)
- Reconciliación GitOps con Flux v2 desde el repositorio como fuente única de verdad
- Acceso público restringido mediante Cloudflare Tunnel + Tailscale sin puertos abiertos hacia internet
- Almacenamiento replicado en Longhorn con tres copias por volumen, sin backups externos
- Secrets cifrados con SOPS y age, decifrados solo dentro del cluster
- No existen backups fuera de la infraestructura local (sin off-site)
- Capacidad limitada a los tres nodos físicos disponibles
- No soporte de autoscaling en el cloud tras la retirada del proveedor
- Parche de firmware manual requerido para hardware no NixOS
- Ningún build host disponible para generar el entorno aarch64 del router
Perfil de infraestructura
Estimación inicial derivada del repositorio y de los servicios detectados.
Despliegue detectado
Qué señales reales de instalación hemos encontrado.
Requisitos: Nix con flakes activados, GitHub account propietario y un tailnet Tailscale en la red local.,Instalación: se instala NixOS en cada nodo y se aplica su configuración; luego se forkan repositorios y se seeda Flux contra el fork para que reconcilie kubernetes/clusters/home desde Git.,Se debe usar --target-host y --build-host al ejecutar nixos-rebuild, nunca con sudo. El build host puede ser control-plane-1 o cualquier nodo disponible.,Flux aplica las Kustomizations en orden dependiente: cluster-sources → cluster-namespaces → cluster-bootstrap-secrets → cluster-secrets → infra (platform) → cluster-apps.,Para añadir un servicio, crear su namespace en namespaces/, listarlo y agregar un HelmRepository en sources/helm/. El namespace Traefik debe tener el label bedrock.io/traefik-routable: true para que la policy de egress lo seleccione.,Los secretos necesarios se guardan en el reposi
Stack y dependencias
Componentes inferidos a partir de manifests, configuración y documentación.
Puede sustituir a
Relaciones detectadas por el análisis del repositorio y su categoría.
Experiencia real de la comunidad
Ayuda a contrastar la estimación automática con instalaciones reales.
Todavía no hay datos comunitarios para este proyecto.