Your Ktor service must take its port and credentials from the environment in production. How do you wire that?

## The problem One artifact has to run in several environments with different ports, hostnames, database URLs and secrets, and none of those may be baked into the image. Ktor gives you three layered mechanisms; a good answer uses them in the right order rather than reaching for `System.getenv` everywhere. ## Layer 1 — the committed file defines the schema `application.conf` should list every key the service reads, even the ones with no safe default. That file is documentation with teeth: a reader sees the full configuration surface in one place, and a startup read against a declared key fails immediately if nothing supplied a value. ``` ktor { deployment { port = 8080 port = ${?PORT} } application { modules = [ com.example.ApplicationKt.module ] } } app { db { url = "jdbc:postgresql://localhost:5432/app" url = ${?DATABASE_URL} password = ${?DB_PASSWORD} } } ``` ## Layer 2 — HOCON substitution pulls values from the environment The `${?NAME}` form is an **optional** substitution: if the environment variable is set, the assignment happens; if it is unset, the line is dropped entirely and whatever value was assigned before survives. That is precisely the semantics you want for a default-plus-override pattern, and it is why the default is written on the line *above* the substitution — order matters, last assignment wins. The non-optional form `${NAME}` is different: an unresolved reference is a parse error. Use it deliberately when you want the config itself to refuse to load without the variable. Note what `password = ${?DB_PASSWORD}` does when the variable is unset: the key simply does not exist. That is a feature — pair it with `property("app.db.password")` in code so the module throws during startup. A service that boots with an absent password and then fails on its first query is strictly worse to operate. ## Layer 3 — command-line overrides for one-offs `EngineMain`'s `main` reads its arguments. Beyond the well-known `-port=` and `-host=`, it accepts `-config=` to point at an alternative file and `-P:path.to.key=value` to override any single configuration path. This is the right tool for a local run against staging or a debugging session — not for the standing deployment, which should be reproducible from the environment alone. ## What to say about secrets Three points separate a senior answer from a middling one. **Never a literal in the file.** The committed config carries the *key*, not the value. Anything with a literal secret is a leak the moment the repo is cloned, and rotating it becomes a code change. **Validate at startup, not at use.** Map configuration into typed settings inside the module function using the throwing accessor. Deploy pipelines watch for a process that fails to come up; they do not watch for a handler that starts 500ing under load. **Do not log the values.** Log that configuration loaded and which environment was selected, never the resolved secrets. If a startup summary is useful, log key names and whether each was supplied. ## The anti-pattern to name Sprinkling `System.getenv("DATABASE_URL")` through the code bypasses the config tree. Now the service has two configuration channels, only one of which is discoverable from the file; tests cannot override the second without mutating process environment; and nobody can enumerate what the service actually reads. Routing everything through `environment.config` keeps a single, inspectable surface — the environment becomes a *source* feeding it rather than a competing mechanism. ## A workable shape ``` data class AppSettings(val dbUrl: String, val dbPassword: String) fun Application.settings(): AppSettings { val db = environment.config.config("app.db") return AppSettings( dbUrl = db.property("url").getString(), dbPassword = db.property("password").getString(), ) } ``` Call it once at the top of the module. Every downstream component takes `AppSettings`, which makes them trivially testable and makes the configuration contract a compile-time type rather than a set of strings scattered across handlers. ## Container detail worth knowing Many platforms inject the port as `PORT` and expect the process to bind it; that is exactly what `port = ${?PORT}` covers. Also bind the host to `0.0.0.0` rather than `localhost` in a container, since a loopback bind is unreachable from outside the container regardless of correct port configuration.