Load balancing more than one emby server

[afogleson 15]

ok so before i do this.... (after all i dont want to do a bunch of work that i dont need to do if someone has tried and proven this wont work) 

So lets say i have a server farm (i sort of do... but its "small" only 3 servers currently) and i want to run a clustered load balanced set up on said farm. Currently I have all of the 3 servers running in Docker containers and all of those containers currently are set up such that all the data/config/etc is on local volumes. I can put those all on shared space of course (and I suppose would have to in order to accomplish this) so here is the scenario... lets say I have user A (and b and c and d and so on but lets deal with the simple case which is really just all cases) and that user is currently on server 1 watching a movie/show/etc. they obviously get a lot of data (what i have watched where i exited when i stopped watching etc etc) so the user stops watching and later comes back to continue watching.... but they are now on server 2.... is it SAFE to point all those servers (3) at the same data set? they would all have the same permissions and such... the load balancing is easy ive done that too many times for customers in my job  but that was on a regular java application with maybe a nodejs or such front end and so on. so sort of built for clustering.... 

 

Has anyone tried? succeeded? failed? if not i will just backup my data and try it myself but I dont want to mess with the large data backup if someone has tried and failed. 

[Neminem 1518]

I think you will run into issues with Emby's DB since its a SQLite DB.

I would think that you will see DB corruption and lockups.

SQLite does not like being on a network share, and is as a rule of thumb not advisable. 

[yocker 1247]

5 hours ago, afogleson said:

ok so before i do this.... (after all i dont want to do a bunch of work that i dont need to do if someone has tried and proven this wont work) 

So lets say i have a server farm (i sort of do... but its "small" only 3 servers currently) and i want to run a clustered load balanced set up on said farm. Currently I have all of the 3 servers running in Docker containers and all of those containers currently are set up such that all the data/config/etc is on local volumes. I can put those all on shared space of course (and I suppose would have to in order to accomplish this) so here is the scenario... lets say I have user A (and b and c and d and so on but lets deal with the simple case which is really just all cases) and that user is currently on server 1 watching a movie/show/etc. they obviously get a lot of data (what i have watched where i exited when i stopped watching etc etc) so the user stops watching and later comes back to continue watching.... but they are now on server 2.... is it SAFE to point all those servers (3) at the same data set? they would all have the same permissions and such... the load balancing is easy ive done that too many times for customers in my job  but that was on a regular java application with maybe a nodejs or such front end and so on. so sort of built for clustering.... 

 

Has anyone tried? succeeded? failed? if not i will just backup my data and try it myself but I dont want to mess with the large data backup if someone has tried and failed. 

Emby is sold as a personal Emby server more or less.
Having it be able to do load balancing between servers would make it more than that and make even more use it as a piracy Netflix. Don't think the Emby dev team would like that.

Best you can do is run multiple serveres and then just point them to the same media files so they will make their own separate databases.
I bet you can then make some load balancing in a remote proxy that point people to what ever server that is the least conjected.

[rbjtech 5284]

As above, the sticking point is the emby database as it's exclusively locked and will not allow multi account access.

Everything outside of the db works just fine with load balancing but limit one server as a metadata fetcher, the others should act as readers only,  you'll need a reverse proxy etc to do the http connection algorithm but I guess you are well aware of the methods and how to do this.    Due to the db issue - I would try and use a persistent connection (ie returning users always connect to the same server) + an offline db sync, that way the users history stays with them until the next db 'sync'.   Once a sync has occured, they can connect to any server they wish - so only make it persistent for that day.

Edited August 17, 2025 by rbjtech

[afogleson 15]

Well i would argue it is not sold at all. (other than premeire license) I get your point. a DB is easy to work around. Albeit it may mean moving to jelly fin since it has all the source available and its relatively (relative being the key word) easy to move to a different DB. I imagine though there is a ton of legacy code baked into both that assumes the db is and will always be sqllite. (sigh, but ill leave my enterprise architect impatience at the door ) 

