Documentation
Jellyfin and your media server, reachable from anywhere — unexposed
Jellyfin is an open-source media server you host yourself — and that is exactly what makes remote access tricky: there is no vendor cloud service to bridge your living room and your phone on the road. The usual answers all come down to exposing something to the internet: forwarding a port, running a reverse proxy, maintaining a VPN server. The mesh approach does the opposite: the Jellyfin server joins your private workspace, keeps a stable address and name, and your devices reach it from anywhere over an end-to-end encrypted path — without a single port ever being opened on your router.
Why remote access to Jellyfin is a headache
On the local network, everything is easy: Jellyfin listens on port 8096 by default, you type the machine’s address into the app, playback starts. The moment you leave home, the problem changes nature: Jellyfin deliberately has no cloud service — no vendor-hosted account, no provided relay. That is a conscious project choice, your data stays with you — but it leaves everyone to solve reachability on their own, and the question comes up in the community again and again. The classic answers all carry a cost.
Port forwarding
Opening port 8096 on the router makes the server reachable — by you, and by the entire internet. The login page becomes visible from anywhere, automated scanners find it around the clock, and every flaw in the listening software becomes remotely exploitable.
The reverse proxy
A reverse proxy in front of Jellyfin (domain and certificate) encrypts access, but it is one more exposed service to install, configure, patch and watch — and the server remains reachable from the whole internet, guarded by a password.
The home-grown VPN server
A VPN server avoids exposing Jellyfin, but it moves the problem: you must open a port for the VPN itself, maintain it, hand out configurations — and it remains impossible behind a CGNAT connection (4G/5G, many recent fiber plans), where no port can be opened at all.
The Plex case, in a word
Plex sidesteps the problem with a cloud account and a relay option operated by its vendor: simpler remote access, at the price of depending on that third-party service. Jellyfin makes the opposite choice — everything stays with you — and that is the choice the mesh approach completes.
| Approach | What gets exposed | What you maintain |
|---|---|---|
| Port forwarding | Jellyfin itself, to the whole internet | The router rule, the public address |
| Reverse proxy | The proxy, to the whole internet | Proxy, domain, certificates, updates |
| Home-grown VPN server | The VPN's port | The VPN server and its client configurations |
| VIGIL mesh | Nothing — zero inbound ports | A client installed on each machine |
The mesh approach: the server joins your workspace
With VIGIL-MESH, the machine hosting Jellyfin is enrolled into your workspace like any other device. It opens no inbound port: outbound connections only, a single flow on 443 UDP, the same port as the modern web. Your playback devices are enrolled the same way, and all of them end up on a private network that follows them everywhere. If your Jellyfin runs on a NAS, the principle is identical — the NAS itself (file shares, admin interface) has its own dedicated page: /docs/acceder-nas-a-distance.
- A stable address — the server gets an overlay address (within 100.64.0.0/10) that never changes, wherever you are.
- A readable name — with MagicDNS, the machine is reached by its short name, resolved the same way from every member of the network.
- End-to-end encryption — sessions are QUIC/TLS 1.3 connections with a hybrid post-quantum key exchange.
- Nothing visible from the internet — the Jellyfin login page is only reachable from the machines in your workspace.
On the application side, nothing exotic: Jellyfin clients let you type in the address of their server. Instead of a public address, you enter the server’s address on the mesh — its MagicDNS name or its stable address, followed by Jellyfin’s usual port. The app then behaves as if it were on the server’s local network, because, from the network’s point of view, it is.
Throughput: direct path and local transcoding
Video streaming is about the most bandwidth-sensitive workload there is: a needless detour is paid for immediately in buffering. This is where the architecture matters. When you start playback, the connection is established immediately through a relay — the vigie — then migrates without interruption to the direct peer-to-peer path as soon as NAT traversal has found one. In steady state, the video stream travels from the server to your device over the shortest route, without transiting any intermediate infrastructure.
Transcoding remains Jellyfin’s business: when the device’s connection cannot handle the original file, the server converts the video on the fly to a lower bitrate, just as for local access. The mesh changes nothing about that mechanism — it carries the resulting stream over the most direct path available.
- Direct path: peer to peer, the available throughput is that of your two connections — no third-party server caps it.
- Relayed path: if direct is impossible (two symmetric NATs facing each other, for instance two 4G connections), the stream goes through the vigie, encrypted end to end — it never sees the content.
- Personal use: free, with unlimited direct traffic; only relayed traffic is subject to a quota.
DLNA and device discovery across the mesh
A media server sits among devices that find each other by broadcast: DLNA discovery relies on SSDP, multicast announcements sent “to everyone on the link”; automatic server discovery by the apps uses mechanisms of the same kind. Yet those announcements normally never cross a router — which is why a classic L3 VPN makes the server vanish from the apps, even once the tunnel is up.
VIGIL-MESH treats each network as a broadcast domain: broadcast, multicast and link-local IP reach every member as on a switch, and that traffic is encrypted end to end with rotating sender keys. The server’s SSDP announcements (DLNA is an optional Jellyfin feature), mDNS discovery and the apps’ own searches therefore cross the mesh as if all your devices shared a single cable — including hundreds of kilometers from the living room. And unlike on a physical LAN, these announcements never travel in the clear outside your machines: the relay replicates them without being able to read them.
Sharing the library with the family, without exposing it
A Jellyfin server rarely serves a single person: everyone has their own account and history, a relative far away enjoys the library. With the exposed approaches, widening access means widening exposure. With the mesh, widening access means enrolling devices: each household member’s phone joins the workspace with its own identity, and sees the server as if it were at home.
- One device, one identity — every enrolled machine holds its own cryptographic identity; revoking one (a lost phone, a loaned device) cuts its access immediately, without touching the others.
- Access policies (ACLs) — the network is deny by default: you can allow the family’s devices to reach only the media server, without opening the rest of your machines to them.
- Jellyfin accounts stay Jellyfin accounts — the mesh decides which machines can reach the server; profiles, passwords and parental controls remain managed inside Jellyfin.
Setting it up, step by step
There is nothing to change in Jellyfin itself: the server keeps listening as it always has. Setup consists of connecting the machines to the private network.
- 1Create a workspaceCreate an account and a workspace: this is the private network that will link the server and your devices.
- 2Install the client on the Jellyfin serverInstall the VIGIL-MESH client on the machine hosting Jellyfin (Windows or Linux). It will open no inbound port.
- 3Enroll the server, then your devicesFrom the console, Networks page → Machines → “Add a machine”: a single-use key enrolls the server, then each playback device the same way.
- 4Verify connectivityCheck that the server shows up with its stable address and answers ping, and that its MagicDNS name resolves from your devices.
- 5Point the Jellyfin appsIn each client app, enter as server address the MagicDNS name (or the stable address) followed by Jellyfin’s port — 8096 by default. Playback then works everywhere, just like at home.
Troubleshooting: the questions that come up
Most blockers fall into three families: a mistyped address, a device that is not (or no longer) a member of the network, or a genuine limit worth knowing about. In the order to check them:
- The app cannot find the server — check that the playback device is enrolled and connected to the mesh, then type the address by hand (name or stable address, port included) rather than relying on automatic discovery.
- It worked, now it doesn’t — a suspended, revoked or expired device loses access immediately; check its state in the console, and that the client is actually running on the server.
- The name does not resolve — reach the server by its stable address first: if it answers but the name does not, the issue is on the MagicDNS resolution side, not the server side.
- Remote playback stutters — look at the upload bandwidth of the server’s connection and let Jellyfin transcode. Two endpoints behind symmetric NAT (two 4G connections) force a permanently relayed path, longer than the direct one.
- The smart TV sees nothing — the honest limit: a device that cannot run the client (a closed TV, a streaming stick) cannot join the mesh. At home it keeps reaching the server over the LAN as before; remotely, favor a device that can run the client (Windows, Linux, Android, Jetson).