Despliegue de Owncast en un VPS: streaming en vivo autoalojado, SSL, Docker y copias de seguridad

1. Qué configuramos y por qué

Owncast es una plataforma abierta para alojar live-streaming de forma independiente. Recibe la señal de vídeo de OBS Studio u otra aplicación compatible con RTMP, la transcodifica o la transmite a los espectadores mediante un reproductor web, y proporciona una página de transmisión, chat, ajustes del canal y moderación básica.

A diferencia de Twitch, YouTube Live o Kick, el servidor de Owncast está bajo su control. Usted gestiona directamente el dominio, los ajustes de acceso, los registros, las copias de seguridad y la política de almacenamiento de datos. Esto resulta útil para transmisiones privadas, eventos corporativos, proyectos educativos, comunidades propias o la integración del streaming con un sitio web.

En esta guía se presupone el siguiente esquema:

• VPS con Ubuntu Server 24.04 LTS y una dirección IPv4 pública;
• dominio stream.example.com dirigido al VPS;
• Docker Engine y Docker Compose Plugin;
• Owncast en un contenedor con almacenamiento persistente;
• Caddy como reverse proxy y gestor automático de TLS;
• OBS Studio en el ordenador del presentador;
• almacenamiento externo para las copias de seguridad.

Qué obtendremos al final

Después de seguir las instrucciones, el espectador podrá abrir la dirección HTTPS del canal y usted podrá enviar la señal desde OBS a la dirección RTMP. La interfaz web de Owncast estará disponible a través de Caddy en los puertos 80 y 443, mientras que la conexión RTMP se aceptará en el puerto 1935. El panel de administración estará protegido con una contraseña independiente.

Es importante comprender los límites de este esquema. Un VPS no crea ancho de banda adicional para cada espectador: el servidor debe enviar la señal de vídeo a cada cliente conectado. Si la señal tiene un bitrate de 6 Mbit/s y la ven 50 personas simultáneamente, el tráfico saliente puede alcanzar aproximadamente 300 Mbit/s, sin contar los datos de servicio.

Self-hosted y plataformas en la nube

Los servicios en la nube son más sencillos al principio: no es necesario actualizar el servidor, vigilar el disco, configurar SSL ni pagar aparte por el tráfico saliente. Al mismo tiempo, existen limitaciones de la plataforma: normas de contenido, comisiones, límites de API, registro obligatorio de los espectadores o falta de control total sobre las analíticas.

Owncast self-hosted requiere más administración, pero ofrece una arquitectura predecible. Puede integrar el reproductor en su sitio, cambiar el diseño, restringir el acceso mediante VPN o reverse proxy, almacenar la configuración localmente y trasladar la instalación entre servidores.

2. Qué configuración de VPS se necesita para esta tarea

El recurso principal para el live-streaming no son solo la CPU y la memoria, sino también la red saliente. Si Owncast no transcodifica el vídeo, el servidor principalmente recibe una señal RTMP y la distribuye a los espectadores. Si se activan perfiles de calidad adicionales o la transcodificación, la carga de la CPU aumenta considerablemente.

Configuración mínima

Para una transmisión de prueba y un canal privado pequeño, basta un VPS con 2 vCPU, 2 GB de RAM, un SSD de 30–40 GB y un puerto de red de 1 Gbit/s. Esta opción está pensada aproximadamente para 5–15 espectadores con una señal de 2–4 Mbit/s, siempre que el servidor no realice una transcodificación pesada.

Una opción inicial práctica para un canal público es 2–4 vCPU, 4 GB de RAM, un disco NVMe de 80 GB y al menos 1 TB de tráfico saliente mensual. Para una señal de 1080p con un bitrate de 5–8 Mbit/s, normalmente es suficiente para una comunidad pequeña, pero el límite real depende del plan, la red y el número de espectadores simultáneos.

Opción de VPS adecuada

Para la configuración descrita puede elegir un VPS adecuado con 4 vCPU, 8 GB de RAM, un disco NVMe de al menos 80 GB, IPv4 pública y un puerto de red de 1 Gbit/s. Compruebe no solo la velocidad del puerto, sino también el límite mensual de tráfico: 100 espectadores a 6 Mbit/s pueden utilizar alrededor de 2,2 TB de datos salientes durante 24 horas de transmisión continua.

