Servidores

Autoalojamiento en casa 2026: costos, ISP, ruido y Cloudflare Tunnel (guía sysadmin)

Por qué decidí autoalojar en casa en 2026 (y por qué tú también puedes)

Tengo un servidor Dell OptiPlex 3060 corriendo Debian 13 dentro de un armario desde hace tres años. Lo que empezó como un experimento para sacar Nextcloud y Jellyfin de la nube se convirtió en el nodo principal de mi vida digital: backups cifrados, DNS interno, agente de IA local, túnel VPN y la página que estás leyendo ahora mismo. Funciona. Pero no funciona porque instalé “12 servicios” — funciona porque aprendí, a la mala, los cuatro o cinco límites prácticos que un servidor Linux en casa respeta a diario y que casi nadie te dice en los tutoriales.

Este post es la guía que me hubiera gustado leer el día que monté el primer servidor. No es una receta de instalación ni una lista de servicios — eso ya lo cubrimos en Domina el Autoalojamiento en 2026 y en Cómo armar un homelab en 2026: presupuesto real + roadmap 12 meses. Aquí vas a leer sobre ISP, CGNAT, la factura de luz, el ruido del gabinete, las caídas eléctricas y la negociación con tu casa. Lo que pasa cuando el servidor ya está montado y empieza a vivir con el resto de tu familia.

TL;DR — Lo que vas a tener al final

TL;DR — Lo que vas a tener al final

  • Tiempo de setup: 1 día para el primer encendido y 4-6 horas más para túneles + monitoreo + backups. Mantenimiento mensual: ~1 hora.
  • Requisitos: 1 PC con 8 GB de RAM mínimo (reciclar un desktop sirve), Debian 13 o Ubuntu 26.04 LTS, UPS de 600 VA mínimo, dominio propio y un proveedor de DNS dinámico o Cloudflare Tunnel.
  • Resultado: 5-10 servicios accesibles desde internet con un costo eléctrico de 4-9 USD al mes, sin suscripciones mensuales a la nube y con tus datos físicamente en tu casa.
  • Troubleshooting común: CGNAT del ISP bloqueando puertos, IPv6 solo saliente, cortes de luz que rompen el filesystem, ruido del ventilador en la sala y migración repentina de IP pública.

Por qué autoalojar en casa sigue siendo buena idea en 2026

Tres razones lo justifican hoy más que hace cinco años, y una razón lo desaconseja. Vamos con las buenas.

Primero, el costo del VPS barato subió. Hetzner, OVH y DigitalOcean siguen ofreciendo servidores por 4-6 USD al mes, pero ese precio solo cubre 2 GB de RAM y un volumen SATA. El primer escalón real (4 vCPU + 8 GB + 80 GB SSD) está en 12-18 USD. Tres años de eso son 432-648 USD — exactamente lo que cuesta reciclar un Lenovo M720q con 32 GB de RAM comprándolo usado. La amortización cambia de ecuación.

Segundo, la latencia a “la nube” sigue siendo mala para datos que produces en casa. Selfies, escaneo de documentos, archivos de Immich y respaldos de Nextcloud viajan hasta Virginia o Frankfurt ida y vuelta. En LAN local, esos mismos archivos se mueven a 1-2 GB/s.

Tercero, la dependencia de proveedores únicos se rompió. CrowdStrike, OVH caído, Google Fotos cerrando funciones, iCloud borrando cuentas sin aviso y Adobe subiendo Creative Cloud 30% en un año — la lista de proveedores que fallaron en 2024-2026 es demasiado larga para confiar. Tener una copia física en tu casa es una red de seguridad real, no una romántica del open source.

Ahora la razón para pensarlo dos veces: el ISP no siempre te deja. Si tu ISP te asigna CGNAT sin IPv6, tu servidor seguirá siendo alcanzable por internet pero no podrá iniciar conexiones entrantes sin un workaround. Y si tu ISP aplica QoS agresivo al puerto 25 o al tráfico persistente, el servidor casero se vuelve un lastimoso. Antes de comprar nada, verifica que tu ISP no te esté boicoteando. Lo vemos en la próxima sección.

