docs/v5/architecture/responsibility-split.md
Use this as the first check when deciding where a new feature belongs.
| Question | Owner |
|---|---|
| What should happen for this user, team, app, database, or deployment? | Coolify |
| Which connected host should receive this request? | Coolify chooses, Flux routes |
| How do we get a command to a NATed host? | Flux |
| Do this concrete operation on this host. | coold |
| Is this allowed for this Coolify user/team? | Coolify |
| Is this host operation dangerous even if Coolify asked for it? | coold deny filter |
Flux does not inspect product meaning. containers.start is just a frame to a
host; Flux does not know it is part of an nginx deployment.
coold does not store Coolify secrets, users, teams, app ownership, deployment history, billing data, or business audit.
If a different orchestrator could reuse the same operation with its own app model, it probably belongs in coold. If the operation only makes sense because of Coolify's product model, it belongs in Coolify.