{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreigq3eftii4h5xhs2y4szipq3ykct2l6sazvdsdoogpz4jac4mh2sa",
    "uri": "at://did:plc:pgryn3ephfd2xgft23qokfzt/app.bsky.feed.post/3ml7rjjnxph42"
  },
  "path": "/t/space-stuck-on-preparing-space-for-12-hours-despite-successful-build/175770#post_2",
  "publishedAt": "2026-05-06T22:33:02.000Z",
  "site": "https://discuss.huggingface.co",
  "tags": [
    "Spaces Configuration Reference",
    "Streamlit Spaces",
    "Spaces Changelog — Deprecate Streamlit SDK",
    "Space perpetually stuck on “Preparing Space” after previously working",
    "Space stuck in preparing step",
    "Stuck “Preparing Space”",
    "Space stuck at “Preparing” forever — no logs, reset doesn’t work",
    "“Running” displayed while Space is stuck in “Preparing”",
    "Hugging Face Space discussion mentioning website@huggingface.co"
  ],
  "textContent": "There have been similar code-related issues in the past, but the cases where the process gets stuck on “Preparing” can’t be explained by the code alone. As for the issue where it gets stuck on “Preparing” indefinitely, there was a similar case in the past due to a glitch on Hugging Face.\n\n* * *\n\n### Analysis and debugging hints\n\nThis looks less like a normal application build failure and more like either:\n\n  1. a **Hugging Face Spaces deployment/status/readiness stuck state** , or\n  2. a **runtime/port configuration mismatch** , especially if this is a Docker Space running Streamlit.\n\n\n\nThe important clues are:\n\n  * the build logs reportedly complete successfully;\n  * the container logs reportedly show Streamlit starting on port `8501`;\n  * the Space remains stuck on **“Preparing Space”** for 12+ hours;\n  * restarting the Space does not clear the state;\n  * the Space is on a paid CPU Upgrade plan.\n\n\n\nThat combination usually points away from a simple `requirements.txt` failure or Python traceback. If the app process has really started, but the Hub UI still stays on **Preparing Space** , then the remaining question is whether Hugging Face’s routing/readiness layer can actually reach the app.\n\n### First thing to check: SDK type and port contract\n\nPlease check the YAML block at the top of your `README.md`.\n\nHugging Face Spaces are configured through README YAML:\n\n  * Spaces Configuration Reference\n\n\n\nThe key distinction is whether this is a Streamlit SDK Space or a Docker Space.\n\n#### Case A: Streamlit SDK Space\n\nIf your README says something like:\n\n\n    sdk: streamlit\n    app_file: app.py\n\n\nthen port `8501` is expected.\n\nHugging Face’s Streamlit Spaces documentation says Streamlit Spaces use port `8501`, and warns not to override it in `.streamlit/config.toml`:\n\n  * Streamlit Spaces\n\n\n\nSo if this is `sdk: streamlit`, I would check:\n\n\n    1. Is there a .streamlit/config.toml file?\n    2. If yes, does it override the port?\n    3. If it overrides the port away from 8501, remove that override.\n    4. If it does not override the port, then port 8501 is probably not the issue.\n\n\nAlso note that Hugging Face has deprecated Streamlit as a default built-in SDK option. New Streamlit Spaces are now expected to use the Docker SDK with the Streamlit template:\n\n  * Spaces Changelog — Deprecate Streamlit SDK\n  * Streamlit Spaces\n\n\n\nThat does not automatically mean your current Space is broken because of the deprecation, but it is useful context.\n\n#### Case B: Docker Space\n\nIf your README says:\n\n\n    sdk: docker\n\n\nthen the port contract is different.\n\nFor Docker Spaces, the Spaces Configuration Reference says `app_port` defaults to `7860`.\n\nStreamlit normally starts on `8501`, so if this is a Docker Space and Streamlit is listening on `8501`, your README should explicitly include:\n\n\n    sdk: docker\n    app_port: 8501\n\n\nFor Docker, I would make sure all three layers agree:\n\n\n    README.md:\n    app_port: 8501\n\n    Dockerfile:\n    EXPOSE 8501\n\n    Startup command:\n    streamlit run app.py --server.port=8501 --server.address=0.0.0.0\n\n\nIf Docker is exposing `7860` while Streamlit is listening on `8501`, the container can look “started” in the logs while the Space remains unreachable from Hugging Face’s proxy/readiness layer.\n\n### Why 12+ hours is suspicious\n\nA Space staying in **Preparing Space** for 12+ hours is not a normal startup delay.\n\nThe Spaces config docs describe `startup_duration_timeout` as the maximum time a Space is allowed to start before being considered unhealthy, with a default of 30 minutes:\n\n  * Spaces Configuration Reference\n\n\n\nSo if the Space is still in **Preparing Space** after many hours, especially after a restart, that suggests something is stuck beyond the normal app startup window.\n\n### Similar historical reports\n\nThere are several similar reports where a Space stayed stuck in `Preparing`, `Building`, or a misleading status state even though the user had already tried restart/rebuild/factory rebuild:\n\n  * Space perpetually stuck on “Preparing Space” after previously working\n  * Space stuck in preparing step\n  * Stuck “Preparing Space”\n  * Space stuck at “Preparing” forever — no logs, reset doesn’t work\n  * “Running” displayed while Space is stuck in “Preparing”\n\n\n\nSo I would not treat this as a completely new class of problem. It looks more like a recurrence or variant of an existing Spaces stuck-state pattern, unless the README/Docker port configuration turns out to be wrong.\n\n### Practical checks I would do next\n\n#### 1. Check README YAML\n\nPlease paste or inspect the YAML block at the top of `README.md`.\n\nUseful fields:\n\n\n    sdk: <sdk-type>\n    app_file: <app-file>\n    app_port: <app-port-if-docker>\n    python_version: <python-version-if-set>\n    startup_duration_timeout: <timeout-if-set>\n\n\nMost important question:\n\n\n    Is this sdk: streamlit or sdk: docker?\n\n\n#### 2. Check direct Space URL\n\nTry the direct runtime URL, not only the Hub page:\n\n\n    https://<space-subdomain>.hf.space/\n\n\nIf the direct `.hf.space` URL loads but the Hub page still says **Preparing Space** , that strongly suggests a Hugging Face status/UI/control-plane mismatch.\n\nIf the direct `.hf.space` URL does not load, then the problem is more likely readiness/proxy/port/startup-related.\n\n#### 3. Check whether the app binds to the correct host\n\nFor Docker or custom server setups, the app should bind to:\n\n\n    0.0.0.0\n\n\nnot only:\n\n\n    localhost\n    127.0.0.1\n\n\nFor Streamlit Docker, the command should look like:\n\n\n    streamlit run app.py --server.port=8501 --server.address=0.0.0.0\n\n\n#### 4. Check for silent runtime failure after startup\n\nSometimes the log line saying Streamlit started is not the final story. The app may start, then crash or hang while loading a model, file, database, cache, or secret.\n\nI would check whether the container logs show anything after the Streamlit startup line:\n\n\n    Out-of-memory?\n    Permission denied?\n    Missing file?\n    Download timeout?\n    Auth/token error?\n    Model loading hang?\n    Cache path issue?\n\n\n#### 5. Check whether the app relies on files created during a previous session\n\nSpaces should be treated as rebuildable from a clean state. If the app depends on files that were created interactively, cached in a previous container, or written to ephemeral disk, a rebuild/restart may lose them.\n\nThis can create confusing “it worked before, then got stuck after restart/rebuild” behavior.\n\n### My current estimate\n\nBased on the symptoms you described, my estimate would be:\n\n\n    Most likely:\n    A Spaces-side stuck deployment/status/readiness/proxy state.\n\n    Also plausible:\n    Docker Space port mismatch: Streamlit listens on 8501, but app_port is missing or still 7860.\n\n    Less likely:\n    Normal dependency installation failure, because the build reportedly succeeds.\n\n    Less likely but still possible:\n    The app starts Streamlit successfully, then hangs or crashes during model/data initialization.\n\n\n### When to contact Hugging Face Support\n\nIf the README/Docker/port settings look correct and the Space is still stuck, I would contact Hugging Face Support.\n\nThere are forum discussions where users are directed to contact:\n\n\n    website@huggingface.co\n\n\nExample:\n\n  * Space perpetually stuck on “Preparing Space” after previously working\n  * Hugging Face Space discussion mentioning website@huggingface.co\n\n\n\nWhen contacting support, include enough information for them to inspect the stuck deployment state directly.\n\nUseful information to include:\n\n\n    Space URL:\n    <space-url>\n\n    Account / namespace:\n    <account-or-org>\n\n    SDK type:\n    <sdk: streamlit OR sdk: docker OR other>\n\n    README YAML:\n    <full README YAML block>\n\n    If Docker:\n    <app_port value>\n    <Dockerfile EXPOSE line>\n    <startup command>\n\n    Hardware:\n    <CPU Basic / CPU Upgrade / GPU type / other>\n\n    Latest commit SHA:\n    <commit-sha>\n\n    Approximate time the issue started:\n    <timestamp + timezone>\n\n    Direct .hf.space URL status:\n    <loads / does not load / status code / screenshot>\n\n    Build log final lines:\n    <final 20-50 lines>\n\n    Container log excerpt:\n    <lines showing Streamlit started on port 8501>\n    <any lines after startup>\n\n\n### Suggested wording for the support request\n\n\n    Hello Hugging Face Support,\n\n    My Space appears to be stuck on “Preparing Space” for more than 12 hours despite a successful build.\n\n    Space URL:\n    <space-url>\n\n    Account / namespace:\n    <account-or-org>\n\n    Hardware:\n    <hardware-plan>\n\n    Issue summary:\n    - The Space has been stuck on “Preparing Space” for over 12 hours.\n    - Build logs appear to complete successfully.\n    - Container logs show Streamlit starting successfully on port 8501.\n    - Restarting the Space does not resolve the issue.\n    - The Space is on a paid CPU Upgrade plan.\n\n    I have checked the likely port/configuration issue:\n\n    SDK type:\n    <sdk-type>\n\n    README YAML:\n    <readme-yaml>\n\n    If this is a Docker Space, app_port is:\n    <app-port-value>\n\n    If this is a Streamlit SDK Space, I understand Streamlit Spaces normally use port 8501.\n\n    Because the app process appears to start successfully in the container logs, this looks more like the Space deployment/status/readiness/proxy layer is stuck and not transitioning the Space to a usable running state.\n\n    Could you please force-restart, clear the stuck deployment state, or investigate the Spaces readiness/proxy/status state for this Space?\n\n    Additional details:\n\n    Latest commit SHA:\n    <commit-sha>\n\n    Approximate time the issue started:\n    <timestamp-timezone>\n\n    Direct .hf.space URL status:\n    <direct-url-status>\n\n    Build log excerpt:\n    <build-log-excerpt>\n\n    Container log excerpt:\n    <container-log-excerpt>\n\n    Thank you.\n\n\n### Short version\n\n  * If this is `sdk: docker`, verify `app_port: 8501`.\n  * If this is `sdk: streamlit`, port `8501` is expected, but check that `.streamlit/config.toml` is not overriding it.\n  * If the build succeeds and Streamlit starts, but the Space stays in **Preparing Space** for 12+ hours, this likely points to a stuck Spaces deployment/status/readiness state.\n  * If the direct `.hf.space` URL works while the Hub UI still says **Preparing** , that points even more strongly to a status/control-plane mismatch.\n  * If config looks correct, emailing `website@huggingface.co` with the Space URL, logs, README YAML, SDK type, hardware, commit SHA, and direct `.hf.space` status is appropriate.\n\n",
  "title": "Space stuck on \"Preparing Space\" for 12+ hours despite successful build"
}