Tu ISP decide más de lo que crees: CGNAT, puertos y QoS

El obstáculo más común en 2026 no es técnico — es contractual y operacional. Tu proveedor de internet decide si tu servidor funciona o no, y la mayoría de los hogares en América Latina y Europa están en una de estas tres situaciones.

Situación 1: IP pública dinámica (la mejor)

Ethernet directo a tu router, IP v4 pública que cambia cada vez que se reinicia el módem o cada 24 horas por DHCP. Es el caso de la mayoría de las conexiones de fibra óptica residenciales con un router neutro detrás. Aquí puedes abrir puertos sin problema y un DNS dinámico (DDNS) cubre la rotación de IP.

Para confirmarlo, abre tu router y mira la interfaz WAN: si la IP que aparece empieza con un prefijo público (no 10.x, no 172.16-31.x, no 192.168.x), tienes IP pública. Verifícalo desde afuera comparando con curl ifconfig.me corriendo en tu servidor.

Situación 2: CGNAT (la más común en LATAM)

Tu ISP te asigna una IP privada (100.64.0.0/10, 10.x, 172.16-31.x) y comparte una IP pública entre muchos clientes. Los puertos bloqueados por defecto son todos los entrantes. Ni port forwarding, ni UPnP, ni nada. Esta configuración es estándar en ISPs grandes de Argentina, México, Chile y Colombia desde 2022.

La salida real en 2026 es Cloudflare Tunnel: corres cloudflared en el servidor, sale al exterior por HTTPS puerto 443 como cualquier usuario navegando web, y Cloudflare expone tu servicio al mundo sin tocar el router. Configuración completa abajo en la sección 5. Si tu ISP no te da CGNAT pero igual bloquea el puerto 80, Cloudflare Tunnel es la salida más limpia porque no depende del ISP ni del router.

Situación 3: IP compartida con CG-NAT pero IPv6 público

Menos común pero creciente en ISP europeos. Tu ISP te da una dirección IPv6 pública por sesión, pero la IPv4 sigue en CGNAT. Aquí combinas DDNS para la IPv6 y Cloudflare Tunnel como fallback — porque la IPv6 pública es alcanzable por clientes que también tengan IPv6, y un porcentaje cada vez mayor sí la tiene.

Para detectar esta situación desde Linux, basta con mirar la dirección de la interfaz:

# IPv4 — si es 100.64.x.x, 10.x.x.x o 192.168.x.x, estás en CGNAT o detrás de router
ip -4 addr show eth0 | grep inet
# IPv6 — si tiene un prefijo distinto a fe80:: y NO empieza con fd, tienes IPv6 pública
ip -6 addr show eth0 | grep inet6

Si ambas interfaces devuelven direcciones privadas, confirma mirando la WAN del router. Y si todo es privado, el plan Cloudflare Tunnel es la salida.

Electricidad: lo que nadie calcula (y lo que sí cuesta)

“Un servidor consume poca luz” es la mentira más repetida del autoalojamiento casero. Calculemos el caso real.

Un Dell OptiPlex 3060 con un i5-8500 y un SSD consume entre 25 y 45 W en idle, 60-80 W bajo carga continua. Un Lenovo ThinkCentre M720q con i5-8400T oscila entre 18 y 35 W. Un mini PC N100 moderno ronda los 10-22 W. Y un rack de dos Xeon viejos puede pasar los 200 W en idle — eso ya es una estufa.

Traducido a dinero con tarifa LATAM promedio (0,15 USD/kWh con impuestos):

Hardware Consumo idle Consumo 24/7 mensual Costo mensual
Mini PC N100 (Beelink EQ13) 12 W 8,6 kWh 1,3 USD
Lenovo M720q i5-8400T 25 W 18 kWh 2,7 USD
Dell OptiPlex 3060 i5-8500 35 W 25 kWh 3,8 USD
PC vieja con HDD + GPU 80 W 58 kWh 8,7 USD
Rack mini con 2x Xeon E5-2620 180 W 130 kWh 19,5 USD

