Self-Host Visio with Greffon
A video call is one of the most personal things you route through someone else's servers. Here is the honest setup for Visio, the DINUM video conferencing app, on a greffer you own.
Every video call you make on a hosted service runs your face, your voice, and whatever is on your screen through someone else's infrastructure. Visio is the video conferencing app from La Suite numerique (DINUM, the French government's digital service), built on LiveKit. Grafting it onto a greffer puts the meeting server, the recordings, and the accounts on hardware you own. Greffon wires up the TLS and routing. This post is the honest version of that setup, because Visio is one of the heavier things in the catalog and it has one real sharp edge.
Why own the meetings
Visio bundles a full conferencing stack: a web frontend, a Django backend, an embedded Keycloak for login, a LiveKit media server, MinIO for recordings, Postgres, and the workers that tie them together. Running it yourself means the rooms, the user list, and any recorded media live on your greffer rather than a SaaS account. For a team or a family that does not want its calls passing through a third party, that is the whole point.
Graft it from the catalog
Pick Visio from the catalog and graft it onto your greffer. Greffon generates the secrets it needs (database password, object storage keys, the LiveKit API secret, the Keycloak admin password) and wires TLS and routing for the web UI, so you reach it over HTTPS. The gateway, signaling WebSocket, and recordings all travel over that one HTTP front door.
It is a heavy app, and the first boot shows it
This is not a single small container. Visio is roughly ten services plus a WebRTC media server. The first start pulls several gigabytes of images and takes a few minutes before the UI comes up, and the running set wants real memory and CPU headroom. A 1 GB micro instance will struggle. Give it a greffer with a few gigabytes of RAM and some disk to spare, and do the first boot when you can wait it out rather than in front of people you invited to a call.
The UDP media port, and why it needs a public IP
Here is the sharp edge. The web UI, login, and signaling are all ordinary HTTP, so they ride Greffon's routing (and the built-in Stem tunnel) like any other web app. But the actual audio and video does not. LiveKit carries media over a UDP port published directly on the host, and your participants' browsers have to reach that UDP port to send and receive video.
Greffon exposes that port through L4 proxy-mode, so on a greffer with a public IP the media port is reachable and calls work end to end. The catch: the Stem tunnel carries HTTP and TCP, not UDP yet. So if your greffer sits behind NAT or CGNAT with no public IP, the UI will load over the tunnel but the video will not connect. For Visio, run it on a greffer with a reachable public IP (a small VPS, or a box at home with the media UDP port forwarded). Plan for that before you graft it, not after the first call fails to connect.
Change the demo login before anyone else sees it
The catalog ships Visio as a self-contained demo so you can confirm it works the moment it boots: log in with username demo and password demo. That is fine on your own network for a first look, and you can also register a fresh account from the login screen.
demo account is public knowledge. Before you put the instance anywhere reachable, create a real account and stop relying on the demo credentials. Login runs through the embedded Keycloak, so you manage accounts there.Keep it always-on
A meeting server is only useful when it is up at the moment someone clicks your link. Between the always-on expectation and the need for a reachable public UDP endpoint, Visio is a poor fit for a laptop that sleeps. Run it on an always-on greffer with a public IP and enough memory for the full stack. If a call drops mid-meeting, the first things to check are that the media UDP port is actually reachable from the outside and that the host has not run out of RAM.