Autoalojamiento: 12 servicios que puedes correr en tu casa

El autoalojamiento (self-hosting) es recuperar el control de tus datos. En vez de confiar en Google, Dropbox o Netflix, corres sus equivalentes en tu propio servidor. Esta guía cubre los 12 servicios más prácticos para empezar: desde nube privada hasta domótica.

—

El cambio mental

La mayoría de la gente usa docenas de servicios cloud sin pensarlo:

• Google Drive para archivos.
• Gmail para email.
• Google Calendar para citas.
• Dropbox para compartir.
• Netflix para ver películas.
• LastPass para contraseñas.
• Google Photos para fotos.

Cada uno sabe de ti, te muestra anuncios, o te cobra mensualmente. La alternativa: un servidor en casa + software open source. Una inversión inicial de $100-300 USD (hardware) y recuperas el control.

—

Hardware mínimo viable

Mi recomendación 2026: Mini PC con Intel N100. Tiene bajo consumo (15W), buena CPU, soporta 16 GB RAM sin problema, y corre todos los servicios de esta guía sin despeinarse.

—

Los 12 servicios

1. Nextcloud (nube privada)

Para qué: reemplaza Google Drive + Google Calendar + Google Contacts + Google Photos.

RAM: 300-800 MB según uso.

Dificultad: media (Docker lo simplifica).

Por qué: sincronización de archivos, calendario, contactos, fotos, oficina (con Collabora). Todo en tu servidor.

Setup:

Este compose levanta Nextcloud con PostgreSQL como base de datos (más robusto que SQLite para uso real) y expone la interfaz web en http://tu-servidor:8080. Antes de correrlo, asegurate de cambiar POSTGRES_PASSWORD por algo fuerte y guardar el archivo en una carpeta versionada (Git privado). El volumen nc_data contiene la config de Nextcloud; db_data la base entera — ambos sobreviven a reinicios del contenedor.

# docker-compose.yml mínimo
services:
  nextcloud:
    image: nextcloud:29-apache
    restart: always
    ports:
      - "8080:80"
    volumes:
      - nc_data:/var/www/html
    depends_on:
      - db
  db:
    image: postgres:16-alpine
    restart: always
    environment:
      POSTGRES_PASSWORD: cambiar
      POSTGRES_DB: nextcloud
      POSTGRES_USER: nextcloud
    volumes:
      - db_data:/var/lib/postgresql/data
volumes:
  nc_data:
  db_data:

Si ves “Nextcloud can’t be installed because dependencies are missing”, el contenedor no tiene permisos sobre el volumen. Paralo, corré sudo chown -R 33:33 nc_data (el UID 33 es www-data dentro del contenedor) y volvé a levantar. Si ves database not ready en bucle, el depends_on esperó a que el proceso de Postgres arrancara pero no a que la DB estuviera lista para conexiones; agregale al servicio db un healthcheck con pg_isready -U nextcloud y cambiá depends_on por la forma larga con condition: service_healthy. No olvides poner el stack detrás de un reverse proxy con HTTPS antes de exponerlo a internet: docker run -d ... caddy:2 con un Caddyfile que apunte a nextcloud:80 resuelve los certificados automáticamente.

2. Vaultwarden (gestor de contraseñas)

Para qué: reemplaza LastPass, 1Password, Bitwarden.

RAM: 50-100 MB.

Dificultad: baja.

Por qué: tus contraseñas sincronizadas entre dispositivos, todo cifrado de extremo a extremo, sin que un tercero vea nada.

Vaultwarden es un server compatible con clientes Bitwarden. Más liviano que el oficial (escrito en Rust en vez de .NET) y suficiente para uso personal/familiar. Expone la API web en :8081 que puedes usar directamente desde el navegador o configurar como server custom en la app móvil.

services:
  vaultwarden:
    image: vaultwarden/server:latest
    restart: always
    ports:
      - "8081:80"
    volumes:
      - vw_data:/data
volumes:
  vw_data:

Accede desde cualquier cliente oficial de Bitwarden (móvil, desktop, web). La URL del server es la que configuras en la app.

