Skip to main content

​
The default

Without any setting, the platform picks the shallowest Ktor module, the one with the fewest : levels in its Gradle path. If several are equally shallow, it picks the first in alphabetical order. So :api wins over :services:billing, and :admin wins over :api.

​
Choosing it with atoll.primary

Set the atoll.primary Gradle property to the module’s path. The usual place is gradle.properties at the root of your build:
Commit the file so every deployment uses the same primary module. Rules:
  • The value is a Gradle path such as :api or :services:gateway.
  • It must name a Ktor module of the project. If it does not, the deployment fails with a message that lists the Ktor modules the platform found, e.g. “atoll.primary is set to ‘:web’, which is not a Ktor module of this project (Ktor modules: :admin, :api)”.
  • It only applies to Ktor modules. The primary web module is always the shallowest one.

​
Changing the primary module

Change the property and deploy. The bare host moves to the new module once that module is up and running. Until then, the old primary keeps serving it, so the switch has no gap.

​
Where you see it

atoll deploy and the panel mark the primary target:
Custom domains point at the primary module unless you name another module.