Cuándo se necesita un servidor dedicated

Un servidor dedicated está justificado si el canal reúne regularmente a cientos de espectadores, se requieren varias transmisiones simultáneas, se realiza codificación dependiente del hardware o no se puede permitir la competencia por la CPU y la red con otras máquinas virtuales. También resulta útil para archivar un gran número de grabaciones y procesar vídeo.

Para un solo canal de Owncast, un dedicated normalmente es excesivo. Primero mida la CPU, la RAM, el tráfico saliente y la latencia. Conviene pasar a un servidor físico cuando aumentar el VPS ya no resuelva el problema o cuando el coste de los recursos garantizados sea comparable al de un dedicated.

Elección de la ubicación

Ubique el servidor cerca de la audiencia principal. La proximidad geográfica reduce la latencia al abrir el sitio y el riesgo de problemas de red, pero no elimina la carga derivada de distribuir el vídeo. Si los espectadores se encuentran en varias regiones, para escalar puede añadir un CDN para los recursos web o utilizar un media relay independiente; sin embargo, un CDN HTTP convencional no siempre realiza correctamente el proxy del flujo de vídeo en directo.

3. Preparación del servidor

A continuación se utiliza una instalación limpia de Ubuntu Server 24.04 LTS con un usuario creado durante la instalación. Todos los comandos se ejecutan mediante SSH con un usuario que tiene permisos sudo. Sustituya la dirección IP y el nombre de dominio por sus propios valores.

Actualización del sistema y utilidades básicas

Primero actualice el índice de paquetes y los componentes instalados. Es necesario reiniciar si se ha actualizado el kernel o las bibliotecas del sistema utilizadas por los servicios.

sudo apt update
sudo apt full-upgrade -y
sudo apt install -y ca-certificates curl gnupg git vim unzip jq htop ncdu
sudo reboot

Después de volver a conectarse, compruebe la versión del sistema operativo y la hora. Una hora incorrecta puede dificultar la comprobación de los certificados TLS y el funcionamiento del planificador de copias de seguridad.

cat /etc/os-release
timedatectl status
hostnamectl

Usuario administrativo independiente

No utilice root para el trabajo diario. Cree el usuario streamadmin, añádalo al grupo sudo e instale una clave SSH pública. Puede obtener la clave pública del archivo local ~/.ssh/id_ed25519.pub.

sudo adduser streamadmin
sudo usermod -aG sudo streamadmin
sudo install -d -m 700 -o streamadmin -g streamadmin /home/streamadmin/.ssh
sudo nano /home/streamadmin/.ssh/authorized_keys
sudo chown streamadmin:streamadmin /home/streamadmin/.ssh/authorized_keys
sudo chmod 600 /home/streamadmin/.ssh/authorized_keys

Abra un segundo terminal y asegúrese de que el acceso funciona:

ssh streamadmin@SERVER_IP

Después de comprobarlo, puede prohibir el acceso SSH de root y desactivar la autenticación mediante contraseña. No haga esto antes de comprobar la clave: de lo contrario, es fácil perder el acceso al servidor.

sudo install -d -m 755 /etc/ssh/sshd_config.d
printf 'PermitRootLogin no\nPasswordAuthentication no\nKbdInteractiveAuthentication no\n' | sudo tee /etc/ssh/sshd_config.d/99-hardening.conf
sudo sshd -t
sudo systemctl reload ssh

Firewall y fail2ban

Es necesario permitir SSH, HTTP, HTTPS y RTMP. El puerto SSH del ejemplo sigue siendo el estándar 22; si lo ha cambiado, sustituya la regla de UFW.

sudo apt install -y ufw fail2ban
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 1935/tcp
sudo ufw enable
sudo ufw status verbose

Fail2ban bloqueará los intentos repetidos de acceso SSH fallidos. Para una configuración básica basta con activar el jail del sistema:

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

El puerto 1935 solo es necesario para el RTMP entrante. No exponga el puerto administrativo de Owncast al exterior: estará disponible mediante el reverse proxy HTTPS y limitaremos el acceso directo a una dirección bind local.

4. Instalación del software — paso a paso