Si la primera vez que abres el cliente te aparece “Invalid SSL certificate”, estás entrando por HTTP en vez de HTTPS. Vaultwarden acepta HTTP solo si tú lo permitís con ROCKET_TLS={}/path/to/cert.pem o poniéndolo detrás de un reverse proxy. Nunca uses Vaultwarden por HTTP en una red que no sea la tuya: las contraseñas viajarían en texto plano dentro de tu LAN. Para recuperación, exportá tu vault periódicamente desde la web UI (User → Export Vault) y guardá el JSON encriptado fuera del server.

3. Pi-hole o AdGuard Home (bloqueador de publicidad DNS)

Para qué: bloquea publicidad y trackers para TODOS los dispositivos de tu casa.

RAM: 30-80 MB.

Dificultad: baja.

Por qué: cero anuncios en smart TVs, apps, juegos. Sin instalar nada en cada dispositivo.

Pi-hole corre un servidor DNS local que devuelve 0.0.0.0 para los dominios de publicidad conocidos (usa listas públicas actualizadas). Los puertos 53/tcp y 53/udp son obligatorios para DNS; 8082:80/tcp es el panel web de administración. Si tienes otro DNS server en la red (como systemd-resolved en el host), va a chocar con el puerto 53 — desactivalo o cambiá el puerto del Pi-hole.

services:
  pihole:
    container_name: pihole
    image: pihole/pihole:latest
    restart: always
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "8082:80/tcp"
    environment:
      TZ: 'America/Toronto'
      WEBPASSWORD: 'cambiar-esto'
    volumes:
      - './etc-pihole:/etc/pihole'
      - './etc-dnsmasq:/etc/dnsmasq.d'

Configura tu router para que use la IP de la Pi como DNS primario. O configuralo manualmente en cada dispositivo.

Si después de levantar el contenedor no responde DNS, el problema casi siempre es que el puerto 53 ya está ocupado por otro servicio (often systemd-resolved). verifica con ss -ulnp | grep :53 en el host; si ves otro proceso, paralo o cambiá el bind del Pi-hole a una IP específica en lugar de 0.0.0.0. El password web es lo único que necesitas cambiar antes del primer arranque; el default 'cambiar-esto' está bien para empezar pero no lo dejes así si exponés el panel. La TZ (zona horaria) afecta los logs y estadísticas — usa la tuya real (America/Argentina/Buenos_Aires si estás en Buenos Aires).

4. WireGuard (VPN personal)

Para qué: accede a tu red desde fuera, protege tráfico en WiFi público.

RAM: ~10 MB.

Dificultad: media (gestión de claves).

Por qué: reemplaza NordVPN/ExpressVPN. Sin límites, sin logs, sin mensualidad.

Mejor opción si quieres simplicidad: Tailscale (basado en WireGuard pero auto-configura todo).

5. Jellyfin (media server)

Para qué: reemplaza Netflix + Plex.

RAM: 200-1000 MB según uso.

Dificultad: media.

Por qué: organizas tus películas/series/música en tu servidor y ves desde cualquier dispositivo (móvil, smart TV, navegador).

Jellyfin lee archivos de /media/movies y /media/tv (en este ejemplo montados como :ro para que Jellyfin no pueda borrar tus archivos originales). El volumen jf_config guarda la metadata, portadas y progreso. El bloque devices: /dev/dri:/dev/dri es opcional: solo funciona si tu CPU tiene GPU Intel/AMD compatible y quieres transcodificación por hardware (ahorra CPU enorme en videos pesados).

services:
  jellyfin:
    image: jellyfin/jellyfin:latest
    restart: always
    ports:
      - "8096:8096"
    volumes:
      - jf_config:/config
      - /media/peliculas:/media/movies:ro
      - /media/series:/media/tv:ro
    # Hardware acceleration (Intel/AMD GPU)
    devices:
      - /dev/dri:/dev/dri  # Solo si tienes GPU compatible
volumes:
  jf_config:

Si ves “Playback error” en el cliente y los logs dicen “no available hardware accelerator”, estás intentando transcodificar pero no tienes /dev/dri montado o tu CPU no soporta QuickSync/VAAPI. Desactivá transcoding en Settings → Playback → “Prefer ffmpeg without hardware acceleration” y volvé a probar (la calidad baja pero funciona). Si el contenedor no arranca con permission denied en /media/movies, asegurate de que el UID 1000 dentro del contenedor (que es jellyfin) pueda leer esos archivos: chmod -R o+rX /media/movies o agregalo al grupo con chown -R :1000.

