ntask staging runs a second nginx that cannot start: two stacks, one 80/443

[acamarata]

Surfaced while restoring the ɳTask staging stack (it had been returning HTTP 500 for days; postgres was missing entirely — fixed by #293).

The remaining wart

The staging box hosts two nSelf stacks, nself-web and ntask. Both compose files define an nginx service binding 80/443. nself-web_nginx owns them and is the real ingress — it holds the api.task.staging.nself.org server block and proxies to ntask_hasura:8080, and it is attached to both docker networks so it can reach across.

ntask_nginx therefore can never start. It crash-looped until I stopped it and cleared its restart policy.

Everything is green with it down:

https://api.task.staging.nself.org/healthz   HTTP 200
https://task.staging.nself.org               HTTP 200

But that is a manual intervention that nself start will undo, because the generated compose still defines the service.

What is actually missing

There is no supported way to say "this project does not run its own ingress; something else fronts it". Grepping for NGINX_ENABLED, NGINX_DISABLE and similar in internal/config and internal/build returns nothing.

That gap is what produced the side-channel docker-compose.staging-live.yml on this box — a hand-maintained compose file the nSelf-First doctrine forbids, which exists because the generated one could not express the deployment.

Suggested shape

An env toggle honoured by nself build that omits the service from the generated compose entirely, rather than generating it and relying on the operator to stop it. Something like:

NGINX_ENABLED=false     # this project is fronted by an external ingress

Whatever the name, the property that matters is that nself build && nself start on a second co-located project produces a stack that comes up clean with no manual steps.

Related

• fix(start): check the ports the stack publishes, not the nSelf defaults #293 fixed the other half: the port pre-flight checked hardcoded defaults instead of the ports the project publishes, so a correctly reconfigured second stack was blocked over ports it never binds.
• This one is the same theme — the two-servers-only constraint means co-locating stacks is normal, and the tooling assumes one stack per host.

Not urgent: staging is serving 200s. But it will regress the next time anyone runs nself start there.