En 2026, para este tipo de implementación resulta conveniente utilizar Docker Engine y Docker Compose Plugin desde el repositorio oficial de Docker. Es mejor fijar la versión de Owncast mediante la etiqueta de la imagen, en lugar de utilizar latest sin restricciones. En el momento de preparar este ejemplo se utiliza la rama Owncast 0.2.x; antes de actualizar, compruebe la versión disponible en la documentación oficial y pruébela en una copia de los datos.

Adición del repositorio oficial de Docker

Primero elimine los paquetes en conflicto, si están instalados desde un repositorio antiguo de Ubuntu.

sudo apt remove -y docker.io docker-compose docker-doc podman-docker containerd runc || true

Los siguientes comandos instalan la clave del repositorio y conectan la fuente oficial de paquetes de Docker.

sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt update

Instale Docker Engine, Buildx y Compose Plugin. En el ejemplo se utiliza la sintaxis moderna docker compose, no el comando independiente obsoleto docker-compose.

sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
sudo systemctl enable --now docker
sudo docker version
sudo docker compose version

Agregar el usuario al grupo docker permite ejecutar Docker sin sudo, pero en la práctica otorga al usuario permisos de nivel root. En un servidor de producción independiente, esto solo es aceptable para un administrador de confianza.

sudo usermod -aG docker "$USER"
newgrp docker
docker run --rm hello-world

Creación de directorios de Owncast

Cree el directorio del proyecto y un directorio independiente para los datos. El directorio de datos debe conservarse al recrear el contenedor: contiene la configuración, los ajustes del usuario, los logotipos, el diseño y otros archivos permanentes de Owncast.

sudo mkdir -p /opt/owncast/{data,backups}
sudo chown -R "$USER:$USER" /opt/owncast
cd /opt/owncast

Archivo Docker Compose

Cree el archivo /opt/owncast/compose.yml. La imagen se ejecuta con el usuario del proceso del contenedor y los datos se montan en la ruta estándar /app/data. El puerto 8080 se publica únicamente en la interfaz loopback, por lo que no puede abrirse directamente desde Internet.

services:
  owncast:
    image: owncast/owncast:0.2.1
    container_name: owncast
    restart: unless-stopped
    environment:
      - TZ=UTC
    ports:
      - "127.0.0.1:8080:8080"
      - "1935:1935"
    volumes:
      - ./data:/app/data
    healthcheck:
      test: ["CMD", "wget", "-q", "-O", "-", "http://127.0.0.1:8080"]
      interval: 30s
      timeout: 10s
      retries: 5
      start_period: 30s

Antes de iniciarlo, descargue la imagen y compruebe la configuración de Compose:

docker compose config
docker compose pull
docker compose up -d
docker compose ps
docker compose logs --tail=100 owncast

Si la imagen con la etiqueta indicada no está disponible, no sustituya la etiqueta por una al azar. Abra la página de versiones de Owncast, seleccione la versión estable actual y modifique el campo image. Después del cambio, ejecute docker compose pull y reinicie el contenedor.

Instalación de Caddy

Caddy recibirá las solicitudes HTTPS, obtendrá automáticamente el certificado de Let’s Encrypt y reenviará las solicitudes a Owncast en el puerto local 8080. La instalación se realiza desde el repositorio oficial de Caddy.

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install -y caddy
sudo systemctl enable --now caddy
caddy version

5. Configuración de Owncast, el dominio y SSL

Registro DNS

En el registrador del dominio, cree un registro A:

Si utiliza IPv6 y se enruta correctamente al servidor, puede añadir un registro AAAA. No cree un registro AAAA si IPv6 no está configurado en el VPS: en ese caso, algunos espectadores recibirán una dirección inaccesible.

Puede comprobar el DNS desde el propio servidor o desde un ordenador local:

dig +short A stream.example.com
dig +short AAAA stream.example.com

Configuración inicial de Owncast

Abra la interfaz mediante la dirección local a través de un túnel SSH. Es más seguro que abrir temporalmente el puerto 8080 en el firewall externo:

ssh -L 8080:127.0.0.1:8080 streamadmin@SERVER_IP

