Alojar Owncast en un VPS administrado: sus directos en su propio servidor

Qué hace Owncast

Owncast es un servidor de vídeo en directo y de chat de código abierto, autoalojado y de un solo usuario: una instancia lleva el canal de una persona o de una organización. Su README lo presenta como una forma de emitir sus propios directos, al estilo de las grandes plataformas generalistas, conservando la propiedad de su contenido, su interfaz, su moderación y su audiencia.

• La recepción: su software de emisión, como OBS, envía el flujo por RTMP, el protocolo que usan las principales plataformas de directo.
• La difusión: Owncast corta el vídeo en segmentos HLS, en una o varias calidades, y lo sirve en su página web. El flujo se reproduce también en VLC o mpv, en /hls/stream.m3u8.
• El chat: integrado en la página, con moderadores, expulsiones e inicio de sesión mediante el Fediverso o IndieAuth.
• El Fediverso: una cuenta de Mastodon puede seguir su servidor y recibir un aviso cada vez que empieza un directo. La versión 0.3.0 añade Featured Streams, que muestran los directos de otros servidores Owncast.
• La ampliación: webhooks, API y, desde la 0.3.0, plugins, instalados desde la administración con los permisos que usted les concede.

Lo que permite la licencia MIT

Owncast se publica bajo la licencia MIT. Concede, de forma gratuita, el derecho a usar, copiar, modificar, fusionar, publicar, distribuir, sublicenciar y vender copias del software. Puede, por tanto, ejecutarlo para su empresa, su comunidad o sus clientes, sin ninguna licencia que comprar.

La única condición es conservar el aviso de copyright y el texto de la licencia en todas las copias o partes sustanciales del software. El texto ofrece el software «tal cual», sin garantía.

Procesador y ancho de banda: dimensionar el servidor

La documentación lo dice de entrada: las necesidades dependen de su configuración. Plantea, eso sí, una regla clara para estimarlas. El procesador transcodifica el vídeo en las calidades que ofrece; el ancho de banda lo lleva hasta cada espectador.

• El número de espectadores no cambia la carga del procesador. El vídeo se codifica una vez y se sirve después a todos: con cero espectadores o con cien, el trabajo de codificación es el mismo. El chat añade un poco de carga, pequeña frente a la codificación.
• El ancho de banda crece con cada espectador. Cada espectador recibe su propia copia del flujo.
• Cada calidad transcodificada necesita procesador, tanto más cuanto más baja es la tasa de bits objetivo, ya que comprimir más exige más cálculo.

El ancho de banda del servidor

La documentación da dos fórmulas. El volumen de un directo, en gigabytes: tasa de bits en kbps × duración en segundos × espectadores ÷ 8.000.000. La velocidad de salida máxima que hay que sostener, en Mbps: tasa de bits en kbps × espectadores ÷ 1000. Con varias calidades, calcule cada una y súmelas. Sus estimaciones para un directo de dos horas:

En un VPS de Simafri, el tráfico no tiene contador mensual: sus directos se dimensionan según su tasa de bits máxima. A medida que crece su audiencia, el almacenamiento de objetos, que se trata más abajo, sirve el vídeo en lugar del servidor.

El procesador

La documentación da referencias medidas, precisando que varían según el códec, la tasa de bits, la resolución y el preajuste del codificador:

• Un núcleo por calidad: como regla aproximada, un solo núcleo de procesador puede encargarse a menudo de una calidad transcodificada a 30 imágenes por segundo.
• La frecuencia de imagen: 60 imágenes por segundo exigen unas dos veces el cálculo de 30, y 24 imágenes por segundo, unas 0,8 veces.
• El ajuste por defecto: Owncast arranca con una sola calidad, a 1200 kbps y 24 imágenes por segundo, con el audio transmitido tal cual. La documentación aconseja partir de ahí, probar y añadir después una calidad cuando el procesador tenga margen.

La documentación no da ninguna cifra de memoria, y el disco cuenta poco: los segmentos de vídeo se escriben y después se eliminan a medida que avanza el directo. Solo la carpeta data crece con el tiempo. En un VPS, el procesador se encarga de la codificación: cada calidad transcodificada se dimensiona en vCPU. En un VPS administrado, cuéntenos cómo son sus directos, su tasa de bits, sus calidades y su audiencia, y le recomendamos el tamaño adecuado.

Su conexión de emisión

Antes de llegar al servidor, el flujo sale de su propia conexión. La documentación pide una velocidad de subida de al menos 1,5 veces la tasa de bits del flujo: 7,5 Mbps para un flujo de 5000 kbps. Recomienda una conexión por cable antes que el wifi.

La instalación con Docker Compose

