Revert "the orchestrator image serves its own admin GUI" — wrong layer
A pod image is never an orchestrator; the full image always is. Acting on
the Digesta report's second option put orchestrator behaviour into
codai.api.app, which is what a RENTED POD runs, and that is wrong in three
separate ways:
- the GUI pages are not under BearerAuthMiddleware (it guards /v1/* only),
so every rented pod would have served /admin and /login on its public
address;
- the first-admin bootstrap would have created an admin account, with a
password in the pod's log, in each pod's throwaway auth.json;
- initialising the session manager would have broken allow_open_pod, where
the operator deliberately launches a pod with no token: the pod would
then refuse every request instead of accepting all of them.
Reverted all three. Bug 1 stays — /health and /v1/health are a genuine
pod-side fix, since surya probes {service_url}/health.
The real Bug 3 is elsewhere and the report's premise was also wrong:
server.engines=0 does not mean "no engines", it means AUTO — "one per
detected GPU, min 1" (config.py:70) — which is why their host kept spawning
engine#0. A true GPU-less orchestrator in the full image needs its own
change, not a flag that already exists.
Co-Authored-By:
Claude Opus 5 <noreply@anthropic.com>
Showing
Please
register
or
sign in
to comment