[afogleson 15]

3 hours ago, rbjtech said:

As above, the sticking point is the emby database as it's exclusively locked and will not allow multi account access.

Everything outside of the db works just fine with load balancing but limit one server as a metadata fetcher, the others should act as readers only,  you'll need a reverse proxy etc to do the http connection algorithm but I guess you are well aware of the methods and how to do this.    Due to the db issue - I would try and use a persistent connection (ie returning users always connect to the same server) + an offline db sync, that way the users history stays with them until the next db 'sync'.   Once a sync has occured, they can connect to any server they wish - so only make it persistent for that day.

lets be honest though... i am not talking about setting up - as someone implied - a netflix environment. I am talking about what is essentially a passive failover vs some real clustered high availability environment. in the rare case that I have 4 or 5 clients even then it would be rare for sqllite to fail. Someone suggested corruption... i doubt it. SQL lite for better or worse locks the entire db when it writes worst case scenario you may see an occasional error on a client that wanted to write but could not. in a perfect world I'd sit down (maybe with the Jellyfin code) and abstract that data layer off but i am not looking for an enterprise solution im looking for a "if i am away from home, and one server goes down I still have 2 other servers in the cluster to use" id probably use a scheme for load balancing even. (server 1 unless... then server 2 unless... then server 3.... if all three are down i probably have bigger problems at the house)

 

[Neminem 1518]

Well give it a go

Tell us how its behaving and good luck

[caffeineshock 18]

On 8/17/2025 at 3:18 PM, afogleson said:

lets be honest though... i am not talking about setting up - as someone implied - a netflix environment. I am talking about what is essentially a passive failover vs some real clustered high availability environment. in the rare case that I have 4 or 5 clients even then it would be rare for sqllite to fail. Someone suggested corruption... i doubt it. SQL lite for better or worse locks the entire db when it writes worst case scenario you may see an occasional error on a client that wanted to write but could not. in a perfect world I'd sit down (maybe with the Jellyfin code) and abstract that data layer off but i am not looking for an enterprise solution im looking for a "if i am away from home, and one server goes down I still have 2 other servers in the cluster to use" id probably use a scheme for load balancing even. (server 1 unless... then server 2 unless... then server 3.... if all three are down i probably have bigger problems at the house)

 

failover with a hypervisor. hyper-v, kvm/qemu/proxmox, esxi, etc. 

you could just mirror a vm across multiple nodes and in case one node fails, the vm will still be available on the other node (a few seconds later, depends on your setup). no corruption, nothing. you dont want load balancing, you want high availablity, thats something completely different. you could offload your storage to a central... storage so that it does not have to be migrated (in case you dont want HA storage)

easy

[afogleson 15]

20 minutes ago, caffeineshock said:

failover with a hypervisor. hyper-v, kvm/qemu/proxmox, esxi, etc. 

you could just mirror a vm across multiple nodes and in case one node fails, the vm will still be available on the other node (a few seconds later, depends on your setup). no corruption, nothing. you dont want load balancing, you want high availablity, thats something completely different. you could offload your storage to a central... storage so that it does not have to be migrated (in case you dont want HA storage)

easy

Yes i would agree somewhat.. but i DO want load balancing also. I have many players in the home and over the network. I have a decent server that i would probably use for the networked connections (since they would do conversions likely) but a couple rPi devices run emby (in a docker container also) And since rPi are not super powerful i would like to have those only handling minimal connections (lets say i have 3 rPi... i dont want 1 or 2 to sit idle while rPi 0 is handling 3 requests/streams) and yes i realize that means session affinity. that is not hard to do... every "load balancer" in the world handles - or has mechanisms to handle that. Im not terribly concerned about that aspect but in short i need both high availability AND some load balancing. 

[Neminem 1518]

Guess you would need some other Media Server

[brothom 177]

23 hours ago, afogleson said:

