Héberger Owncast sur un VPS infogéré : vos directs vidéo sur votre serveur

Ce que fait Owncast

Owncast est un serveur de diffusion vidéo en direct et de chat, open source, auto-hébergé et mono-utilisateur : une instance porte la chaîne d'une personne ou d'une organisation. Son README le présente comme une façon de tenir ses propres directs, dans l'esprit des grandes plateformes, en gardant la maîtrise du contenu, de l'interface, de la modération et du public.

• La réception : votre logiciel de diffusion, OBS par exemple, envoie le direct en RTMP, le protocole des grandes plateformes de streaming.
• La diffusion : Owncast découpe la vidéo en segments HLS, en une ou plusieurs qualités, et la sert sur sa page web. Le flux se lit aussi dans VLC ou mpv, à l’adresse /hls/stream.m3u8.
• Le chat : intégré à la page, avec modérateurs, bannissements et authentification par le Fediverse ou IndieAuth.
• Le Fediverse : un compte Mastodon peut suivre votre serveur et être prévenu de chaque direct. La version 0.3.0 ajoute les flux mis en avant, qui affichent les directs d’autres serveurs Owncast.
• L’extension : webhooks, API, et depuis la 0.3.0 des plugins, qui s’installent depuis l’administration avec les permissions que vous leur accordez.

Ce que permet la licence MIT

Owncast est publié sous licence MIT. Elle accorde gratuitement le droit d'utiliser, de copier, de modifier, de fusionner, de publier, de distribuer, de sous-licencier et de vendre des copies du logiciel. Vous pouvez donc le faire tourner pour votre entreprise, votre communauté ou vos clients, sans licence à acheter.

La seule condition est de garder la notice de copyright et le texte de la licence dans toute copie ou partie substantielle du logiciel. Le texte fournit le logiciel « tel quel », sans garantie.

Processeur et bande passante : dimensionner le serveur

La documentation le dit d'emblée : les besoins dépendent de votre configuration. Elle pose une règle claire pour les estimer. Le processeur transcode la vidéo dans les qualités que vous proposez ; la bande passante la distribue à chaque spectateur.

• Le nombre de spectateurs ne change pas la charge du processeur. La vidéo est encodée une fois, puis servie à tous : zéro ou cent spectateurs, le travail d'encodage est le même. Le chat ajoute un peu de charge, faible à côté de l'encodage.
• La bande passante croît avec chaque spectateur. Chacun reçoit sa propre copie du flux.
• Chaque qualité transcodée demande du processeur, d'autant plus que le débit visé est bas, car compresser davantage coûte plus de calcul.

La bande passante du serveur

La documentation donne deux formules. Le volume d'un direct, en gigaoctets : débit en kbit/s × durée en secondes × spectateurs ÷ 8 000 000. Le débit de pointe à tenir en sortie, en Mbit/s : débit en kbit/s × spectateurs ÷ 1 000. Avec plusieurs qualités, calculez chacune et additionnez. Ses estimations pour un direct de deux heures :

Sur un VPS Simafri, le trafic n'a pas de compteur mensuel : vos directs se dimensionnent sur leur débit de pointe. Quand l'audience grandit, le stockage objet, présenté plus bas, sert la vidéo à la place du serveur.

Le processeur

La documentation donne des repères mesurés, en précisant qu'ils varient selon le codec, le débit, la résolution et le préréglage d'encodage :

• Un cœur par qualité : en règle approximative, un cœur de processeur tient souvent une qualité transcodée à 30 images par seconde.
• La cadence d'images : 60 images par seconde demandent environ deux fois le calcul de 30, et 24 images par seconde environ 0,8 fois.
• Le réglage par défaut : Owncast démarre avec une seule qualité, à 1 200 kbit/s et 24 images par seconde, son audio transmis tel quel. La documentation conseille de partir de là, de tester, puis d'ajouter une qualité quand le processeur a de la marge.

La mémoire n'est pas chiffrée par la documentation, et le disque compte peu : les segments vidéo sont écrits puis effacés au fil du direct. Seul le dossier data grandit avec le temps. Sur un VPS, c'est le processeur qui encode : chaque qualité transcodée se dimensionne en vCPU. Sur un VPS infogéré, décrivez-nous vos directs, leur débit, leurs qualités et votre audience, et nous vous recommandons la taille qui convient.

Votre connexion de diffusion

