GitOps en tu NAS: monta CI/CD como en producción y úsalo para aprender

En este artículo te muestro cómo montar un pipeline GitOps completo en tu NAS o Mini PC: desde que haces git push hasta que tu aplicación está corriendo en producción homelab, sin tocar ni un solo servidor manualmente. Lo mejor: todo lo que aprendas aquí es 100% transferible a entornos enterprise. Tu homelab como laboratorio profesional.

¿Qué es GitOps y por qué debería importarte?

GitOps es la evolución lógica de la infraestructura como código. La idea es simple pero revolucionaria: tu repositorio Git es la única fuente de verdad. No hay scripts de deploy, no hay conexiones SSH manuales, no hay «funciona en mi máquina». Si está en Git, se despliega automáticamente. Si no está en Git, no existe.

El flujo funciona así: tú haces push de tu código, el sistema de CI (Continuous Integration) lo compila y testea, y el sistema de CD (Continuous Deployment) sincroniza automáticamente el estado deseado (lo que hay en Git) con el estado real (lo que hay corriendo en tus servidores). Si algo falla, hay rollback automático al estado anterior.

Para desarrolladores, esto cambia todo: reduces el tiempo entre escribir código y verlo funcionando de horas a minutos, eliminas errores humanos en deploys, y ganas trazabilidad completa (quién cambió qué y cuándo). En producción enterprise, esto se paga solo. En tu homelab, te convierte en el tipo de profesional que las empresas quieren contratar.

Stack recomendado para homelab: ligero, potente y 100% open source

No necesitas un datacenter. Este stack está diseñado para correr en un NAS modesto o un Mini PC, consumiendo menos recursos que un navegador con 10 pestañas abiertas:

Nota sobre las specs: Los requisitos de k3s están verificados en la documentación oficial de Rancher (docs.k3s.io). Para Gitea, al ser una aplicación Go compilada, los requisitos son mínimos; el consumo real depende del número de repositorios y usuarios activos. ArgoCD se ejecuta dentro de Kubernetes y sus requisitos se distribuyen entre los recursos del cluster.

¿Por qué este stack específicamente?

Gitea es GitHub autoalojado sin la complejidad de GitLab. En una sola imagen Docker tienes repositorios Git, pull requests, issues, wiki y desde la versión 1.19, CI/CD integrado compatible con GitHub Actions. Para equipos pequeños y homelabs, es la opción más eficiente.

Gitea Actions usa el mismo formato YAML que GitHub Actions. Esto significa que puedes copiar workflows directamente de repositorios públicos y funcionarán. El runner (act_runner) se conecta a tu instancia Gitea y ejecuta los jobs en contenedores Docker aislados.

ArgoCD es el estándar de facto para GitOps en Kubernetes. Se instala en el cluster y monitoriza continuamente tus repositorios Git. Cuando detecta diferencias entre lo declarado y lo desplegado, las corrige automáticamente. Tiene una UI web excelente para visualizar el estado de tus aplicaciones.

k3s es Kubernetes distribuido por Rancher, diseñado específicamente para entornos con recursos limitados. Un binario de 100MB que incluye todo lo necesario: containerd, Flannel (CNI), CoreDNS, traefik (ingress), y kubectl. Consume menos de 500MB de RAM en reposo.

Caso de uso real: de push a producción en 5 minutos

Veamos el flujo completo con una aplicación web sencilla (una API en Node.js):

Paso 1: Estructura del repositorio

Tu repositorio en Gitea tiene dos directorios clave:

mi-api/
├── src/                    # Código fuente
├── Dockerfile             # Imagen de la aplicación
├── .gitea/workflows/      # CI/CD de Gitea
│   └── build.yaml
└── k8s/                   # Manifiestos Kubernetes
    ├── deployment.yaml
    └── service.yaml

Paso 2: El workflow de CI (build.yaml)

Cuando haces push a la rama main, Gitea Actions ejecuta este workflow:

name: Build and Push
on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build Docker image
        run: docker build -t mi-api:${{ github.sha }} .
      - name: Push to registry
        run: |
          docker tag mi-api:${{ github.sha }} registry.homelab/mi-api:${{ github.sha }}
          docker push registry.homelab/mi-api:${{ github.sha }}