Ahora abra http://127.0.0.1:8080 en el ordenador local. Durante el primer inicio, Owncast le ofrecerá realizar la configuración inicial. Indique el nombre del canal, la zona horaria, la contraseña del administrador, la descripción y otros parámetros. Utilice una contraseña única de al menos 20 caracteres.

La clave de transmisión no debe publicarse junto con la dirección de la transmisión. Cualquier persona que obtenga esta clave podrá enviar una transmisión a su canal. Después de una filtración, cambie la clave en el panel de administración de Owncast y actualice la configuración de OBS.

Proxy inverso mediante Caddy

Cree el archivo /etc/caddy/Caddyfile. Sustituya el dominio por el suyo. La directiva reverse_proxy reenvía las solicitudes HTTP al contenedor de Owncast, mientras que Caddy activa HTTPS automáticamente después de que el DNS empiece a apuntar al servidor y los puertos 80/443 estén disponibles.

stream.example.com {
    encode gzip zstd

    reverse_proxy 127.0.0.1:8080

    log {
        output file /var/log/caddy/owncast-access.log
        format json
    }

    header {
        Strict-Transport-Security "max-age=31536000"
        X-Content-Type-Options "nosniff"
        Referrer-Policy "strict-origin-when-cross-origin"
    }
}

Compruebe la sintaxis y aplique la configuración:

sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl reload caddy
sudo journalctl -u caddy -n 100 --no-pager

Al cabo de unos segundos, Caddy debería obtener el certificado. La comprobación de HTTPS se realiza con el comando:

curl -I https://stream.example.com
curl -sS https://stream.example.com | head

Se espera una respuesta HTTP/2 200 u otro código HTTP satisfactorio devuelto por la página actual de Owncast. Si Caddy informa de un error de ACME, compruebe el DNS, la hora del sistema, las reglas de UFW y la presencia de otro proceso en los puertos 80 o 443.

Configuración de OBS Studio

En OBS, abra la configuración de la transmisión y seleccione un servicio personalizado. En el campo del servidor, indique:

rtmp://stream.example.com/live

En el campo de la clave, pegue la Stream Key del panel de Owncast. Para la primera prueba, utilice un perfil moderado: H.264, 1920×1080 a 30 fotogramas por segundo y una tasa de bits de 4500–6000 Kbit/s. El audio AAC de 128–160 Kbit/s es compatible con la mayoría de los dispositivos.

Si la velocidad de Internet de subida del presentador es inestable, comience con 1280×720 y 2500–4000 Kbit/s. La transmisión debe contar con margen de velocidad: es recomendable que la velocidad real de subida sea como mínimo 1,5 veces superior a la tasa de bits elegida. En OBS, active la reconexión automática y establezca un búfer de reconexión de 10–20 segundos.

Comprobación de la configuración

Compruebe que el contenedor está en ejecución y tiene el estado healthy o funciona de forma estable sin reinicios cíclicos:

cd /opt/owncast
docker compose ps
docker inspect --format='{{json .State.Health}}' owncast | jq
docker compose logs --tail=200 owncast

Compruebe el backend local sin la participación de Caddy:

curl -I http://127.0.0.1:8080
ss -lntp | grep -E ':(80|443|1935|8080)\b'

La comprobación de los puertos externos desde otro nodo ayuda a detectar errores en el firewall:

nc -vz stream.example.com 80
nc -vz stream.example.com 443
nc -vz stream.example.com 1935

Después de iniciar OBS, abra la página pública de Owncast y compruebe que aparece el indicador de transmisión en directo, aumenta el número de espectadores y se reproduce el sonido. Si la página se abre, pero el vídeo no se inicia, compruebe primero los registros de Owncast y la consola del navegador.

6. Comprobación de la transmisión y diagnóstico

Una comprobación fiable debe incluir no solo la apertura de la página web, sino también la supervisión de los recursos durante la emisión. En una sesión SSH independiente, inicie la monitorización del contenedor:

docker stats owncast

Si la CPU se mantiene de forma estable cerca del 100 por ciento de uno o varios núcleos, probablemente se deba a la carga del procesamiento de vídeo o a un perfil demasiado exigente. Si falta memoria, Linux puede empezar a utilizar swap, lo que aumenta las latencias y crea el riesgo de que el contenedor se detenga.