Avant d'atteindre le serveur, le direct part de votre connexion. La documentation demande un débit montant d'au moins 1,5 fois le débit du flux : 7,5 Mbit/s pour un flux à 5 000 kbit/s. Elle recommande une connexion filaire plutôt que le Wi-Fi.

L'installation avec Docker Compose

La documentation propose l'image owncast/owncast de Docker Hub, qui contient ffmpeg, l'outil d'encodage dont Owncast a besoin. Sur un serveur où Docker est installé, créez un dossier et placez-y ce compose.yaml, tiré de la documentation :

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

• Le port 8080 publié sur 127.0.0.1 : c'est le seul écart avec l'exemple de la documentation, qui publie les deux ports. Sa page sur les proxys inverses demande de garder Owncast hors d'Internet, car il écoute sur toutes les interfaces par défaut, et Docker publie un port sur toutes les adresses du serveur s'il n'en reçoit aucune. L'interface web s'atteint alors par le seul proxy inverse.
• Le port 1935 reçoit le direct en RTMP. Il reste public, car votre logiciel de diffusion l'atteint directement, sans passer par le proxy.
• Le dossier data garde la base de données et ses sauvegardes sur le serveur, hors du conteneur : c'est lui qui se sauvegarde et se déplace.
• L'étiquette latest suit la dernière version publiée ; 0.3.0 fixe une version.

Sans Docker : l'installateur officiel

L'autre voie de la documentation est un script qui télécharge la dernière version d'Owncast pour votre plateforme, et ffmpeg s'il n'est pas déjà présent. Il installe tout dans un dossier owncast, sous le dossier courant. La documentation déconseille de le lancer en root et recommande de lire un script distant avant de l'exécuter :

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

Pour qu'Owncast démarre avec le serveur et redémarre seul après un arrêt, la documentation fournit un service systemd, à adapter au dossier et au compte choisis :

