For short term systems, such as used in events (like the FIRST LEGO League). Getting instances of software to run and configured is a relatively large task. As components are deployed on new servers, web addresses change and hence configuration needs to be adjusted to the new reality.
One way to solve this is to create and maintain permanent configurations, but that does not scale when the configuration needs to change based on need, infrastructure and available resources.
For the FIRST LEGO League, we use a messaging server (RabbitMQ) as a central hub between a multiple of applications. When an event is held, a local instance of that server is set up and all applications need to be configured with the server address. This gets harder as the number of applications grows.
Set up a hosted, always-on server (on the global internet) that can act as a configuration negotiator. It exposes an api to register services. These services MUST register themselves with one or more named addresses (one as default). They MAY add other configuration fields, and MAY add a notification endpoint. When new services register, the notification endpoints are contacted with the new configuration.
When setting up systems, the configuration endpoint needs to be configured in all these systems, which may have been done on a default instance already. All systems will then register themselves and share relevant configuration through the configurator.
This method does mandate the need for an internet connection to the hosted configurator, but this connection only has to be up during the configuration step. When configured, the systems could run in a local network.