Compruebe el espacio libre y el tamaño del directorio de datos:

df -h /
du -sh /opt/owncast/data
sudo du -xhd1 /var/lib/docker | sort -h

Supervise el tráfico saliente. Según el panel del proveedor, los datos pueden actualizarse con retraso, por lo que para una evaluación inmediata utilice herramientas del sistema o la monitorización de la interfaz. Si el canal tiene un límite de tráfico, configure con antelación alertas al alcanzar el 70–80 por ciento del límite mensual.

Evaluación del ancho de banda

El cálculo puede realizarse con la fórmula: la tasa de bits de la transmisión en Mbit/s se multiplica por el número de espectadores y después se añade un margen de aproximadamente el 15 por ciento. Por ejemplo, una transmisión de 6 Mbit/s para 40 espectadores requiere aproximadamente 276 Mbit/s de ancho de banda de subida:

6 × 40 × 1,15 = 276 Мбит/с

Para calcular el tráfico mensual, convierta la tasa de bits a gigabytes. Una transmisión de 6 Mbit/s que funciona continuamente durante un día transmite aproximadamente 64,8 GB sin tener en cuenta la sobrecarga del protocolo. Con 30 espectadores, son unos 1,9 TB al día, por lo que las emisiones públicas prolongadas deben planificarse por separado.

Comprobación de TLS

El certificado y la cadena pueden comprobarse mediante OpenSSL:

echo | openssl s_client -connect stream.example.com:443 -servername stream.example.com 2>/dev/null | openssl x509 -noout -issuer -subject -dates

Caddy renueva el certificado automáticamente. No ejecute Certbot en paralelo para el mismo dominio: dos gestores de certificados pueden entrar en conflicto debido a los puertos y al desafío ACME.

7. Copias de seguridad y mantenimiento

Qué es necesario guardar

El objeto principal de la copia de seguridad es /opt/owncast/data. Puede contener la configuración del canal, cambios personalizados en el diseño, datos del chat, configuración y otros archivos necesarios para restaurar la instalación. Guarde también /opt/owncast/compose.yml, /etc/caddy/Caddyfile y la lista de paquetes instalados.

No conviene copiar sin más todo el directorio /var/lib/docker: esto aumenta el tamaño de la copia de seguridad y vincula la restauración al formato interno de Docker. Restaure el proyecto mediante Compose y devuelva únicamente los datos persistentes necesarios.

Copia de seguridad sencilla mediante restic

Restic cifra las copias de seguridad antes de enviarlas al almacenamiento remoto. Como backend se puede utilizar un almacenamiento compatible con S3 o un servidor independiente. Instale el paquete:

sudo apt install -y restic
sudo install -d -m 700 /root/.config/restic
sudo nano /root/.config/restic/env
sudo chmod 600 /root/.config/restic/env

El archivo de entorno debe contener la dirección del repositorio, la contraseña y las claves de S3. Los valores siguientes son solo un ejemplo y deben sustituirse:

export RESTIC_REPOSITORY="s3:https://s3.example.net/owncast-backups"
export RESTIC_PASSWORD="GENERATE_A_LONG_RANDOM_PASSWORD"
export AWS_ACCESS_KEY_ID="S3_ACCESS_KEY"
export AWS_SECRET_ACCESS_KEY="S3_SECRET_KEY"

No debe perder la contraseña de Restic: sin ella no es posible restaurar el almacenamiento cifrado. Inicialice el repositorio una sola vez:

sudo bash -c 'source /root/.config/restic/env && restic init'

Cree el script /usr/local/sbin/owncast-backup. Antes de copiar, Compose se detiene temporalmente para que los datos no cambien durante la instantánea. Una breve interrupción es más segura que guardar un estado inconsistente.

sudo tee /usr/local/sbin/owncast-backup > /dev/null <<'EOF'
#!/usr/bin/env bash
set -Eeuo pipefail

source /root/.config/restic/env

PROJECT=/opt/owncast
STAGE=$(mktemp -d)
trap 'rm -rf "$STAGE"' EXIT

cd "$PROJECT"
docker compose stop owncast

