# Persistent 503 Error Between Private Docker Spaces

> Source: <https://discuss.huggingface.co/t/persistent-503-error-between-private-docker-spaces/177610#post_2>
> Published: 2026-07-09 07:59:28+00:00

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.