No parece mucho, pero súmale el UPS, el switch PoE, el disco USB de backups, el modem, el router y un disco de red para NAS — y el consumo total sube otros 30-50 W sin que nadie se dé cuenta. La realidad: un homelab mediano en LATAM gasta entre 5 y 15 USD al mes de luz, no los “2 USD” que proclaman los blogs gringos. En tarifa europea (0,32 USD/kWh), el mismo homelab sale por 12-35 USD al mes.

Cómo medir el consumo real

Si tienes un medidor inteligente tipo Shelly Plug o Tapo P110, conéctalo al rack y mide durante una semana entera. Vas a descubrir que el consumo idle es 30-50% más alto de lo que dice la ficha técnica porque el SSD, la RAM y los ventiladores suman. La métrica real es USD/mes en la factura, no vatios en la etiqueta.

UPS: lo mínimo indispensable

Un UPS de 600 VA protege el servidor y el modem durante 10-20 minutos. Eso es suficiente para sobrevivir el 95% de los cortes de luz domésticos y para apagar limpio con un script cuando la batería cae al 20%. Con 150-220 USD compras un APC Back-UPS 600VA que te da esa protección.

Configura el demonio apcupsd o nut y conecta vía USB al servidor. El script de shutdown hace dos cosas: avisa por Telegram que la luz se cortó, y si la batería baja del 20%, ejecuta shutdown -h now. Verificable así:

sudo apt install apcupsd
sudo sed -i 's/^UPSCABLE.*/UPSCABLE usb/' /etc/apcupsd/apcupsd.conf
sudo sed -i 's/^UPSTYPE.*/UPSTYPE usb/' /etc/apcupsd/apcupsd.conf
sudo systemctl restart apcupsd
apcaccess status | grep -E "BATTERYLEVEL|TIMELEFT|LOADPCT"

Si TIMELEFT muestra menos de 5 minutos con LOADPCT arriba del 50%, el UPS es chico. Sustituir por 1000 VA o agregar un segundo disco SSD con coherencia transaccional (ext4 con barrier=1, lo explica la sección de backups).

Ruido, calor y la negociación con tu casa

El primer mes nadie se queja. El segundo mes alguien te pregunta “¿qué es ese zumbido?”. El cuarto mes te mudas de oficina o el servidor sale al armario. Esta es la parte que ningún tutorial menciona.

Ruido: el factor decisivo

Un OptiPlex o ThinkCentre con ventiladores de 80 mm ronda los 28-35 dB en idle, casi imperceptible. Un PC gamer con ventiladores de 120 mm sube a 38-45 dB — audible. Un servidor rack con ventiladores de 40 mm ronda los 50-60 dB — insoportable en una sala. La medición real es: si tu servidor está en el living, debe pasar los 30 dB. Si está en un cuarto cerrado, hasta 40 dB.

Si tu PC es ruidoso, hay tres opciones reales:

  • Reemplazar el ventilador de la fuente por uno Noctua o be quiet! de 80-120 mm. 25 USD, baja 5-8 dB.
  • Mover el servidor a un armario, garage o sótano ventilado. La temperatura ambiente importa — más en la siguiente sección.
  • Cambiar de hardware. Un N100 moderno con SSD pasivo silencioso (Beelink EQ13 o MinisForum UN100) usa menos de 15 W y es 100% pasivo, así que cero ruido. 150-220 USD nuevo, suficiente para 80% de los servicios caseros.

Calor: el enemigo silencioso

Un servidor que consume 35 W genera 35 W de calor — es calorimetría directa, no hay vuelta. En un armario de 1×1 m sin ventilación, ese calor eleva la temperatura ambiente 5-8°C sobre la habitación. A 35°C internos, el SSD empieza a throttlear y el MTBF cae 50%. A 45°C, se apaga solo. A 55°C, los capacitores electrolíticos se degradan rápido.

Para mantener el servidor sano en un armario cerrado:

  • Ventilación pasiva con rejilla superior e inferior, no cerrada hermética.
  • Sensor de temperatura con smartctl -A /dev/sda | grep Temperature revisado diariamente o con smartd configurado para alerta.
  • Límite duro: smartctl -l scterc,50,50 /dev/sda para que el SSD baje rendimiento en lugar de sobrecalentarse.

