Variable Substitution Without Deploying Package

Currently for Production, our Network Services team does a DNS flip to point to Staging. The problem is we have variables that point to the DB server that need to be updated during Production deployment (on the Staging web server). Basically we need to be able to update the DB IPs in the Staging web.config without redeploying the full package.

Any ideas?


Hi Jamie,

Thanks for getting in touch! Unfortunately, Octopus is unable to perform partial deployments. However, you would be able to have a step that is either a step template or a PowerShell/script that can change the web.config which only runs on a condition you could also set.

There are not too many options sadly. Let me know if you have any further questions or run into any issues.



Daniel provided one approach, but I’d like to offer another one that truly takes advantage of Octopuses release model: Blue/Green deployments -

You essentially set up two production environments. I don’t think it’s a very good practice to switch your production dns between a staging and production environment if that’s what you’re doing. The staging environment can be and should be just for testing. With blue/green deployments you should be able to solve your issue elegantly.

I’m not sure how that’s different from what we’re currently doing? We deploy to what’s called staging, and qa tests it, but once it’s done it becomes production and old production becomes staging.

The problem is the database deployment since they are on different boxes so we have to update our config files to point from staging db to production db after scripts are ran. We ended up solving it with a custom script for now.

If you have an idea of a better solution please let me know and I’ll pass it along to our network services team.



Sent from my Bell Samsung device over Canada’s largest network.


Right now you are currently doing the Blue/Green deployment concept, but you’re doing it with a mixture of Staging and Production environments which is where you’re having a problem.

The correct way to do it is to set up two production environments and swap DNS between those two. Both production environments would therefore use the same variables and you still only have one staging environment. Consider the following environments, S1, P1, P2.

If your DNS is currently pointed at P1 then next time you deploy to Production you promote your release that is on S1 to P2 and then flip the DNS switch to P2. The following release would promote from S1 to P1 and then the DNS would switch to P1.

Again, an environment should only serve one environment. The entire architecture of Octopus is built around this. You create a variable sets that update your config files depending on what environment you’re deploying to. A staging (test) environment should never be forced into a production environment.

If you look at the images in the link I provided it shows you how to set up two production environments with different machines assigned to them.