La documentación propone la imagen owncast/owncast de Docker Hub, que incluye ffmpeg, la herramienta de codificación que Owncast necesita. En un servidor con Docker instalado, cree una carpeta y coloque en ella este compose.yaml, tomado de la documentación:

services:
  owncast:
    image: owncast/owncast:latest
    restart: unless-stopped
    ports:
      - "127.0.0.1:8080:8080"
      - "1935:1935"
    volumes:
      - ./data:/app/data

docker compose up -d

• El puerto 8080 publicado en 127.0.0.1: es el único cambio respecto al ejemplo de la documentación, que publica los dos puertos. Su página sobre el proxy inverso pide no exponer Owncast directamente a internet, ya que escucha por defecto en todas las interfaces, y Docker publica un puerto en todas las direcciones del servidor cuando no se le indica ninguna. La interfaz web solo es accesible entonces a través del proxy inverso.
• El puerto 1935 recibe el flujo por RTMP. Sigue siendo público, porque su software de emisión llega a él directamente, sin pasar por el proxy.
• La carpeta data guarda la base de datos y sus copias en el servidor, fuera del contenedor: es lo que se copia y se traslada.
• La etiqueta latest sigue la versión más reciente; 0.3.0 fija una versión.

Sin Docker: el instalador oficial

La otra vía de la documentación es un script que descarga la última versión de Owncast para su plataforma, y ffmpeg si aún no está instalado. Lo instala todo en una carpeta owncast dentro de la carpeta actual. La documentación desaconseja ejecutarlo como root y recomienda leer cualquier script remoto antes de ejecutarlo:

curl -s https://owncast.online/install.sh | bash

Para que Owncast arranque con el servidor y se reinicie por sí solo tras un fallo, la documentación ofrece un servicio systemd, que hay que adaptar a la carpeta y a la cuenta elegidas:

[Unit]
Description=Owncast
After=network.target

[Service]
Type=simple
WorkingDirectory=/opt/owncast
ExecStart=/opt/owncast/owncast
User=owncast
Group=owncast
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now owncast

Contraseña de administración y clave de emisión

La administración está en /admin. Owncast arranca con unos accesos que todo el mundo conoce, y la documentación pide cambiarlos en el primer inicio de sesión:

Para hacer este cambio antes de abrir la interfaz al público, pase por un túnel SSH: el puerto 8080 del servidor aparece en su ordenador, en http://localhost:8080/admin. Añada -p y el puerto SSH que figura en su área de cliente.

ssh -L 8080:127.0.0.1:8080 user@live.example.com

• La contraseña de administración se cambia en «Configuration», «Server Setup». Necesita de 8 a 192 caracteres, al menos una minúscula, una mayúscula, una cifra y un carácter especial entre !@#$%^&*, y ningún guion.
• Las claves de emisión se gestionan en la pestaña «Stream Keys» de la misma página. Owncast propone una clave de 30 caracteres generada automáticamente, y puede tener varias, cada una con un comentario: una clave entregada a un coanfitrión puede revocarse después sin tocar las demás.
• Una contraseña olvidada se sustituye al arrancar con la opción --adminpassword, que la guarda en la base de datos.

La contraseña de administración y la clave de emisión empiezan las dos con el valor abc123, pero son dos ajustes distintos: cambie ambos.

HTTPS: el proxy inverso

Owncast no gestiona HTTPS por sí mismo. La documentación coloca delante un proxy inverso, que escucha en los puertos 80 y 443, obtiene el certificado, cifra el tráfico y lo transmite sin cifrar a Owncast en el puerto 8080. Sin HTTPS, los navegadores marcan la página como no segura, y una página servida en HTTPS no puede insertar su vídeo ni su chat.

• El proxy transmite todas las rutas, incluida la conexión WebSocket en /ws, que lleva el chat. Un proxy que la bloquea corta el chat.
• RTMP no pasa por el proxy: su software de emisión envía directamente al puerto 1935 de Owncast.
• La dirección real de los visitantes: Owncast lee la cabecera X-Forwarded-For para bloquear la dirección IP de un usuario expulsado del chat. La documentación pide que sea el propio proxy quien defina esta cabecera.

Con Caddy

La documentación sugiere Caddy si no tiene otra preferencia: obtiene por sí mismo un certificado de Let’s Encrypt y transmite WebSocket sin ningún ajuste adicional. Este es su ejemplo de Caddyfile, en el que la línea tls indica la dirección de correo de la cuenta de Let’s Encrypt:

live.example.com {
  encode gzip
  reverse_proxy 127.0.0.1:8080
  tls contact@example.com
}

Con Nginx