En climas templados (centro de Argentina, Chile, Colombia Eje Cafetero), un OptiPlex o N100 funciona bien sin aire acondicionado. En climas cálidos (costa Caribe, norte de México, Brasil tropical), el armario necesita ventilación forzada o el servidor sale al cuarto con aire acondicionado prendido 12 horas.

Cómo salir a internet: DDNS, Cloudflare Tunnel y port forwarding

Tres caminos llegan al mismo destino — exponer tu servidor al mundo. La elección depende del ISP y de cuánta complejidad quieres tolerar.

Camino 1: Port forwarding + DDNS (cuando tienes IP pública dinámica)

El más simple. Configuras tu router para redirigir los puertos 80 y 443 a la IP local del servidor, y un cliente DDNS mantiene tu dominio apuntando a la IP pública actual.

DuckDNS es gratuito, simple y usa la API HTTP para actualizar:

# Obtener token en duckdns.org (login con GitHub)
# Crear dominio: casa.duckdns.org
curl "https://www.duckdns.org/update?domains=casa&token=TOKEN&ip="
# Cron cada 5 minutos
echo '*/5 * * * * root curl -s "https://www.duckdns.org/update?domains=casa&token=TOKEN&ip=" > /dev/null' 
  > /etc/cron.d/duckdns

Después, en Cloudflare gestionas tu dominio real (ej. casa.ejemplo.com) con un CNAME a casa.duckdns.org. Renovación de certificados Let’s Encrypt vía Caddy o Nginx con --dns-cloudflare.

Camino 2: Cloudflare Tunnel (cuando hay CGNAT)

El túnel inverso más limpio en 2026. cloudflared en el servidor establece una conexión saliente HTTPS puerto 443 con Cloudflare, y el tráfico entrante a tu dominio llega por ese túnel. Cero configuración en el router, cero puertos abiertos.

Instalación y configuración mínima:

# Instalar cloudflared
curl -fsSL https://pkg.cloudflare.com/cloudflare-main.gpg 
  | sudo tee /usr/share/keyrings/cloudflare-main.gpg > /dev/null
echo "deb [signed-by=/usr/share/keyrings/cloudflare-main.gpg] https://pkg.cloudflare.com/cloudflared $(lsb_release -cs) main" 
  | sudo tee /etc/apt/sources.list.d/cloudflared.list
sudo apt update && sudo apt install cloudflared -y
# Login y crear túnel (asumimos dominio ya delegado a Cloudflare)
cloudflared tunnel login
cloudflared tunnel create casa-server
# Configurar — apuntar servicio a localhost:8080
mkdir -p ~/.cloudflared
cat > ~/.cloudflared/config.yml << 'EOF'
tunnel: casa-server
credentials-file: /home/sysadmin/.cloudflared/<UUID>.json
ingress:
  - hostname: app.ejemplo.com
    service: http://localhost:8080
  - service: http_status:404
EOF
# Correr como servicio del sistema
sudo cloudflared service install
sudo systemctl enable --now cloudflared

Después configuras en el dash de Cloudflare la ruta app.ejemplo.com -> casa-server y listo. El túnel pasa por HTTPS, certificados los gestiona Cloudflare, y tu servidor queda completamente invisible a scans externos. Si quieres profundizar, Exponer servicios de tu home lab a internet: 6 vías explicadas compara Cloudflare Tunnel con Tailscale, Ngrok, frp y otras 4 opciones reales.

Camino 3: Tailscale o NetBird (acceso VPN personal)

Si tu objetivo es acceder desde tu laptop o teléfono, no abrir nada al público, Tailscale o NetBird self-hosted es imbatible. WireGuard por debajo, mesh entre dispositivos, IP fija en cada nodo, MagicDNS para nombres. La diferencia con los caminos anteriores: tu servidor no tiene URL pública, pero accedés desde cualquier dispositivo sin tocar el firewall.

Si vas a elegir uno solo, mi recomendación en 2026 para casa: Cloudflare Tunnel para servicios públicos + Tailscale para administración. Esa combinación cubre el 95% de los casos sin tocar el router ni hacer port forwarding.

El stack mínimo seguro: DNS interno, reverse proxy y 2FA

