Persistent 503 Error Between Private Docker Spaces

Hugging Face users report a persistent 503 error when making server-side requests from one private Docker Space to another, despite individual features being documented as supported. The issue appears to be a regression since July 8, as external requests succeed while internal Space-to-Space calls fail. Hugging Face is urged to clarify whether cross-Space requests are still intended to work or provide a documented alternative.

Personally, this and Space-to-Space requests to .hf.space return 503 from awselb since Jul 8 https://discuss.huggingface.co/t/space-to-space-requests-to-hf-space-return-503-from-awselb-since-jul-8/177607 looks more like a regression to me. Details below: just in case, @hysts https://discuss.huggingface.co/u/hysts Direct answer: the general architecture does not appear to be inherently unsupported. Hugging Face documents Docker Spaces as suitable for FastAPI and other API endpoints https://huggingface.co/docs/hub/spaces-sdks-docker , documents authenticated access to private Space endpoints, and also documents calling one Space from another Space https://huggingface.co/docs/hub/spaces-api-endpoints . I could not find one official reference that combines this exact topology—private Docker caller, private Docker target, arbitrary FastAPI route, and server-side Bearer authentication—but the individual pieces are documented or have prior working examples. For a private Docker Space, the route I would expect to use is still: caller Space → HTTPS on port 443 → https://<target-subdomain .hf.space/<route → Authorization: Bearer <token that can access the target Space → target application The Docker Spaces documentation https://huggingface.co/docs/hub/spaces-sdks-docker describes exposing an application through app port , and the Spaces networking documentation https://huggingface.co/docs/hub/spaces-overview networking allows outbound HTTP/HTTPS traffic on ports 80 and 443. The official private Tabby Docker Space example https://github.com/huggingface/hub-docs/blob/main/docs/hub/spaces-sdks-docker-tabby.md also uses the direct .hf.space URL as an API endpoint and adds an authorization header when the Space is private. The strongest reason I would currently suspect a regression is the independent report in Space-to-Space requests to .hf.space return 503 from awselb https://discuss.huggingface.co/t/space-to-space-requests-to-hf-space-return-503-from-awselb-since-jul-8/177607 . That report describes: 200 outside Hugging Face but 503 from inside a Space;If those controls are accurate, this is difficult to explain purely as a Dockerfile, FastAPI route, token-scope, private-visibility, DNS, or single-Space deployment problem. For now, I would pause large application-side changes . Rebuilding all five Spaces again, changing the model-loading code, or increasing retries is unlikely to isolate a source-dependent platform issue. A small inside-vs-outside comparison with exact timestamps is likely to be more useful. awselb header or the missing Run Log entry. It is the independently reported difference between an external caller receiving 200 and a Space caller receiving 503 from the same target.The key question for HF is whether server-side requests from one Space to another .hf.space endpoint are still intended to work. If they are, the current evidence appears to warrant platform-side investigation. If they are not, the supported replacement route needs to be documented.