Persistent 404 on Docker Space - app_port routing seems to be ignored (User: josejar)

Spaces
1

Hello Hugging Face community and team,

I am writing to report a persistent and blocking issue with every Docker-based Space I create. I have tried all troubleshooting steps and I’m hoping someone can help. I am posting this without links due to the new user filter.

The Problem:
My Docker Spaces consistently return a 404 error on their public URL. The application logs confirm a successful startup on the correct internal port, so the core issue seems to be that the app_port directive in my README.md is being ignored by the platform’s router.

My test Spaces can be found by navigating to a user’s Spaces and looking for the paths:

  • josejar/n8n_2

  • josejar/n8napp

Expected Behavior:
The public URL of the Space should route traffic to my application.

Actual Behavior:
A Hugging Face 404 page is displayed.

Configuration Details (Verified on all attempts):

  1. README.md:

Generated yaml

---
title: N8N Test App
sdk: docker
app_port: 5678
---

content_copydownload

Use code with caution.Yaml

  1. Dockerfile:

Generated dockerfile

FROM n8nio/n8n:latest
EXPOSE 5678

content_copydownload

Use code with caution.Dockerfile

  1. Application Logs: The logs always confirm a successful startup. The last lines typically state that the editor is accessible on “localhost port 5678”.

Troubleshooting Steps Performed (without success):

  • Verified README.md and Dockerfile configurations.

  • Confirmed all necessary secrets (WEBHOOK_URL, auth, etc.) are set.

  • Performed multiple Restarts and a full Factory Rebuild .

  • Created brand new, clean Spaces from scratch (the ones listed above by path).

The outcome is always the same: a perfect application log but a 404 on the public URL. This strongly suggests a platform-level issue.

Could the HF team please take a look at the routing for my account’s Spaces?

Thank you for your help.
User: josejar

1 Like
2

No spaces are showing up…
If you’re currently set to Public, it’s definitely a bug… @meganariley @pierric @hysts

3

Hello Hugging Face Team (@hysts @meganariley),

I am reporting a definitive bug in the platform’s routing/authentication layer for private Spaces.

Space: josejar/n8n_2

After an exhaustive debugging process, we have achieved a perfectly healthy container state. The application logs confirm a successful startup on the correct port and host (0.0.0.0:5678), and the container is running without errors.

Here is the conclusive evidence of the platform bug:

  1. When the Space is set to Public: It works perfectly and is accessible.

  2. When the Space is immediately switched back to Private: It instantly returns a 404 error, even when I am logged into my account.

This A/B test proves that the container and its configuration are correct. The failure point is exclusively the private visibility setting. The authentication layer is incorrectly denying access to the owner of the Space, resulting in a 404.

This issue is blocking the use of private Docker Spaces on my account. Could you please investigate the authentication proxy or routing rules for my account’s private Spaces?

Thank you for your help.

1 Like
5

Hello everyone,

I wanted to share the solution to a problem that was driving me crazy for a while, hoping it will save someone else some time.

The Problem

One day, I suddenly couldn’t access my private Hugging Face Space from my Brave browser. The symptoms were very confusing:

  • The application wouldn’t load in the embedded window (the <iframe>).
  • Even stranger, if I tried to access the direct URL (my-user-hf.co/spaces/my-space), it would also fail or give me an error, even though I was correctly logged into my Hugging Face account.

I started thinking I had broken something in my Dockerfile, that it was a Hugging Face bug, or that the direct URL simply didn’t work for private Spaces.

The Real Cause: The Browser’s Privacy Shields

After a lot of testing, I discovered the problem wasn’t Hugging Face, but my own browser’s privacy protections (Brave Shields). This also applies to Firefox’s “Enhanced Tracking Protection.”

Here’s what’s happening:
For Hugging Face to grant you access to your private Space (either in the embedded view or via the direct URL), your Space on the ...hf.space domain needs to “talk” to the huggingface.co domain to verify that it’s you and that you’re logged in.

Brave sees this communication between two different domains and, by default, classifies it as “cross-site tracking” and blocks it to protect your privacy. By blocking this, the authentication process fails, and Hugging Face denies you access.

The Solution (It’s very simple)

The solution is to tell Brave to trust your Space’s page and not to apply its shields to it.

  1. Navigate to your private Space’s page on Hugging Face (the one with the URL huggingface.co/spaces/...).
  2. Click the orange lion icon for Brave Shields in the address bar.
  3. In the panel that opens, click the main toggle switch at the top to turn the shields off (“Shields are UP” → “Shields are DOWN”).
  4. The page will reload.

And that’s it! After doing this, everything magically starts working again:

  • The application loads in the embedded window.
  • The direct URL (...hf.space) of your private Space also works perfectly, because the authentication process is no longer being blocked.

I hope this helps anyone who runs into this frustrating issue. Before you start changing your code, check your browser’s shields!

Best regards.

1 Like