Yes i would agree somewhat.. but i DO want load balancing also. I have many players in the home and over the network. I have a decent server that i would probably use for the networked connections (since they would do conversions likely) but a couple rPi devices run emby (in a docker container also) And since rPi are not super powerful i would like to have those only handling minimal connections (lets say i have 3 rPi... i dont want 1 or 2 to sit idle while rPi 0 is handling 3 requests/streams) and yes i realize that means session affinity. that is not hard to do... every "load balancer" in the world handles - or has mechanisms to handle that. Im not terribly concerned about that aspect but in short i need both high availability AND some load balancing. 

Why not use multiple docker instances (albeit separated or on the same machine, doesn't matter) that are bound via some sort of load balancing. Then create a single point of entry (machine with "fixed" ip) which then negates traffic to the least populated server. That's the hard way, because when the user is viewing something, there shouldn't suddenly be a switch to a different machine.

The easy way is simple creating subdomains (s1.domain.com, s2.domain.com, etc) and forwarding these to your network and intercepting the incoming hostname and forwarding that to the designated device.

That way you can tell your users to use a specific domain or so. It's not exactly "premium quality" but that way you can separate users as well much like how websites like amazon and netflix seem to do it. Logging in via their localized websites also delivers a cdn close to that server it looks like, not close to the viewer's origin, simplifying the process. There are load balancers still, but those are only on a local level. 

[afogleson 15]

6 hours ago, brothom said:

Why not use multiple docker instances (albeit separated or on the same machine, doesn't matter) that are bound via some sort of load balancing. Then create a single point of entry (machine with "fixed" ip) which then negates traffic to the least populated server. That's the hard way, because when the user is viewing something, there shouldn't suddenly be a switch to a different machine.

The easy way is simple creating subdomains (s1.domain.com, s2.domain.com, etc) and forwarding these to your network and intercepting the incoming hostname and forwarding that to the designated device.

That way you can tell your users to use a specific domain or so. It's not exactly "premium quality" but that way you can separate users as well much like how websites like amazon and netflix seem to do it. Logging in via their localized websites also delivers a cdn close to that server it looks like, not close to the viewer's origin, simplifying the process. There are load balancers still, but those are only on a local level. 

I have all that. multiple docker instances on the same server would make little to no sense for the high availability part. certainly I have servers capable of running multiple emby servers on the same server since they are all connected with 25gbs networking so i am pretty sure i can handle any stream size i need. These will be docker containers but docker containers on multiple servers also. it would be easy enough to use multiple domains and tell users "well if you cannot hit emby.mydomain.com then go to emby2.mydomain.com, and if that fails go to emby3.mydomain.com" that defeats the idea of load balancing. 

 

as a side note i have proven that they can work this way (and docker containers makes that a lot easier since the "data" is all on a share and thus you just point at the libraries and config and such on said share. I have not done any heavy load testing but it does work at normal levels. I just need to put together the load balancer to do it the right way (hence they would have the names emby1, 2, 3, etc.... but the loadbalancer has emby.mydomain.com  and it will decide where the requests go to. 

[RanmaCanada 494]

Everything you describe is far outside the scope of what Emby is intended for. You said you don't want to create a Netflix, yet you keep coming back to the whole lie about load balancing. No user who is using Emby for what is intended for needs this. I run Emby on a laptop and I've had no issues with having upwards of 16 concurrent users. It's a personal media server, not a VOD service. You should be looking elsewhere.

[afogleson 15]

4 minutes ago, RanmaCanada said:

Everything you describe is far outside the scope of what Emby is intended for. You said you don't want to create a Netflix, yet you keep coming back to the whole lie about load balancing. No user who is using Emby for what is intended for needs this. I run Emby on a laptop and I've had no issues with having upwards of 16 concurrent users. It's a personal media server, not a VOD service. You should be looking elsewhere.

So Where exactly in the docs and licenses for emby does it say what it is intended for? Does it say in said licenses "though shall not make emby safe for server failures?" I travel every single week. I have a certain amount of flexibility but if a server goes down then I have people in the house asking me whats up. I never said that emby cannot HANDLE the connections with a single server. Please point me to where i said that if you feel i have. I am sure that you are interpreting what i say, in view of YOUR own expectations of how things SHOULD work. Meanwhile i am looking at Failsafe measures so that if a server goes down it is barely noticable. (of course it will be noticed since if it goes down mid stream your stream WILL stop. but you can then reconnect and hit a different server and everything is back to normal) so please explain to me where what i am doing is contrary to what ANY software that is used in a multi user environment should be capable of.... after all i might be wrong on so many points... i only did IT programming, system design and enterprise architecture for 30 years or so.... 

[afogleson 15]

11 minutes ago, RanmaCanada said:

Everything you describe is far outside the scope of what Emby is intended for. You said you don't want to create a Netflix, yet you keep coming back to the whole lie about load balancing. No user who is using Emby for what is intended for needs this. I run Emby on a laptop and I've had no issues with having upwards of 16 concurrent users. It's a personal media server, not a VOD service. You should be looking elsewhere.

ohh and by the way... Emby IS a video on demand (VOD) system... unless you are only allowing your users to watch what you currently push out as a stream... they can select what video to watch... on demand. 

[brothom 177]

9 hours ago, afogleson said:

I have all that. multiple docker instances on the same server would make little to no sense for the high availability part. certainly I have servers capable of running multiple emby servers on the same server since they are all connected with 25gbs networking so i am pretty sure i can handle any stream size i need. These will be docker containers but docker containers on multiple servers also. it would be easy enough to use multiple domains and tell users "well if you cannot hit emby.mydomain.com then go to emby2.mydomain.com, and if that fails go to emby3.mydomain.com" that defeats the idea of load balancing. 

Then this sounds more like an issue in infrastructure than anything else. You're trying to use multiple Emby instances at different locations at the same time which isn't really what Emby is trying to achieve or support to begin with. 

 

6 hours ago, afogleson said:

So Where exactly in the docs and licenses for emby does it say what it is intended for?

You're right, it doesn't state that anywhere, but it doesn't state it's an Enterprise-level application either.

Emby also states on this page https://emby.media/support/articles/Premiere-Limits.html, that it's designed to handle up to 30 devices from a single-household.
What a "single-household" is obviously kept vague, so let's just pretend the page is talking about a single server that handles 30 devices (connections).

 

6 hours ago, afogleson said:

 i only did IT programming, system design and enterprise architecture for 30 years or so.... 

Finally, please don't patronize people on this forum. We're all here to achieve the same goal of improving Emby as a product. That isn't a way to achieve that. There're for more programmers and system engineers on here than you'd think.

[pwhodges 2012]

9 hours ago, afogleson said:

i am looking at Failsafe measures so that if a server goes down it is barely noticable.

Fine; but what are you doing that makes Emby go down at all?  In several years usage mine has never crashed in normal* operation.

Paul

* Twice in that time a new beta has failed to run at all on my system - but that doesn't count as "normal operation"!

[ebr 16169]

13 hours ago, afogleson said:

So Where exactly in the docs and licenses for emby does it say what it is intended for?

Here: https://emby.media/terms.html

Quote

For any Software made available to you to download through the website, or accessible due to a subscription service or purchased through a third party platform (e.g. Apple App Store, Google Play Store, or via a Roku Channel), Emby grants you a personal, non-commercial, worldwide, royalty-free, revocable, non-transferable, non-sublicensable, and non-exclusive license to use the software provided to you by Emby ("Software"). This license is for the sole purpose of enabling you to use and enjoy the benefit of the Software in the manner permitted by these Terms.

 

[kikinjo 281]

I love it when ebr quotes terms or something else emby team wrote, and there is nothing in that text about topic that is discussed. 

Seems like personal or non commercial software CANT HAVE failover, or balancing. At least for emby team.

 

Edited August 21, 2025 by kikinjo

[Lessaj 467]

The software is not designed to be scaled, if it was then external DB connections would be configurable since that's the main pain point with multiple instances, they are not going to be in sync with each other due to local DBs that are locked - even if they have the same content (backend files) the user data is still unique to that instance, and on top of that more than likely the item IDs will be different between each instance.

I'm reading this topic as "how do I make Emby highly available with multiple nodes" and the answer is you can't. You can setup a load balancer for multiple reverse proxies, but for the Emby server itself all you can do is set up a VM or docker container that you can migrate between hosts if a host crashes or taken down for maintenance, that's as much high availability as you're going to get.

[afogleson 15]

10 hours ago, pwhodges said:

Fine; but what are you doing that makes Emby go down at all?  In several years usage mine has never crashed in normal* operation.

Paul

* Twice in that time a new beta has failed to run at all on my system - but that doesn't count as "normal operation"!

Well lucky you... you have had computers running for "several years" and those computers have never crashed on their own. Literally from an IT perspective (my profession) i have to say you have been extremely lucky. I have had servers crash because the OS updates failed and so on... or I HAD to take a server down to perform the os update. (or update the emby release even) and yes that means that MAYBE one family member (key word here since i am going to answer the accusation that somehow I am violating license terms.... when i asked WHAT is it used for) or more might have their stream go down until they reconnect (and get a different server theoretically) 

 

[afogleson 15]

54 minutes ago, Lessaj said:

The software is not designed to be scaled, if it was then external DB connections would be configurable since that's the main pain point with multiple instances, they are not going to be in sync with each other due to local DBs that are locked - even if they have the same content (backend files) the user data is still unique to that instance, and on top of that more than likely the item IDs will be different between each instance.

I'm reading this topic as "how do I make Emby highly available with multiple nodes" and the answer is you can't. You can setup a load balancer for multiple reverse proxies, but for the Emby server itself all you can do is set up a VM or docker container that you can migrate between hosts if a host crashes or taken down for maintenance, that's as much high availability as you're going to get.

Blatantly false... you CAN. you have to share config and data... and put that all on shares. but i can run (so far i have run 3 hosts all pointing at the same data/config and they all run fine...

 

[afogleson 15]

1 hour ago, kikinjo said:

I love it when ebr quotes terms or something else emby team wrote, and there is nothing in that text about topic that is discussed. 

Seems like personal or non commercial software CANT HAVE failover, or balancing. At least for emby team.

 

Yes... im about to answer that post

[Lessaj 467]

Just now, afogleson said:

Blatantly false... you CAN. you have to share config and data... and put that all on shares. but i can run (so far i have run 3 hosts all pointing at the same data/config and they all run fine...

 

I doubt that will work long term. If it's already working then why are you asking about it?

[afogleson 15]

6 hours ago, ebr said:

Here: https://emby.media/terms.html

 

So there is nothing NON PERSONAL NOR COMMERCIAL that i am doing. i am merely making sure that my personal non commercial emby environment has failover and is balanced such that multiple streams can be handled so that a single server is not over taxed such that other users (in my family/personal usage) can watch at full quality settings versus having to cut them down on a 200mbs stream to 3 or such.... 

 

At this point i already solved the problem and no it is not perfect in any way shape or form. decisions (which probably were never thought out at the time of creation) were made to use sqlLite which does impose severe restrictions (and yes i COULD have some write failures .... ohh darn someone might lose their write that said they were at minute 92 of a 120 minute movie) but since SQLLite also locks the entire db on a write there will not be corruption. its a tradeoff im willing to live with. if i was not, id just move to Jellyfin and do the contribution to allow some other DB. 

 

At this point can we PLEASE close this topic. it is ceasing to be helpful or even proiftable for ANYONE else. the short answer is... yes you can do this... you have to point every emby server at the shared data (which means... basically use docker containers or some other container technology) so the question is solved.