mkdir -p "$STAGE/owncast-data" "$STAGE/config"
rsync -a --delete "$PROJECT/data/" "$STAGE/owncast-data/"
cp "$PROJECT/compose.yml" "$STAGE/config/compose.yml"
cp /etc/caddy/Caddyfile "$STAGE/config/Caddyfile"

docker compose start owncast

restic backup "$STAGE" --tag owncast
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check
EOF
sudo chmod 700 /usr/local/sbin/owncast-backup

Ejecute la prueba manualmente y asegúrese de que el contenedor vuelva a funcionar:

sudo /usr/local/sbin/owncast-backup
restic snapshots
docker compose -f /opt/owncast/compose.yml ps

Añada una ejecución diaria mediante un temporizador de systemd. El temporizador es preferible a cron, porque su estado y sus registros se pueden consultar mediante journalctl.

sudo tee /etc/systemd/system/owncast-backup.service > /dev/null <<'EOF'
[Unit]
Description=Backup Owncast data

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/owncast-backup
EOF

sudo tee /etc/systemd/system/owncast-backup.timer > /dev/null <<'EOF'
[Unit]
Description=Daily Owncast backup

[Timer]
OnCalendar=--* 03:15:00
Persistent=true

[Install]
WantedBy=timers.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now owncast-backup.timer
systemctl list-timers owncast-backup.timer

Comprobación de la restauración

Una copia de seguridad solo se considera válida después de una restauración de prueba. Obtenga la lista de instantáneas, seleccione un identificador y restaure el contenido en un directorio temporal sin sobrescribir production:

sudo bash -c 'source /root/.config/restic/env && restic snapshots'
sudo mkdir -p /tmp/owncast-restore
sudo bash -c 'source /root/.config/restic/env && restic restore SNAPSHOT_ID --target /tmp/owncast-restore'
sudo find /tmp/owncast-restore -maxdepth 4 -type f | sort | head -50

Compruebe periódicamente la restauración en un VPS independiente o durante una maintenance window. El repositorio de copias de seguridad debe estar fuera del servidor principal: un fallo del disco, la eliminación del VPS o la vulneración de root no deben destruir ambas copias.

Actualización de Owncast

Antes de actualizar, haga una copia de seguridad reciente y lea las release notes. Para una actualización planificada, detenga la transmisión, descargue la nueva imagen, vuelva a crear el contenedor y compruebe los registros:

cd /opt/owncast
sudo /usr/local/sbin/owncast-backup
docker compose pull
docker compose up -d
docker compose ps
docker compose logs --tail=200 owncast

Cambie la versión en compose.yml de forma consciente. El rolling update para un único contenedor de Owncast no está disponible en el sentido clásico: normalmente existe un breve periodo de indisponibilidad. Para minimizar el tiempo de inactividad, conserve de antemano el tag antiguo comprobado y no lo elimine hasta confirmar que la actualización se ha realizado correctamente.

Mantenimiento periódico

• Compruebe semanalmente el espacio disponible, el estado del contenedor y las últimas copias de seguridad.
• Realice mensualmente una restauración de prueba de parte de los datos.
• Actualice Ubuntu y Docker durante una ventana de mantenimiento independiente.
• Controle la fecha de vencimiento del dominio y la disponibilidad del DNS.
• Compruebe el consumo de tráfico saliente después de las transmisiones importantes.
• Cambie periódicamente la contraseña administrativa y la clave de transmisión si sospecha que se han filtrado.
• No almacene secretos en un repositorio Git público ni los inserte en un Dockerfile.

8. Solución de problemas y FAQ

¿Por qué el dominio se abre con el error «connection refused»?

Primero compruebe que el DNS apunta a la IP correcta: dig +short A stream.example.com. Después ejecute sudo systemctl status caddy, sudo ss -lntp y sudo ufw status. Caddy debe escuchar en los puertos 80 y 443, y Owncast en el puerto local 8080. Si el contenedor está detenido, consulte docker compose logs owncast. El error también aparece cuando queda un registro AAAA incorrecto en el DNS.

¿Por qué Caddy no puede obtener el certificado?

