Try our conversational search powered by Generative AI!

Load balancing Episerver and keeping up with Episerver releases



We're setting up a load balanced environment with one of our clients that has the most active release schedule.
We're using an automatic deployment tool where we can disable one node in the server farm to make a deploy while the other one(s) continue serving traffic.

This sounds quite straight forward until we add another thing into the pot: keeping up with the Episerver updates!

Currently Episerver does not count a change in the database schema as a major change, therefore there could be database changes with each weekly update.
And for each update in the database Episerver increments a version number that is stored within a Stored Procedure. Episerver also checks this version at startup to ensure that the database version is correct.

Are there any good plans how to handle this with the automatic deployments?

Should we take inspiration from the deployments in DXC with the following steps if we don't want a downtime when upgrading?

This list is given that we only have 2 nodes in the farm and that every step is successful so we don't need to rollback.
Of course we also consider having routines where we health check each node before putting it back into the load balanced farm, but we keep the following list simple for the example.

  • 1) A copy of the database is taken.
  • 2) Node A is taken out of the load balanced farm (because we don't want visitors on Node A while doing step 3)
  • 3) Node A receives a new set of connectionStrings that is using the copy of the database and where AppSettings have episerver:DatabaseMode set to ReadOnly according to the Database mode documentation. As this is a change in the configuration for AppSettings, Node A needs to recycle!
  • 4) Node A is taken back into the load balanced farm
  • 5) Node B is taken out of the load balanced farm to be upgraded
  • 6) Node B receive the new deployment package and the original database is upgraded
  • 7) Node B is taken back into the load balanced farm
  • 8) Node A is taken out of the load balanced farm to be upgraded
  • 9) Node A receive the new deployment package (with a configuration that will not have database mode in AppSettings and the connectionStrings use the original, now upgraded, database)
  • 10) Node A is taken back into the load balanced farm

I'm not so keen that Node A needs to recycle to be set in Read Only mode!
Even if we would let Node A use the original database and Node B use the copy for upgrading, Node A still needs to recycle as the Read Only mode is set with a change in web.config.

I'm thinking of implementing my own IDatabaseMode that will identify whether Read Only is enabled by reading something else than web.config. Will that do any harm as the website needs to initialize before I can replace the original implementation with my own?

Edited, Jun 22, 2016 22:58


Not sure that deciding "dynamically" whether database is in read-only mode or not during runtime is good idea. There are code fragments that reacts on database mode located in initialized modules. Changing database mode "dynamically" during runtime - might break something or eventually set application / data in incorrect state.

What is the issue related to recycling? What you are willing to avoid?

Jun 29, 2016 9:40

Hi Valdis,

It might be a non-issue since in a load balanced environment the visitor would not experience any issues with this. But it does not feel good to recycle the website to set this.

My main question however was the routines for deploying to a load balanced environment. :)

Jun 29, 2016 11:15

This is most interesting topic and I am following this up and hope to hear your experiences.

Sep 27, 2016 14:59

My road has always been the boring...we don't do that :)

Updating database schedule on the fly automagically starts all sorts of nervous reactions in my poor developer body...

Sep 27, 2016 15:17

Hi @Alf,

did you experiment with evaluation of IDatabaseMode after initialization? Any thoughts?

I have the same approach in mind. I want to avoid the hassle and time during my deploy just to enable readonly mode.
But if it's not supported...

Kind regards,


Sep 21, 2017 9:24

Hi Bob,

I did some experiments but there are quite alot of things that are depending on this that is defined in initialization.

I have not had time to setup the automated deploy for load balanced environment yet but this is my idea:

  1. Take down node 1, traffic will go to node 2
  2. Set read only on node 1
  3. Take node 1 back to traffic
  4. Take down node 2, traffic will go to node 1
  5. Start doing backups and deploy routines
Sep 21, 2017 9:27

Hi Alf,

thanks for the quick response!

For the moment I deploy to an app service, which scales if necessary. So it's not possbile -as far I know- to take one node down, alter settings and bring back into the loadbalancer.

If I want to support this scenario, I complicates my release / (ARM) deployment a lot.

But as excpected, changing the value at runtime is not recommended.

Sep 21, 2017 10:45

One option that I see is doing an extra deploy to staging + swap with only one parameter change, the readonly flag.

And then the actual deploy...

Sep 21, 2017 10:48
* You are NOT allowed to include any hyperlinks in the post because your account hasn't associated to your company. User profile should be updated.