[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

Mot de passe et clé de diffusion

L'administration se trouve sur /admin. Owncast démarre avec des identifiants connus de tous, que la documentation demande de changer dès la première connexion :

Pour faire ce changement avant d'ouvrir l'interface au public, passez par un tunnel SSH : le port 8080 du serveur apparaît sur votre poste, à l'adresse http://localhost:8080/admin. Ajoutez -p et le port SSH affiché dans votre espace client.

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

• Le mot de passe d'administration se change dans « Configuration », « Server Setup ». Il compte de 8 à 192 caractères, au moins une minuscule, une majuscule, un chiffre et un caractère spécial parmi !@#$%^&*, et aucun tiret.
• Les clés de diffusion se gèrent dans l'onglet « Stream Keys » de la même page. Owncast propose une clé de 30 caractères générée pour vous, et vous pouvez en garder plusieurs, chacune avec un commentaire : une clé pour un coanimateur se retire ensuite sans toucher aux autres.
• Un mot de passe perdu se remplace au démarrage avec l'option --adminpassword, qui l'enregistre dans la base.

Le mot de passe d'administration et la clé de diffusion valent tous deux abc123 au départ, mais ce sont deux réglages distincts : changez les deux.

HTTPS : le proxy inverse

Owncast ne gère pas HTTPS lui-même. La documentation place devant lui un proxy inverse, qui écoute sur les ports 80 et 443, obtient le certificat, chiffre le trafic et transmet en clair à Owncast sur le port 8080. Sans HTTPS, les navigateurs signalent la page comme non sécurisée, et une page en HTTPS ne peut pas intégrer votre vidéo ni votre chat.

• Le proxy transmet tous les chemins, dont la connexion WebSocket de /ws, qui porte le chat. Un proxy qui la bloque coupe le chat.
• RTMP ne passe pas par le proxy : votre logiciel de diffusion envoie directement au port 1935 d'Owncast.
• L'adresse réelle des visiteurs : Owncast lit l'en-tête X-Forwarded-For pour bloquer l'adresse IP d'un utilisateur banni du chat. La documentation demande que le proxy pose lui-même cet en-tête.

Avec Caddy

La documentation suggère Caddy si vous n'avez pas d'autre préférence : il obtient seul un certificat Let's Encrypt et transmet WebSocket sans réglage. Voici son exemple de Caddyfile, où la ligne tls donne l'adresse e-mail du compte Let's Encrypt :

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

Avec Nginx

Avec Nginx, la documentation insiste sur WebSocket : c'est l'oubli qui désactive le chat. Ajoutez ce bloc map dans la section http de /etc/nginx/nginx.conf :

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

Ce bloc de site reprend celui de la documentation, sur le port 80 pour laisser Certbot poser 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

Diffuser en RTMP depuis OBS

Owncast accepte tout logiciel qui diffuse en RTMP vers un serveur distant. La clé n'est acceptée que sur le chemin /live. Dans OBS :

1. Ouvrez « Paramètres », puis « Stream », et choisissez « Personnalisé » comme service.
2. Saisissez l’adresse rtmp://live.example.com:1935/live.
3. Saisissez votre clé de diffusion, celle de l’onglet « Stream Keys » d’Owncast.
4. Lancez le direct.

Un logiciel sans champ pour la clé accepte l'adresse complète, rtmp://live.example.com:1935/live/votre-cle.

Sur un VPS Simafri, l'adresse IPv6 du serveur peut ouvrir le port de votre choix : votre logiciel de diffusion atteint le port 1935 par cette adresse, sous un nom qui porte l'enregistrement AAAA. Sur un réseau Docker en IPv4, comme ici, Docker relie le port de l'adresse IPv6 du serveur au conteneur. Ouvrez ce port si ufw est actif, puis testez depuis votre poste :

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

Pour un autre besoin, dites-nous ce que vous visez, nous regardons l'adressage avec vous.

Les réglages de votre logiciel de diffusion

• Les codecs : H.264 pour la vidéo et AAC pour l'audio, les seuls dont le transcodage et la lecture sont assurés.
• L'intervalle d'images clés : une toutes les 2 secondes, jamais sur « auto ». Dans OBS, l'intervalle se compte en secondes, donc 2.
• Le débit : envoyez ce que vous comptez offrir, pas davantage. Si votre serveur tient 720p à 2 500 kbit/s, ne lui envoyez pas du 1080p à 6 000 kbit/s : chaque conversion demandée charge le processeur.

Les qualités vidéo et la latence

Les qualités proposées aux spectateurs se règlent dans « Configuration », « Video ». Plusieurs qualités permettent au lecteur de choisir celle que sa connexion tient : la documentation recommande une seconde qualité, de 1 000 à 2 000 kbit/s, à côté d'une haute qualité de 4 000 à 6 000 kbit/s, une fois la première configuration testée.

• Le débit : de 400 à 13 000 kbit/s, par pas de 100.
• La cadence : de 24 à 120 images par seconde, 24 par défaut.
• La résolution : changez la largeur ou la hauteur, pas les deux, et Owncast garde les proportions.
• L'usage du processeur : cinq niveaux. Plus il est élevé, meilleure est l'image, ou plus petit le fichier à qualité égale.

Le passthrough transmet la vidéo reçue sans la réencoder : il économise presque tout le processeur de cette qualité, et ignore ses réglages de débit, de résolution et de cadence. La documentation le réserve aux utilisateurs avertis : les spectateurs reçoivent exactement ce qu'envoie votre logiciel, ce que certains lecteurs ne savent pas lire, et la latence augmente. Testez la lecture sur les appareils qui comptent pour vous avant de vous y fier.

La latence se règle par le tampon de latence, sur la même page. Chaque niveau échange un peu de délai contre de la stabilité, et un changement s'applique au direct suivant :

La version 0.3.0 ajoute aussi, côté spectateur, l'option « Minimize latency » du lecteur, qui accélère légèrement la lecture pour se rapprocher du direct, et un réglage de lecture automatique, désactivé par défaut.

Le stockage objet pour servir plus de spectateurs

Owncast peut envoyer ses segments vidéo vers un stockage compatible S3, d'où les spectateurs les téléchargent. Le serveur continue de servir la liste de lecture principale, les API et le chat ; la vidéo, qui fait presque toute la bande passante, part du stockage. Votre serveur n'envoie alors qu'une copie de chaque qualité : dans l'exemple de la documentation, 6,5 Mbit/s pour deux qualités à 5 000 et 1 500 kbit/s, que vous ayez zéro ou mille spectateurs. Le processeur, lui, garde la même charge.

1. Créez un compartiment chez votre fournisseur de stockage objet.
2. Rendez-le lisible publiquement, et posez une règle CORS si le fournisseur en demande une : une erreur CORS ou Access-Control-Allow-Origin dans la console du navigateur vient presque toujours de là.
3. Dans « Configuration », « Server Setup », onglet « S3 Object Storage », activez le stockage et saisissez le nom du compartiment, la clé d’accès, la clé secrète, le point d’accès et la région. Tous ces champs sont obligatoires.

Ce stockage sert le direct, pas l'archive : Owncast efface au fil de l'eau les segments plus anciens que la liste de lecture, plus une vingtaine de segments de marge. Le compartiment ne garde que les dernières minutes du flux.

Pour des spectateurs répartis dans le monde, la documentation décrit aussi un réseau de diffusion de contenu (CDN) placé devant Owncast, avec un nom d'origine distinct et le réglage « Websocket host override », qui garde le chat relié au serveur d'origine.

Le chat et sa modération

Le chat se règle dans « Configuration », « Chat ». Par défaut, il n'y a aucun modérateur : la documentation conseille au moins de vous nommer vous-même, depuis la page « Users » de l'administration.

• Les modérateurs masquent un message ou bannissent un utilisateur depuis le chat lui-même. Ils n'ont pas accès à l'administration.
• Le bannissement déconnecte l'utilisateur, retire ses messages et bloque son adresse IP connue. Il se lève ensuite ; la suppression d'un utilisateur, elle, est définitive.
• Les utilisateurs établis : ce réglage refuse les messages des comptes de moins de 15 minutes, modérateurs exceptés.
• Le filtre de langage rejette les messages injurieux, à partir d'une liste interne.
• L'authentification obligatoire réserve l'écriture aux utilisateurs authentifiés, par un compte du Fediverse ou par IndieAuth, et aux modérateurs.
• La limite de débit, active par défaut, accepte environ un message tous les deux tiers de seconde et bloque 10 secondes celui qui inonde le chat.

La documentation rappelle que le blocage d'adresse IP se contourne, avec un VPN par exemple : il freine les abus, et la modération reste l'affaire de chaque chaîne. D'où l'intérêt de modérateurs nommés pour vos directs les plus suivis.

Les sauvegardes

Owncast sauvegarde sa base de données lui-même, une fois par heure, dans data/backup/owncastdb.bak. L'option --backupdir change ce dossier. Voici ce que contient le dossier de données :

Pour une reprise complète, ou pour déplacer l'instance, la documentation demande de sauvegarder tout le dossier data : le copier sur une nouvelle installation emporte tout. Avec Docker, service arrêté :

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

Planifiez cette copie au rythme de vos directs, et envoyez-la hors du serveur. Posées sur son disque, ces archives entrent aussi dans ses sauvegardes de nuit.

Restaurer la base

La restauration ramène la base à l'heure de la sauvegarde : tout changement postérieur est perdu. Copiez d'abord la base actuelle en lieu sûr, puis :

1. Arrêtez Owncast.
2. Lancez Owncast avec --restoreDatabase et le chemin du fichier de sauvegarde : il restaure la base, puis s’arrête.
3. Redémarrez Owncast normalement, puis vérifiez vos réglages dans l’administration.

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

Les mises à jour

Avec Docker, la documentation donne deux commandes, depuis le dossier du compose.yaml. Le dossier de données reste en place :

docker compose pull
docker compose up -d

Avec l'installateur, la note de la version 0.3.0 décrit la mise à jour : arrêtez le service, mettez de côté les fichiers de l'interface web que vous avez personnalisés, relancez l'installateur avec le compte qui fait tourner Owncast, puis redémarrez. Le script range lui-même une archive du dossier data dans owncast-install-backups avant de remplacer la version.

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

La version 0.3.0 du 3 septembre 2026 apporte les plugins, les flux mis en avant, la lecture automatique et le choix de l'interface d'écoute de RTMP. Sa note demande de lire les changements avant de mettre à jour, car ils touchent votre instance : suivez ces notes à chaque version, et faites une copie du dossier data juste avant.

Qui fait quoi sur un VPS infogéré

L'auto-hébergement demande de tenir le serveur en plus de l'application. Sur un VPS infogéré, nos équipes prennent le serveur en main et suivent votre instance de manière proactive ; Owncast reste votre logiciel, avec ses réglages et ses données.

Si vous préférez que nos équipes interviennent dans l'application elle-même, cette prestation se facture à l'heure ou au forfait, avec un chiffrage communiqué avant l'intervention.