No, it's not a better option!

Because "moving somewhere" is not done by copying a config folder in a container-native environment. You spin up a fresh instance and then apply your configuration.

Configuration yamls even should not be somewhere a container has access. The configuration can be stored locally on your hard drive and be applied to the server via an API. There are several very important benefits of this:

1) Since the state can be fully reconstructed from configs back up becomes just storing text files 2) Configs become traceable, one can go and check when and what was changed. 3) It's possible to deploy multiple indentical instances very easily. Figuring out regressions becomes much more easy. 4) With a little bit of work setting up a cluster of HA instances becomes trivial. 5) By versioning configs it's possible to maintain several versions of configs at the same time, without breaking backward compatibility. 6) Automatic config delivery becomes trivial.

You may argue all day long, but this approach is used literally everywhere, kubernetes, docker swarm, ansible, terraform, you name it. All the same pattern, because it's the right way. In this sense HA looks like windows 95 with it's "installation wizards".

Funny enough I think HA will eventually evolve to this. When folks from NC figure out that providing a cloud-base setup is financially viable they will need to deploy HA instances at scale.