cd /news/developer-tools/persistent-503-error-between-private… · home topics developer-tools article
[ARTICLE · art-52250] src=discuss.huggingface.co ↗ pub= topic=developer-tools verified=true sentiment=↓ negative

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.

read2 min views2 publishedJul 9, 2026

Personally, this (and Space-to-Space requests to *.hf.space return 503 from awselb (since Jul 8)) looks more like a regression to me. Details below:

just in case, @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, documents authenticated access to private Space endpoints, and also documents calling one Space from another Space. 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 describes exposing an application through app_port

, and the Spaces networking documentation allows outbound HTTP/HTTPS traffic on ports 80 and 443. The official private Tabby Docker Space example 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. 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 ** large application-side changes**. Rebuilding all five Spaces again, changing the model- 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.

── more in #developer-tools 4 stories · sorted by recency
── more on @hugging face 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
Live at https://your-agent.zahid.host
Get free account → Pricing
from €0/mo · no card required
LIVE [news/persistent-503-error…] indexed:0 read:2min 2026-07-09 ·