6. Home Assistant (domótica)

Para qué: controla luces, termostatos, cámaras, sensores.

RAM: 200-500 MB.

Dificultad: alta (depende de cuántos dispositivos integres).

Por qué: un solo panel para toda tu casa. Compatible con Zigbee, Z-Wave, WiFi, MQTT.

Tiene su propio OS (Home Assistant OS) que puedes flashear directo en Raspberry Pi.

7. Gitea o Forgejo (Git self-hosted)

Para qué: tu propio GitHub.

RAM: 100-300 MB.

Dificultad: baja.

Por qué: repositorios privados, CI/CD opcional, wiki, issues. Todo gratis.

Gitea expone la web en :3000 y SSH en :2222 (interno del contenedor, mapeado al host). El segundo puerto es importante: si quieres hacer git clone git@tu-server:usuario/repo.git desde afuera, mapealo a un puerto libre en el host (recuerda no chocar con el SSH del sistema si usas 22).

services:
  gitea:
    image: gitea/gitea:latest
    restart: always
    ports:
      - "3000:3000"
      - "2222:22"
    volumes:
      - gitea_data:/data
volumes:
  gitea_data:

En el primer arranque, Gitea pide completar la config desde http://localhost:3000/install — DB puede ser SQLite (para uso personal) o PostgreSQL. Si ves “ssh: connect to host … port 2222: Connection refused”, el contenedor no logró abrir el puerto 22 interno, casi siempre por un conflicto con otro servicio que ya usa el 2222 en el host ($ sudo lsof -i :2222). Si quieres activar CI/CD nativo con Actions, montá un volumen adicional y configura el runner por separado; no viene activado por default.

8. Uptime Kuma (monitor de servicios)

Para qué: te avisa si algún servicio se cae.

RAM: 50-150 MB.

Dificultad: baja.

Por qué: dashboard simple con checks cada 60 segundos, alertas por Telegram/Discord/email.

Uptime Kuma expone su web en :3001 y persiste config + histórico de checks en el volumen uk_data. Una vez levantado, entrá a http://tu-server:3001, creá el primer monitor (HTTP, Ping, TCP, Keyword) y configura las notificaciones. Es el servicio de monitoreo más simple y visual que hay.

services:
  uptime-kuma:
    image: louislam/uptime-kuma:latest
    restart: always
    ports:
      - "3001:3001"
    volumes:
      - uk_data:/app/data
volumes:
  uk_data:

configuras checks HTTP, ping, TCP, keyword — y te llega alerta instantánea si algo falla.

Si después de un upgrade del contenedor los monitors aparecen vacíos, casi siempre es que el volumen uk_data se montó con un owner distinto (típico cuando moviste el stack a otro host). La solución es dejar que Uptime Kuma reescriba la config: paralo, borrá el contenido del volumen uk_data, levantá de nuevo y volvé a crear los monitors (esta vez guardá un export JSON desde Settings → Backup como respaldo). Para alertas por Telegram necesitas crear un bot con @BotFather y copiar el token + chat_id en la config de notificaciones.

9. Mealie o Tandoor (recetas de cocina)

Para qué: organiza tus recetas, planifica comidas, genera listas de compra.

RAM: 100-300 MB.

Dificultad: baja.

Por qué: si cocinas mucho, esto vale oro. Importas recetas de sitios web con un click.

10. Calibre-Web (biblioteca digital)

Para qué: lector de ebooks con biblioteca.

RAM: 100-200 MB.

Dificultad: baja.

Por qué: sincroniza tu progreso de lectura entre dispositivos, convierte formatos automáticamente.

11. Immich (Google Photos replacement)

Para qué: backup automático de fotos del móvil + galería con IA.

RAM: 300-1000 MB según tamaño.

Dificultad: media.

Por qué: Google Photos dejó de ser gratis ilimitado en 2021. Immich es open source, autoalojado, y hace reconocimiento facial/escenas como Google.

Este compose es más complejo porque Immich necesita cuatro servicios: el server (la app web + API), PostgreSQL (DB), Redis (cache + cola de jobs), y un contenedor de machine-learning separado que hace el reconocimiento facial y de escenas (pesado en CPU/RAM). El volumen immich_data guarda las fotos originales; immich_db la base. Ambos volúmenes son críticos: sin backup, perder las fotos es perder todo.

