De hardware sobrante a servidor en producción: por qué somos adictos al self-hosting en Raspberry Pi

De hardware sobrante a servidor en producción: por qué somos adictos al self-hosting en Raspberry Pi

May 07, 2026 self-hosting raspberry-pi node.js devops dns github-actions astro web-infrastructure

El Servidor Oculto en Tu Cajón

Nada como el placer de montar un sitio web en producción con hardware que vale menos que un buen café. Plataformas en la nube como Vercel resuelven la mayoría de casos. Pero hay motivos reales para self-hostear en un Raspberry Pi. Van más allá de la simple nostalgia.

Imagina esto: usas un framework Node.js como Astro, SvelteKit o React. Trae dependencias que no encajan en entornos serverless. Quizás una librería i18n antigua que funciona perfecto, pero no se empaqueta estáticamente. O quieres control total sobre el runtime. Ahí tu Pi se convierte en opción barata frente a nubes costosas.

Paso 1: Enruta el Tráfico—Conecta Tu Pi al Mundo

Primero, abre puertos en tu router. Es el puente entre tu IP pública y ese cacharro silencioso en el estante.

Usa Caddy, un reverse proxy moderno y fácil. Configúralo así:

yoursite.com {
    root * /home/usuario/proyectos/yoursite
    
    file_server
    reverse_proxy localhost:4321
}

Cambia el puerto según tu framework: Astro usa 4321, SvelteKit 5173, apps Node.js suelen ir en 3000. Recarga Caddy y ya tienes la base.

Paso 2: Apunta Tu Domain al Pi

Registradores como NameOcean lo hacen simple. Crea un registro DNS A:

A Record: yoursite.com → tu.ip.pública

Listo. El port forwarding del router hace el resto. El tráfico llega directo a tu Pi.

Paso 3: Compila una Vez, Ejecuta Siempre

Genera la build con el comando habitual:

npm run build

Sale una carpeta dist con tu app compilada y el entry point, como entry.cjs o entry.mjs.

Entra PM2, el gestor de procesos que mantiene todo vivo:

npm install -g pm2
cd dist/
pm2 start entry.mjs

Tu sitio rueda sin supervisión. Ni terminal abierta ni dramas.

Paso 4: Despliegues Automáticos con GitHub Actions

Self-hostear mola si evitas loguearte por SSH cada cambio. GitHub Actions lo hace fluido.

Crea .github/workflows/deploy.yml en tu repo:

name: Desplegar en Raspberry Pi
on: [push]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Desplegar por SSH
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.PI_HOST }}
          username: ${{ secrets.PI_USER }}
          password: ${{ secrets.PI_PASSWORD }}
          script: |
            ~/bin/deploy.sh

Guarda IP y credenciales en secrets del repo. Ahora el script de despliegue:

#!/usr/bin/env bash
set -euo pipefail

BASE_DIR="$HOME/projects"
PORTS=(4321 4322)
PORT_INDEX=0

echo "Actualizando código..."
for dir in "$BASE_DIR"/*/ ; do
    if [[ -d "$dir/.git" ]]; then
        (cd "$dir" && git pull)
    fi
done

echo "Construyendo proyectos..."
for dir in "$BASE_DIR"/*/ ; do
    if [[ -f "$dir/package.json" ]]; then
        CURRENT_PORT=${PORTS[$PORT_INDEX]}
        (
            cd "$dir"
            npm run build -- --port "$CURRENT_PORT"
        )
        PORT_INDEX=$(( (PORT_INDEX + 1) % ${#PORTS[@]} ))
    fi
done

echo "Reiniciando servicios..."
pm2 restart all

Cada git push actualiza, compila y reinicia todo solo.

La Cuentas Claras

No es para todos. Pierdes redundancia y CDN global de la nube. Ancho de banda limitado. Si cae tu internet, adiós sitio. Pero si prefieres control total, ahorro y saber que todo es tuyo, funciona de maravilla.

Es una masterclass práctica. Aprendes DNS, reverse proxies, PM2 y CI/CD como ninguna dashboard te enseña.

Ese Raspberry Pi olvidado no es un juguete. Es infraestructura real. Prueba que no siempre hace falta enterprise para producción.

Read in other languages:

RU BG EL CS UZ TR SV FI RO PT PL NB NL HU IT FR DE DA ZH-HANS EN