El runner descarga tu código, construye la imagen Docker con el hash del commit como tag (trazabilidad total), y la sube a tu registry privado.

Paso 3: ArgoCD toma el control

ArgoCD monitoriza el directorio k8s/ de tu repositorio. Cuando detecta cambios (o periódicamente), aplica los manifiestos a tu cluster k3s:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mi-api
spec:
  replicas: 2
  template:
    spec:
      containers:
      - name: api
        image: registry.homelab/mi-api:latest
        ports:
        - containerPort: 3000

ArgoCD actualiza el deployment con la nueva imagen, Kubernetes realiza un rolling update (mantiene la app disponible mientras cambia los pods), y en menos de 30 segundos tu nueva versión está en producción homelab.

Paso 4: Verificación y rollback

En la UI de ArgoCD ves en tiempo real: pods saludables, sincronización completada, recursos creados. Si algo falla, un clic te permite volver a cualquier versión anterior. Todo está versionado en Git, así que el rollback es simplemente hacer checkout de un commit anterior.

De tu homelab a producción enterprise: skills 100% transferibles

Esta es la verdadera magia. Todo lo que has configurado en tu NAS es idéntico a lo que usan empresas como Shopify, GitHub o Spotify:

• GitHub Actions en empresa = Gitea Actions en tu homelab (mismo formato YAML)
• ArgoCD es ArgoCD, igual en un cluster EKS de AWS que en tu k3s casero
• Kubernetes es la API estándar, los manifiestos son idénticos
• Helm charts funcionan igual en cualquier cluster

Cuando en una entrevista te pregunten «¿tienes experiencia con GitOps?», podrás hablar de primera mano sobre operadores, finalizadores, sync waves, hooks de Helm, estrategias de canary deployment… porque lo has montado, roto y arreglado en tu propio laboratorio.

Alternativas si no quieres Kubernetes

No todo el mundo necesita la complejidad de k8s. Si tu caso de uso es más sencillo, existen alternativas válidas:

Docker Compose + Watchtower es el stack más minimalista. Watchtower monitoriza tus imágenes Docker; cuando detecta una nueva versión en el registry, actualiza automáticamente el contenedor. Sin Kubernetes, sin complejidad, pero también sin orquestación avanzada.

Drone CI (y su fork Woodpecker) usa un formato de pipeline más simple que GitHub Actions. Si solo necesitas compilar y desplegar sin la complejidad de matrices, servicios adjuntos y acciones de marketplace, puede ser más elegante.

Hardware recomendado: desde 200€ hasta el infinito

El stack completo puede correr en hardware muy modesto. Estas son las opciones que recomiendo según presupuesto:

Opción económica (200-300€)

Un Intel N100 con 16GB RAM y SSD NVMe. Este procesador de bajo consumo (6W TDP) tiene 4 núcleos y ejecuta virtualización. Perfecto para k3s + Gitea + algunos servicios adicionales.

Ver Mini PCs Intel N100 en Amazon | Buscar en AliExpress

Opción equilibrada (400-600€)

El UGREEN DXP4800 Plus. NAS de 4 bahías con Intel Pentium Gold 8505 (5 núcleos, hasta 4.4GHz), 8GB DDR5 ampliables a 64GB, y dos puertos 2.5GbE. El rendimiento sobra para el stack GitOps completo + almacenamiento + VMs adicionales. He analizado este modelo en nuestra comparativa UGREEN vs Synology.

Ver UGREEN DXP4800 Plus en Amazon

Opción profesional (600-1000€)

Mini PC corporativo reacondicionado (HP EliteDesk, Lenovo ThinkCentre) con Intel i5/i7 de 8ª-10ª generación. 32GB RAM, SSD NVMe, y capacidad para clusters de varios nodos. Perfecto si quieres practicar con alta disponibilidad.

Buscar Mini PCs reacondicionados en Amazon | Ver en AliExpress

He cubierto más opciones de hardware para homelab en nuestra guía de Mini PCs corporativos para Kubernetes y Proxmox.

