Configuration externalizes application and Akka settings so behavior can vary at runtime without changing code. Properties live in a hierarchy, are loaded through ConfigFactory, and can be read wherever an ActorSystem exposes its settings. section 7.0 section 7.1 section 7.2
Use layered files rather than copying complete configurations per environment. Higher-priority values override lower ones; missing values fall back to defaults. Libraries place defaults in reference.conf inside their JARs, so a requested property is expected to resolve to a value rather than silently becoming null. section 7.1.4
Figure 7.3 Priority of the configuration fallback structure. The highest priority is at the top and overrides definitions in lower files.
The fallback priority diagram shows why a local or test override wins while unchanged settings continue to come from lower-priority defaults. section 7.1.4
Apply configuration at several practical boundaries:
- Create an ActorSystem with defaults, or pass a loaded Config to give that system its own settings. section 7.2
- Override only test-specific settings—such as akka.loglevel—using application-test.conf or ConfigFactory.parseString, then fall back to normal configuration. section 7.4
- Lift a subtree ahead of a base configuration when a subapplication needs a few different values while retaining all other values. section 7.3.1
- Set cluster addresses, roles, membership thresholds, and worker counts separately from actor code. section 8.4.2
Override a clustered node at startup
A word-counting node parses its startup port and role into a small configuration, then calls withFallback on the shared words configuration. The same application can therefore start as a seed, director, or aggregator while retaining common cluster and workload settings. section 8.4.2
For local development and testing, seed-node addresses can be supplied as configuration. Cloud deployments instead use Cluster Bootstrap to discover nodes; avoid treating fixed seed-node configuration as the production default in those environments. A deployable service can likewise maintain distinct local and Kubernetes configuration files. section 8.2.1 section 15.2