Una vez que el servidor está accesible desde afuera, el stack mínimo que necesitas correr encima es el siguiente.

Reverse proxy con Caddy o Nginx

Caddy es mi elección por defecto en 2026 por la configuración mínima y el HTTPS automático vía Let’s Encrypt sin plugins extras. Una sola línea por servicio:

# /etc/caddy/Caddyfile
app.ejemplo.com {
    reverse_proxy localhost:8080
}
nextcloud.ejemplo.com {
    reverse_proxy localhost:8081
}

reinicias Caddy y los certificados se emiten solos. Cada vez que agregás un subdominio, los certs se renuevan en menos de 30 segundos. Si prefieres Nginx, la guía Nginx en Ubuntu 24.04: configurar reverse proxy + HTTPS automático (guía 2026) te da el mismo resultado con más líneas.

DNS interno con Pi-hole o AdGuard Home

El servidor casero también resuelve los DNS de la red local. AdGuard Home es mi favorito porque corre en binario único sin dependencias, expone dashboard web, y bloquea publicidad y trackers para toda la casa.

# Descargar e instalar
curl -L -o /tmp/AdGuardHome_linux_amd64.tar.gz 
  https://github.com/AdguardTeam/AdGuardHome/releases/latest/download/AdGuardHome_linux_amd64.tar.gz
tar -xzf /tmp/AdGuardHome_linux_amd64.tar.gz -C /opt/
sudo /opt/AdGuardHome/AdGuardHome -s install
# Configurar: IP del servidor como DNS del router DHCP
# Dashboard web: http://192.168.5.10:3000

Para una red con 10-15 dispositivos, AdGuard bloquea 25-40% de las consultas a trackers y reduce 5-15% el tráfico total en casa. Funciona, y la única tarea de mantenimiento es mirar el log semanal.

2FA obligatorio en todo

SSH con clave ed25519 + TOTP, dashboard de Immich/Nextcloud/Vaultwarden con 2FA, Cloudflare con 2FA y passkey. La regla es: si el servicio soporta 2FA, lo activás antes de exponerlo a internet. Si no soporta 2FA, lo dejás detrás de Tailscale en lugar de público.

El argumento de “es mi casa, no me van a atacar” es exactamente lo que dicen los honeypots antes de ser comprometidos. Las estadísticas de fail2ban 2026 muestran que un servidor SSH abierto recibe 200-400 intentos de fuerza bruta por día desde el primer minuto que está expuesto. La 2FA, fail2ban y un puerto no estándar son las tres capas que separan “expuesto” de “atacado”.

Backups 3-2-1 adaptados a la casa

La regla 3-2-1 sigue vigente: tres copias de tus datos, en dos tipos de medio distintos, una fuera de casa. En el contexto casero, la implementación práctica es esta.

  • Copia 1 (working set): el servidor mismo, con ZFS o Btrfs para snapshots instantáneos.
  • Copia 2 (disco local): un disco USB de 2-4 TB que rota semanalmente. Coste: 60-80 USD.
  • Copia 3 (off-site): una cuenta de Backblaze B2 con cifrado previo, sincronizada con restic o Borg.

El script mínimo de backup con restic apuntando a Backblaze B2:

sudo apt install restic
export B2_ACCOUNT_ID="TU_ACCOUNT_ID"
export B2_APPLICATION_KEY="TU_KEY"
export RESTIC_REPOSITORY="b2:casa-bucket:sysadmin"
restic -r "$RESTIC_REPOSITORY" init
cat > /usr/local/bin/backup.sh << 'EOF'
#!/bin/bash
set -euo pipefail
export B2_ACCOUNT_ID="TU_ACCOUNT_ID"
export B2_APPLICATION_KEY="TU_KEY"
export RESTIC_REPOSITORY="b2:casa-bucket:sysadmin"
export RESTIC_PASSWORD_FILE="/etc/restic/passwd"
restic backup /home /var/lib/docker /etc /root 
  --tag automatico --exclude-file=/etc/restic/exclude.txt
restic forget --keep-daily 14 --keep-weekly 8 --keep-monthly 12 --prune
EOF
sudo chmod 700 /usr/local/bin/backup.sh