Con Nginx, la documentación insiste en WebSocket: olvidarlo es lo que desactiva el chat. Añada este bloque map a la sección http de /etc/nginx/nginx.conf:

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

Este bloque de sitio sigue el de la documentación, en el puerto 80 para que Certbot pueda instalar HTTPS:

server {
    listen 80;
    listen [::]:80;
    server_name live.example.com;

    location / {
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_set_header Authorization $http_authorization;
        proxy_pass_header Authorization;
        proxy_pass http://127.0.0.1:8080;
    }
}

sudo nginx -t
sudo certbot --nginx

Emitir por RTMP desde OBS

Owncast acepta cualquier software que emita por RTMP hacia un servidor remoto. La clave solo se acepta en la ruta /live. En OBS:

1. Abra «Ajustes» y después «Emisión», y elija «Personalizado» como servicio.
2. Introduzca la dirección rtmp://live.example.com:1935/live.
3. Introduzca su clave de emisión, la de la pestaña «Stream Keys» de Owncast.
4. Inicie la emisión.

Un software sin campo para la clave acepta la dirección completa, rtmp://live.example.com:1935/live/your-key.

En un VPS de Simafri, la dirección IPv6 del servidor puede abrir el puerto que elija: su software de emisión llega al puerto 1935 por esa dirección, con un nombre que lleva el registro AAAA. En una red Docker IPv4, como aquí, Docker dirige al contenedor el puerto de la dirección IPv6 del servidor. Abra ese puerto si ufw está activo y pruebe después desde su ordenador:

sudo ufw allow 1935/tcp
nc -6 -vz live.example.com 1935

Para cualquier otra necesidad, cuéntenos lo que tiene en mente y estudiamos con usted el direccionamiento.

Los ajustes de su software de emisión

• Los códecs: H.264 para el vídeo y AAC para el audio, los únicos con los que la transcodificación y la compatibilidad de reproducción están garantizadas.
• El intervalo de fotogramas clave: uno cada 2 segundos, nunca en «auto». En OBS el intervalo se expresa en segundos, así que 2.
• La tasa de bits: envíe lo que piensa ofrecer, no más. Si su servidor sostiene 720p a 2500 kbps, no le envíe 1080p a 6000 kbps: cada conversión que pide añade carga al procesador.

Las calidades de vídeo y la latencia

Las calidades que se ofrecen a los espectadores se ajustan en «Configuration», «Video». Varias calidades permiten al reproductor elegir la que su conexión puede sostener: la documentación recomienda una segunda calidad, de 1000 a 2000 kbps, junto a una calidad alta de 4000 a 6000 kbps, una vez probada su primera configuración.

• La tasa de bits: de 400 a 13.000 kbps, en pasos de 100.
• La frecuencia de imagen: de 24 a 120 imágenes por segundo, 24 por defecto.
• La resolución: cambie el ancho o el alto, no ambos, y Owncast conserva la relación de aspecto.
• El uso del procesador: cinco niveles. Cuanto más alto es el nivel, mejor es la imagen, o más ligero el archivo a igual calidad.

El paso directo (passthrough) transmite el vídeo entrante sin recodificarlo: ahorra casi todo el procesador de esa calidad e ignora sus ajustes de tasa de bits, resolución y frecuencia de imagen. La documentación lo reserva a los usuarios avanzados: los espectadores reciben exactamente lo que envía su software, que algunos reproductores no saben leer, y la latencia aumenta. Pruebe la reproducción en los dispositivos que le importan antes de confiar en él.

La latencia se ajusta con el búfer de latencia, en la misma página. Cada nivel cambia un poco de retraso por estabilidad, y un cambio se aplica a partir del siguiente directo:

La versión 0.3.0 añade también, del lado del espectador, la opción «Minimize latency» del reproductor, que acelera ligeramente la reproducción para acercarse al directo, y un ajuste de reproducción automática, desactivado por defecto.

El almacenamiento de objetos para servir a más espectadores

Owncast puede enviar sus segmentos de vídeo a un almacenamiento compatible con S3, desde el que los espectadores los descargan. El servidor sigue sirviendo la lista de reproducción principal, las API y el chat; el vídeo, que representa casi todo el ancho de banda, sale del almacenamiento. Su servidor envía entonces una sola copia de cada calidad: en el ejemplo de la documentación, 6,5 Mbps para dos calidades a 5000 y 1500 kbps, tenga cero espectadores o mil. La carga del procesador sigue siendo la misma.

1. Cree un bucket con su proveedor de almacenamiento de objetos.
2. Hágalo legible públicamente y defina una política CORS si el proveedor la exige: un error CORS o Access-Control-Allow-Origin en la consola del navegador procede casi siempre de ahí.
3. En «Configuration», «Server Setup», pestaña «S3 Object Storage», active el almacenamiento e introduzca el nombre del bucket, la clave de acceso, la clave secreta, el endpoint y la región. Todos estos campos son obligatorios.