Los puertos 80 y 443 deben estar disponibles desde Internet, y el dominio ya debe resolverse hacia el VPS. Compruebe las reglas de UFW y el firewall externo del proveedor. Asegúrese de que otro servidor web no haya ocupado los puertos: sudo ss -lntp | grep -E ':(80|443)\b'. La causa detallada se encuentra en sudo journalctl -u caddy -n 200. No ejecute Caddy y Certbot simultáneamente para el mismo dominio.

OBS se conecta, pero la transmisión no aparece

Compruebe la dirección del servidor: normalmente es rtmp://stream.example.com/live, no la dirección HTTPS de la página. Asegúrese de que el puerto 1935 esté permitido en UFW y en el firewall externo. La clave de transmisión debe coincidir en Owncast y OBS. Después de iniciar OBS, ejecute docker compose logs -f owncast y compruebe si el servidor registra la conexión RTMP entrante. Si la clave se ha filtrado, cree una nueva.

El vídeo se almacena en búfer para los espectadores aunque la CPU esté libre

La causa más probable es una capacidad de salida insuficiente o un límite de tráfico. Calcule la tasa de bits multiplicada por el número de espectadores y compare el resultado con la velocidad garantizada del VPS. Compruebe la pérdida de paquetes y la ruta hacia varias redes. Reduzca la tasa de bits en OBS, por ejemplo de 6000 a 4000 Kbit/s, y vuelva a probar. Si el problema solo aparece en regiones remotas, considere utilizar un media relay o un servidor edge independiente.

¿Qué configuración mínima de VPS será adecuada?

Para una transmisión de prueba bastan 2 vCPU, 2 GB de RAM, un SSD de 40 GB y una IPv4 pública. Para transmisiones habituales con 20–80 espectadores, es mejor elegir 2–4 vCPU, 4 GB de RAM, un NVMe de 80 GB y un puerto de 1 Gbit/s con suficiente tráfico mensual. Estos valores suponen que Owncast no realiza una transcodificación pesada. Con varios perfiles de calidad se necesitarán CPU y memoria adicionales.

¿Qué elegir: VPS o dedicated para esta tarea?

El VPS es adecuado para la mayoría de los canales pequeños y medianos: es más fácil de escalar, trasladar y mantener, y su coste es menor. Un dedicated es necesario para cientos de espectadores simultáneos, varios canales, transcodificación continua, grandes archivos o requisitos de recursos garantizados. Tome la decisión basándose en mediciones de CPU, RAM, tráfico saliente y latencia de red, no solo en el número de núcleos.

El contenedor se reinicia constantemente. ¿Qué hay que comprobar?

Ejecute docker compose ps y docker compose logs --tail=300 owncast. Las causas frecuentes son una etiqueta de imagen incorrecta, un directorio de datos dañado, falta de espacio o permisos incorrectos en el volume. Compruebe df -h, df -i y los permisos de /opt/owncast/data. No elimine los datos de inmediato: primero detenga el contenedor y copie el directorio. Restaurar desde la última copia de seguridad funcional es más seguro que editar manualmente archivos desconocidos.

¿Se puede abrir Owncast sin dominio ni SSL?

Para una prueba temporal se puede acceder mediante la IP y el puerto local, pero para el uso público es mejor empezar solo después de configurar el dominio y HTTPS. Sin TLS, las contraseñas administrativas y otros datos se transmiten de forma insegura, y los navegadores pueden bloquear determinadas funciones. RTMP tampoco está cifrado de forma estándar, por lo que la clave de transmisión no puede considerarse protegida contra la interceptación. Para production, utilice HTTPS para la interfaz web y limite el acceso al panel.

9. Conclusiones y próximos pasos

Como resultado, Owncast funciona en un VPS mediante Docker, recibe la transmisión desde OBS, ofrece a los espectadores una página HTTPS a través de Caddy y obtiene automáticamente un certificado TLS. Los datos persistentes se han trasladado a un directorio independiente, mientras que las copias de seguridad se cifran con Restic y se envían a un almacenamiento externo.

A continuación, mida la carga real de CPU, la latencia y el tráfico saliente durante varias transmisiones. Después puede añadir la monitorización de Prometheus o Uptime Kuma, configurar un sistema independiente para almacenar las grabaciones y preparar un segundo servidor para la recuperación ante desastres. A medida que crezca la audiencia, planifique la separación del proxy web, el servidor ingest y la distribución del flujo multimedia.