Configuras un timer systemd que corra el script cada noche a las 03:00 y olvidate. El storage en B2 cuesta 6 USD/TB/mes — 1 TB para una casa típica sale menos de 2 USD al mes, mucho más barato que mantener un segundo servidor físico.

Seguridad del borde cuando expones tu IP residencial

Hay una diferencia importante entre exponer IP pública y abrir puertos al mundo. Cloudflare Tunnel mitiga el primer vector (la IP residencial no se filtra), pero no te salva de un ataque interno si alguien entra a tu LAN.

Segmentación con VLANs

Si tu router lo soporta (UniFi, OPNsense, Mikrotik), separar servidores, IoT y usuarios en VLANs distintas. El servidor queda aislado: si una bombilla inteligente es comprometida, el atacante no ve la red de tus laptops ni del servidor.

OPNsense es la opción open source más común para hacerlo bien, y la guía Proxmox + OPNsense: diseño completo de red, firewall, VLANs y servidores explica el setup completo. UniFi es más caro pero más fácil para quien prefiere GUI.

Fail2ban en todos los servicios

Si usas SSH expuesto, fail2ban con la acción estándar banea la IP tras 3 intentos fallidos. CrowdSec suma inteligencia colectiva — si una IP te atacó a ti y a 50 sysadmins más, ya está en la lista compartida y se banea apenas intenta. La guía CrowdSec 2026 cubre la instalación en 10 minutos.

WAF y rate limiting

Si exponés muchos servicios vía Cloudflare Tunnel, activa las reglas de WAF administradas por Cloudflare (gratis en el plan Free para 5 reglas básicas). Suma rate limiting por IP para bloquear scrapers y bots antes de que lleguen al servidor.

Costos reales: comparativa casa vs VPS vs nube

Para cerrar el post, una tabla honesta con los costos que vas a asumir las primeras 52 semanas si eliges cada camino. Datos basados en autoalojamiento con un mini PC N100 + dominio + backups off-site vs Hetzner CX22 vs DigitalOcean 4 GB vs AWS Lightsail 4 GB.

Concepto Casa (N100) Hetzner CX22 DigitalOcean 4GB AWS Lightsail 4GB
Setup inicial 220 USD 0 USD 0 USD 0 USD
Storage mensual 4 USD (B2) incluido incluido incluido
Luz mensual 4 USD 0 USD 0 USD 0 USD
Tráfico mensual 0 USD (asimétrico) 1 TB incluido 4 TB incluido incluido
Costo mensual recurrente 8 USD 5,30 USD 24 USD 20 USD
Costo anual después de 1 año 96 USD 63 USD 288 USD 240 USD
Amortización a 3 años 372 USD 192 USD 864 USD 720 USD

La casa no es la opción más barata. La nube gana en costo mensual puro, sobre todo en Hetzner. Pero la casa gana en:

  • Amortización a 3+ años (el hardware ya está pago).
  • Latencia LAN para Immich, Nextcloud, backups internos.
  • Privacidad: nadie audita tus datos.
  • Aprendizaje: entiendes cómo funciona un servidor de verdad, no una abstracción web.

El break-even llega al año y medio si solo corres Immich y Nextcloud. Antes de eso, un VPS es más pragmático. Después de eso, tu casa paga dividendos en conocimiento y amortización.

Cuándo NO autoalojar en casa (la sección honesta)

No todo el mundo debería correr un servidor casero. Estos son los casos donde no vale la pena.

Si vives en un departamento alquilado donde modificar cableado o poner un rack te expone a perder el depósito, no insistas. Comprá un VPS.

Si tu ISP te asigna CGNAT sin IPv6 y no puedes instalar cloudflared (porque solo tienes acceso a una red empresarial bloqueada), la fricción es muy alta para el beneficio. Ve a un VPS.

Si el lugar donde vives tiene cortes de luz diarios o fluctuaciones de voltaje serias y no puedes comprar un UPS decente, cada apagón te va a corromper el filesystem. Mejor VPS con SLA.