Almacenamiento

Para el stack GitOps, un SSD NVMe de 512GB es suficiente. Los datos críticos (repositorios Git, imágenes Docker) deben respaldarse a HDD mecánicos o NAS secundario. Si vas a montar un cluster k3s con almacenamiento distribuido (Longhorn), necesitas al menos 100GB SSD por nodo.

Ver SSDs NVMe en Amazon | Buscar en AliExpress

Tips para usar tu homelab como laboratorio profesional

Tener el stack funcionando es solo el principio. Para sacarle el máximo provecho como laboratorio de aprendizaje:

1. Documenta todo como si fuera producción

Escribe runbooks, mantén un wiki, justifica decisiones de diseño. Cuando en una entrevista pregunten «¿por qué elegiste X sobre Y?», tendrás una respuesta fundamentada, no «porque salió en un tutorial».

2. Simula escenarios realistas

Implementa autenticación con SSO (Authentik, Authelia), políticas de red (NetworkPolicies en k8s), backup automatizado (Velero), y monitorización completa (Prometheus + Grafana). Estos son requisitos en cualquier empresa.

3. Practica el desastre

Borra un pod crítico y mide cuánto tarda en recuperarse. Simula la pérdida de un nodo del cluster. Prueba tu estrategia de backup haciendo restore en hardware diferente. El caos controlado es el mejor profesor.

4. Contribuye a proyectos open source

Configura tu Gitea para mirror repositorios de GitHub, haz forks, envía PRs. Conectar tu homelab con el ecosistema exterior te enseña sobre integraciones, webhooks, y flujos de trabajo distribuidos.

5. Certificaciones con base práctica

Si estudias para CKA (Certified Kubernetes Administrator) o GitOps Certified Associate, tu homelab es el laboratorio perfecto. No pagues por playgrounds cloud cuando puedes tener k8s local gratuito.

Problemas comunes y soluciones

El runner de Gitea Actions no arranca

Verifica que Docker esté instalado y el socket accesible. El runner necesita acceso a /var/run/docker.sock para lanzar contenedores de ejecución. En sistemas con SELinux (RHEL, Fedora), ajusta los contextos de seguridad.

ArgoCD no puede sincronizar con el repositorio

Comprueba las credenciales SSH configuradas en ArgoCD. El formato de la URL importa: usa git@gitea.homelab:usuario/repo.git con autenticación por clave, o HTTPS con token. También verifica que el nodo k3s tenga resolución DNS del dominio de Gitea.

k3s consume demasiada RAM

Deshabilita componentes innecesarios al instalar: --disable traefik --disable servicelb --disable metrics-server si ya tienes alternativas. Usa SQLite en lugar de etcd para clusters de un solo nodo.

Los builds son lentos

Monta un registry de Docker local con cache. La primera build siempre es lenta porque descarga imágenes base; las siguientes usarán la cache local. Considera usar BuildKit para builds paralelos.

Veredicto: ¿merece la pena el esfuerzo?

Si eres desarrollador y quieres entender realmente cómo se despliega software en producción moderna, absolutamente sí. Este stack te da:

• Un entorno seguro para experimentar sin miedo a romper nada crítico
• Experiencia práctica con herramientas que se piden en ofertas de trabajo
• Un pipeline de desarrollo personal que acelera tus proyectos side-project
• Conocimiento transferible directamente a entornos enterprise

Si tu prioridad es simplemente tener servicios corriendo con mínima complejidad, empieza por Docker en tu NAS con Portainer. Pero si quieres llevar tus habilidades al siguiente nivel y entender GitOps de verdad, montar este pipeline en tu homelab es una inversión que se amortiza en la primera entrevista técnica.

¿Tienes ya un NAS o Mini PC que podría correr este stack? La barrera de entrada nunca ha sido tan baja, y el conocimiento que ganarás nunca ha sido tan valioso.

Precios y especificaciones sujetos a cambio. Verificar en web oficial del fabricante. Este artículo contiene enlaces de afiliado — si compras a través de ellos, nos ayudas a mantener el blog sin coste adicional para ti.