Double Scopes on Machine not working as expected


I have a question regarding the scoping of variables. I searched the forum but could find anything that solves my problem.

So we have a pretty large project containing several environments, every environment has multiple servers (6-10) and containing over a thousand variables. The enviroment is physically splitted in a backoffice (LOB) and a frontoffice (CONS) and both contain the same applications which are deployed based on role.


We have 1 application (login site) which in installed on 2 machines LOB01 and SVC01 and depending on which machine only the variables differ. The codebase is exactly the same so i created 1 step and depending on te roles per machine i hope te fetch the correct variable.


LOB01 -> SVC and LOB role
WFE01 -> SVC and CONS role

1 Step:

Creating the Website in IIS and deploy the nuget package
Role -> SVC

2 variables (in a variable set):

Login_Url -> Value: -> Roles: LOB, SVC
Login_Url -> Value: -> Roles: CONS, SVC


This variable is being used as a HTTP-Binding in IIS . So i expect this to show up as a binding to the created website in IIS.


Now the result is that both servers are configured using the LOB-URL( and this is not what i expect. I expect them to differ because the CONS variable is more specific because it matches on both CONS and SVC and the LOB-URL should be more specific because of LOB and SVC.

When i add the variables “OctopusPrintEvaluatedVariables” and “OctopusPrintVariables” is can see that only the LOB-URL.

I suspect that the variable only matches on 1 Scope defined on the Machine instead of both is my assumption correct. In that case i have to create Scopes (SVC-CONS and SVC-LOB) but that sounds redundant.

Can someone please help me?

Maybe usefull to add, it is not only SVC we use. There are multiple applications which are added to a “ROLE”. For example SVC, WEB, MOBILE, MGT and both are being deployen on both ends (frontnet and backnet).

For example the Login_URL are different but for example the location are shared:

Login_Url -> Value: -> Roles: LOB, SVC
Login_Url -> Value: -> Roles: CONS, SVC
Login_Path -> Value: d:\inetpub\wwwroot -> Roles: SVC

Another variant we are using but even more complex:

The website itself. It is deployed multiple times with the same amount of IIS websites only different settings:
NL / BE / FR or COM

Deploy steps:

1 Deploy NL -> Roles WFE NL
2 Deploy BE -> Roles WFE BE
3 Deploy FR -> Roles WFE FR


Frontnet machine -> CONS SVC WFE NL BE FR
Bacnket machine -> LOB SVC WFE NL BE FR


Site_Url -> Value: -> Roles: LOB, WFE, NL
Site_Url -> Value: -> Roles: CONS, WFE, NL
Site_Url -> Value: -> Roles: LOB, WFE, BE
Site_Url -> Value: -> Roles: CONS, WFE, BE

So the settings can differ on all 3 roles based on frontnet/backnet or country

Hopefully this helps!

Hi Tom,

Thanks for getting in touch. Just to check, which version of Octopus are you using?

When given two variables to pick from, we match by the role that the deployment targets (“SVC” in this case) first, before matching by whatever other roles the machine might happen to have.

So in this case we only match on SVC and ignore the other roles. Then we pick one of those two matches.

I’d agree that if we get multiple matches, we should then go to the next level of trying to see if the machine has any other roles that make it more specific. I have a feeling we may have done this already, but I’m not sure how recently it was.


Hi thanks for your reply.

We are using version

I got only 1 obvious question. In which version should it be fixed so i can determine to change all the scopes to SVC-CONS and SVC-LOB or wait untill that version is being released.

thnx, Tom

Thanks Tom, in that case it mustn’t be the issue we fixed.

I’ve created a bug report here that you can track:

We’re about to release Octopus 3.0, so this will go into the next patch that goes out after 3.0 (so give us a week or two).


Hi Tom,

I did some thinking about the scenarios, and started down the path of tweaking Octopus to work for your scenario. But along the way, I found a few other scenarios that would break if we make variable scoping work the way you need. I wrote a blog post to try and explain:

I’d agree that the examples you gave are pretty intuitive, which is why I originally treated it as a bug report. But when combined with other levels of scoping I think it makes other scenarios much less intuitive.

I hope there’s perhaps a simpler way you can model this; maybe by defining values for the URL’s at environment level, or creating a new role and letting the step target it?

Hope this helps,


Hi Paul,

Thanks for your reply. I’ve read your blog and understand it is difficult to implement. I indeed can imagine that simpler is easier especially with this kind of complex features, keeping a matrix will be hard to maintain and also to understand so we will keep it simple and stupid :).

This is how we configured it at the moment:






  Step1: Deploy NL
    Scope: WFE-NL

  Step2: Deploy BE
    Scope: WFE-BE


    Country/Env Specific Binding-URL:
    Value:         -> Scope WFE-NL-CONS
    Value:   -> Scope WFE-NL-LOB

    Country/Env Specific Binding-URL:
    Value:         -> Scope WFE-BE-CONS
    Value:   -> Scope WFE-BE-LOB

    Value: d:\inetpub\${SiteName} -> Scope WFE, SVC

    Value:  \\share\LOB_folder    -> Scope WFE-LOB
    Value:  \\share\CONS_folder -> Scope WFE-CONS

With these Scopes we can scope all needed sites and environments:

  • Role specific (WFE, SVC)
  • Country specific WFE-NL, WFE-BE
  • Env. specific WFE-LOB, WFE-CONS
  • Country & Envspecific WFE-NL-CONS, WFE-BE-LOB

This works like a charm and is easy to understand. However it was a hell of a job converting all variables to this new scoping approach :slight_smile:

Thanks for your help and time!
Kind Regards,