Plex has confirmed that it will require a Remote Watch Pass or Plex Pass for remote streaming on its TV apps. The change is going into effect for the Roku app first, followed by all other TV apps and third-party clients in 2026.
Earlier this year, Plex increased its pricing for Plex Pass and stopped supporting all options for free remote streaming in the Plex apps, such as adding a custom server connection in the app settings. The company said at the time, “The reality is that we need more resources to continue putting forth the best personal media experience, and as a result, we will no longer offer remote playback as a free feature.” That’s also when Plex introduced the Remote Watch Pass as a less expensive way to enable remote streaming again.
Plex is now rolling out the remote watch changes to its Roku TV app. If you have Plex Pass, or the owner of the server you’re streaming from has Plex Pass, you don’t need to do anything. Otherwise, if you are streaming on a different network from the server’s home network, you need Plex Pass or Remote Watch Pass.
You CAN, but you really shouldn’t. Even the documentation says as much. The Jellyfin server is way to insecure to expose it to the open internet. In reality you can’t safely use Jellyfin remotely without a vpn
It does not say that in the documentation. What the documentation does have, however, are extensive instructions on how to make Jellyfin accessible on WAN: https://jellyfin.org/docs/general/post-install/networking/ https://jellyfin.org/docs/general/post-install/networking/reverse-proxy/
It says so right there.
And there.
This smug mentality that security is unnecessary when exposing ports to the open internet reminds me of people who think its fine to drive drunk because “I’ve done it dozens of times before and nothing happened!” It also reminds me of the mentality of tech company VPs right before they have a massive data breach. It’s quite absurd to read.
For some reason they recommend against directly forwarding Jellyfin’s ports, but reverse proxies are fine. I expect this is because the default configuration doesn’t use SSL.
I think you’ll find without exposing ports to the open internet we would not be having this conversation right now. Which, I suppose, wouldn’t be such a bad thing.
I’ve not looked into it but presumably it’s because whatever web server framework they are using might not be as bug free and battle tested as dedicated web server application like nginx so by limiting the actual web servers exposure you are limiting the attack surface.
This is good to know, thanks for sharing. I’ve only got it local for now after installing at the weekend and wasn’t sure how secure it was for external access.
I’m just chiming in to say that while the documentation gives you information on how to do external access, there are multiple issues open on the github about unauthenticated endpoints that if you know what is on the server already, you can confirm that it’s there
So I wouldn’t use a standard naming convention because using that knowledge, someone who cares could use common names that could be on the server, followed by common standards of formats they would be in, and be able to confirm it’s their via the end points.
Oh no, someone else could possibly play media from my media server, if they have the exact link for it!
Yea, not ideal, but not exactly the end of the world.
This seems like a naive viewpoint as you’re exposing your whole network and everything connected to it to the open internet. Just because the port connects to Jellyfin doesnt mean there isn’t some exploit or vulnerability that can allow for greater access. This is media software written by volunteers and offered for free, so I wouldn’t expect Fort Knox security from it just because its FOSS. In fact, they specifically put the onus on the user to do this themselves if they so chose.
I would trust the FOSS software’s actually auditable security any day of the week over the sketchy proprietary solution targeting an extremely niche market.
Fair enough but has anyone actually audited how secure Jellyfin is when exposed directly to the open internet? Not even the actual developers of the software recommend that, yet the majority of the replies here are being overly smug and cocky thinking it’s perfectly safe to do so.
People have audited the APIs and it is a known issue that if you know the correct URL to certain resources on the server (e.g. specific files) you can fetch them without authentication. Nothing more serious than that has been found.
‘I paid for this shit, and I will not allow it to be disrespected’. Sounds too much like Microsoft and Google apologists.
What problems? The ones that everyone keeps posting which are not a big deal. Sure they should get fixed and a lot of them have been.