services:
  immich-server:
    image: ghcr.io/immich-app/immich-server:release
    restart: always
    ports:
      - "2283:2283"
    volumes:
      - immich_data:/usr/src/app/upload
    depends_on:
      - redis
      - database
  database:
    image: postgres:16-alpine
    restart: always
    environment:
      POSTGRES_PASSWORD: postgres
      POSTGRES_USER: postgres
      POSTGRES_DB: immich
    volumes:
      - immich_db:/var/lib/postgresql/data
  redis:
    image: redis:7-alpine
    restart: always
  machine-learning:
    image: ghcr.io/immich-app/immich-machine-learning:release
    restart: always
volumes:
  immich_data:
  immich_db:

App móvil oficial: Immich (iOS/Android). configuras la URL de tu server y empieza a subir.

El primer POSTGRES_PASSWORD: postgres está como ejemplo en la doc oficial, pero cambialo antes del primer arranque: si alguien accede al contenedor puede dumpear todas tus fotos. Si al subir fotos el server se queda colgado en “processing”, el machine-learning no terminó el job (espera unos minutos, depende de tu CPU) o no tiene suficiente RAM. En una Raspberry Pi 5 con 8 GB, considera desactivar el ML facial y dejar solo el de escenas — lo hacés en Administration → Settings → Image Recognition. haz backup del volumen immich_data ANTES de cualquier upgrade mayor de Immich.

12. Paperless-ngx (gestión documental)

Para qué: escanea, archiva y busca documentos.

RAM: 200-500 MB.

Dificultad: media-alta (OCR, clasificación automática).

Por qué: nunca más perder un recibo o contrato. OCR detecta texto en PDFs/imágenes. Tagging automático. Búsqueda full-text.

—

Stack recomendado para empezar

Si tuvieras que elegir solo 4 para empezar:

Una vez que esos 4 estén estables, agrega:

• Jellyfin (si tienes biblioteca de medios)
• Home Assistant (si tienes dispositivos smart)
• Immich (si quieres reemplazar Google Photos)
• Uptime Kuma (para saber si algo se cae)

—

Consejos operativos

1. Backups, backups, backups

Si pierdes el servidor y no tienes backup, pierdes todo. Mínimo:

• Script de backup automático diario a otro disco o NAS.
• Backup off-site mensual (Backblaze B2, $0.005/GB/mes).
• Prueba los backups cada 3 meses (un backup que no se restaura no es backup).

2. Monitoreo

Si no sabes que algo se cayó, no lo vas a arreglar. Uptime Kuma + Grafana + Prometheus es la combinación estándar.

3. HTTPS para todo

Si expones servicios a internet, usa HTTPS. Caddy es lo más fácil (auto-renueva certificados de Let’s Encrypt).

4. VPN para acceso remoto

Nunca expongas servicios directamente a internet. Usa Tailscale o WireGuard. Solo tú accedes.

5. Documenta tu setup

Un README en tu repo de Git con la configuración, los puertos, los paths de los volúmenes. Cuando se te olvide en 6 meses, te va a salvar.

—

Recursos para profundizar

• r/selfhosted en Reddit: comunidad enorme, recomendaciones diarias.
• Awesome Selfhosted en GitHub: catálogo curado de 400+ servicios self-hosted.
• linuxserver.io: maintainers de imágenes Docker de calidad para casi todo.
• Hetzner, Netcup, Contabo: VPS baratos si quieres empezar sin comprar hardware.

—

Siguientes pasos

Si quieres profundizar más:

1. Kubernetes en casa (k3s): si quieres aprender DevOps de verdad.

2. Ansible/Terraform: para automatizar el setup.

3. Vaultwarden + 2FA: seguridad adicional.

4. Reverse proxy con Caddy + Cloudflare: HTTPS automático.

5. Múltiples servidores: alta disponibilidad con keepalived.

¿Próximo post? Estaba pensando en Tailscale: VPN sin abrir puertos o Caddy como reverse proxy con HTTPS automático. Déjamelo en comentarios.

Si te sirvió, suscríbete al blog para no perderte los siguientes tutoriales.

Preguntas frecuentes

Lee también

• Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
• Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins
• Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
• Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
• Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux

• Docker en producción: 5 prácticas que separan junior de senior
• Monitoreo de servidores Linux con Grafana y Prometheus

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]