Si necesitas 99,9% de uptime para un servicio público al que acceden otras personas, una casa con conexión residencial no es el camino. Sumá un segundo ISP con failover, un segundo UPS, generador, y ya no es un homelab, es un datacenter pequeño. Vuelve a la nube.

Y si tu motivación es solo “no quiero pagar Google Drive”, reconsiderá. Google Drive cuesta 100 USD al año por 2 TB, que es exactamente el break-even de un VPS. Para fotos familiares y backups livianos, la nube es más barata. El autoalojamiento se justifica cuando quieres aprender, cuando necesitas latencia LAN, o cuando tienes > 5 TB de datos que no quieres subir.

Preguntas frecuentes

¿Cuánto paga al mes realmente de luz un servidor Linux 24/7 casero?

Para un mini PC N100 moderno, el costo ronda 1,3-2 USD al mes en tarifa LATAM y 3-5 USD en tarifa europea. Para un OptiPlex o ThinkCentre reacondicionado con SSD, 3-9 USD según tarifa. Sumando router, switch, UPS y disco USB de backups, el total real de un homelab mediano cae entre 5 y 15 USD al mes en LATAM y 12-35 USD en Europa. La métrica correcta es USD por mes en la factura, no vatios en la etiqueta.

¿Cómo accedo a mi servidor desde internet si mi ISP usa CGNAT?

Cloudflare Tunnel es la salida más limpia en 2026. Instalas cloudflared en tu servidor, abres una conexión saliente HTTPS puerto 443 hacia Cloudflare y el tráfico entrante a tu dominio llega por ese túnel. Cero puertos abiertos en el router, cero port forwarding, funciona aunque el ISP te tenga en CGNAT puro. La alternativa es Tailscale o NetBird si solo necesitas acceso personal desde tus dispositivos.

¿Es legal usar mi conexión residencial como servidor en América Latina?

Sí, en la mayoría de los países LATAM no hay restricción legal explícita. Pero casi todos los ISPs residenciales tienen en sus Términos de Servicio una cláusula que prohíbe uso comercial intensivo o reventa. Para uso personal y aprendizaje, no hay problema. Si corres un negocio encima, técnicamente estás violando el TOS aunque la legislación no te persiga. Revisar el contrato antes de montar nada.

¿Qué UPS necesito para que mi servidor casero sobreviva al primer apagón?

Un UPS de 600 VA cubre el servidor y el modem durante 10-20 minutos, suficiente para el 95% de los cortes domésticos y para apagar limpio cuando la batería baja del 20%. Modelos como el APC Back-UPS 600VA cuestan 150-220 USD y se amortizan en el primer corte serio. Conectalo vía USB y configura apcupsd o nut para shutdown automático cuando la batería caiga al umbral.

¿Conviene más un mini PC moderno o reusar una desktop vieja como servidor casero?

Si la desktop vieja es de 2015 o anterior con HDD mecánico, un mini PC N100 moderno gana en todo: consume 70% menos luz, es 100% silencioso, tiene SSD nativo y CPU con aceleración de cifrado por hardware. Cuesta 150-220 USD nuevo y se amortiza en 12-18 meses solo en luz. Si tienes una desktop con i5 de 8va gen o superior + SSD, reusarla está perfecto. Lo que no vale la pena en 2026 son los HDD mecánicos para servidores caseros.

Lee también

Alfonso Moreno | Sysadmin Senior

Soy Alfonso, sysadmin senior con RHCE y más de 10 años administrando sistemas Linux para empresas y proyectos personales. Me especializo en infraestructura, redes, virtualización, monitoring, automation y self-hosting. Sobre SoyLinux.com SoyLinux.com es un blog técnico en español sobre Linux, software libre y self-hosting. Lo mantengo en mi tiempo libre. Áreas de expertise - Linux server administration: RHEL, CentOS, Rocky, Alma, Fedora, Debian, Ubuntu - Network services: Postfix, BIND, Samba, NFS, Squid - Virtualización y containers: KVM, Proxmox, Docker, Podman - Monitoring: Prometheus, Grafana, Zabbix - Automation: Ansible, Bash scripting - Self-hosting: Vaultwarden, Nextcloud, Jellyfin, Immich, Homelab Contacto - Email: [email protected]

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *