Octopus allows you to change settings when you create a release.
You could also use team city or other build tools, but you probably want different settings per environment. So your deployment tool is better placed for this job.
Configuring services at run time obviously introduces a risk of the config service not being up. But I believe the real risk is in the confusion of configuration with application state.
Being sure about the change control for your deployed service is very important.
So moving configuration parameters which can only change with a deployment to Application state which changes depending on the state of another tool introduces an extra variable into you change control process.
Make sure whatever configuration tool you are using enables you to audit the config of the various services over time.
You need to be able to determine what the config was at any given point of time and match it against error logs.
Its tempting to use a config tool as a kind of solution control panel, where you switch features on and off, implement failover, control load balancing etc.
But as with all powerful tools, the 'boring' 'YAGNI' features such as rollback, logging and diagnostics can be forgotten untill something breaks. and you wish you had them.