Este almacenamiento sirve el directo, no un archivo: Owncast elimina sobre la marcha los segmentos más antiguos que la lista de reproducción, más un margen de unos 20 segmentos. El bucket solo guarda los últimos minutos del directo.

Para espectadores repartidos por todo el mundo, la documentación describe también una red de distribución de contenidos (CDN) colocada delante de Owncast, con un nombre de host de origen aparte y el ajuste «Websocket host override», que mantiene el chat conectado al servidor de origen.

El chat y la moderación

El chat se configura en «Configuration», «Chat». Por defecto no hay ningún moderador: la documentación sugiere, como mínimo, nombrarse uno mismo moderador, desde la página «Users» de la administración.

• Los moderadores ocultan un mensaje o expulsan a un usuario desde el propio chat. No tienen acceso a la administración.
• Una expulsión desconecta al usuario, elimina sus mensajes y bloquea su dirección IP conocida. Puede levantarse más adelante; eliminar un usuario, en cambio, es definitivo.
• Solo usuarios consolidados: este ajuste bloquea los mensajes de las cuentas con menos de 15 minutos de antigüedad, salvo los moderadores.
• El filtro de lenguaje rechaza los mensajes ofensivos, con una lista interna de palabras.
• La autenticación obligatoria solo deja enviar mensajes a los usuarios autenticados, mediante una cuenta del Fediverso o IndieAuth, y a los moderadores.
• El limitador de frecuencia, activo por defecto, permite aproximadamente un mensaje cada dos tercios de segundo y bloquea durante 10 segundos a quien inunda el chat.

La documentación señala que el bloqueo por IP puede eludirse, con una VPN por ejemplo: reduce los abusos, y la moderación sigue siendo el trabajo propio de cada canal. De ahí el interés de nombrar moderadores para sus directos más vistos.

Las copias de seguridad

Owncast hace copia de su propia base de datos una vez por hora, en data/backup/owncastdb.bak. La opción --backupdir cambia esa carpeta. Esto es lo que contiene la carpeta de datos:

Para una recuperación completa, o para trasladar la instancia, la documentación pide copiar toda la carpeta data: copiarla en una nueva instalación se lo lleva todo. Con Docker, con el servicio detenido:

docker compose down
tar -czf owncast-$(date +%F).tar.gz data
docker compose up -d

Programe esta copia al ritmo de sus directos y envíela fuera del servidor. Colocados en su disco, estos archivos entran también en sus copias de seguridad nocturnas.

Restaurar la base de datos

Una restauración devuelve la base de datos al momento de la copia: todo lo que ha cambiado desde entonces se pierde. Copie primero la base actual en un lugar seguro y después:

1. Detenga Owncast.
2. Arranque Owncast con --restoreDatabase y la ruta del archivo de copia: restaura la base y se cierra.
3. Arranque Owncast con normalidad y compruebe después sus ajustes en la administración.

docker compose stop
docker compose run --rm owncast --restoreDatabase data/backup/owncastdb.bak
docker compose up -d

Las actualizaciones

Con Docker, la documentación da dos comandos, que se ejecutan desde la carpeta del compose.yaml. La carpeta de datos se queda en su sitio:

docker compose pull
docker compose up -d

Con el instalador, las notas de la versión 0.3.0 describen la actualización: detenga el servicio, aparte los archivos de la interfaz web que haya personalizado, vuelva a ejecutar el instalador con la cuenta que ejecuta Owncast y reinicie. El propio script guarda un archivo de la carpeta data en owncast-install-backups antes de sustituir la versión.

sudo systemctl stop owncast
su -c "curl https://owncast.online/install.sh | bash" owncast
sudo systemctl start owncast

La versión 0.3.0, publicada el 3 de septiembre de 2026, trae los plugins, Featured Streams, la reproducción automática y la elección de la interfaz en la que escucha RTMP. Sus notas piden leer los cambios antes de actualizar, ya que afectan a su instancia: siga estas notas en cada versión y copie la carpeta data justo antes.

Quién hace qué en un VPS administrado

El autoalojamiento exige mantener el servidor además de la aplicación. En un VPS administrado, nuestros equipos se encargan del servidor y siguen su instancia de forma proactiva; Owncast sigue siendo su software, con sus ajustes y sus datos.

Si prefiere que nuestros equipos intervengan en la propia aplicación, ese servicio se factura por horas o a precio cerrado, con un presupuesto comunicado antes de la intervención.