public final class Config

Where a server’s settings come from, in one resolution order.

The shape is the one a Spring Boot developer already knows, because the problem is the same one: the SAME code has to run against a SQLite file on a laptop and a managed PostgreSQL in production, and the difference between those two cannot live in the source. It lives here.

# application.properties, committed
cn1.datasource.url=${DATABASE_URL}
cn1.server.port=8080

# application-dev.properties, also committed
cn1.datasource.url=:memory:

CN1_PROFILE=dev ./server                       # SQLite, nothing installed
DATABASE_URL=postgres://user:pw@db/app ./server # production

A key is looked for in this order, and the first layer that has it wins:

1. a system property of exactly that name (-Dcn1.server.port=9000), which only the local JVM loop can set;

2. an environment variable of the name in upper case with dots as underscores (CN1_SERVER_PORT), which is how a container sets one;

3. the environment variable a platform already sets for it, where one exists: PORT and DATABASE_URL are set for you by every PaaS worth the name, and a server that ignored them would need a wrapper script to start at all;

4. application-<profile>.properties;

5. application.properties;

6. the module’s application.properties as the build compiled it into the server, so a binary with no file beside it still has the committed settings, and a file or the environment can still change any of them;

7. the default the caller passed in.

A test started by @BackendTest adds one layer above all of these: the settings the test itself names. A test that asks for a free port or an in-memory database gets one even in a shell that exports PORT or DATABASE_URL.

A value may reference an environment variable as ${NAME} or ${NAME:fallback}. That resolution happens when the value is READ rather than when the file is loaded, which is what lets a committed application.properties name a variable that only production sets: the dev profile overrides the key, so the unset variable is never looked at. A reference that IS read and cannot be resolved is an error rather than a value with a dollar sign in it – the alternative is a server that tries to open a SQLite file named “${DATABASE_URL}”.

Nothing here is required. A binary with no properties file beside it reads its whole configuration from the environment, which is the normal shape for a container built FROM SCRATCH: there is no file next to the binary because there is nothing next to the binary.