# HF Space "Static SDK is not supported" **URL:** \ **Category:** Spaces\ **Created:** [February 7, 2026, 10:39am UTC](https://discuss.huggingface.co/t/hf-space-static-sdk-is-not-supported/173178 "2026-02-07T10:39:14Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![ggcristian](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/ggcristian/32/47208_2.png) [@ggcristian](https://discuss.huggingface.co/u/ggcristian)\ **Post date:** [February 7, 2026, 10:39am UTC](https://discuss.huggingface.co/t/hf-space-static-sdk-is-not-supported/173178/1 "2026-02-07T10:39:14Z")
Hi there, We just migrated our HF space from Gradio to a static React site. I build it locally with `bun run build` and then I simply commit the `dist/` and add the following to our `README.md`: ``` sdk: static app\_file: dist/index.html ``` The site lacks a `app_build_command`. Is this a problem? After a while I noticed our HF space went onto a Configuration Error saying “Static SDK is not supported” but it was working fine when I first deployed it. ---
**Author:** ![John6666](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/john6666/32/27664_2.png) [@John6666](https://discuss.huggingface.co/u/John6666)\ **Post date:** [February 7, 2026, 12:16pm UTC](https://discuss.huggingface.co/t/hf-space-static-sdk-is-not-supported/173178/2 "2026-02-07T12:16:31Z")
That probably won’t be a problem… Sometimes the cache causes issues; in those cases, you can clear it by making a meaningless change to the `sdk:` line and then reverting it… * * * ## Is it a problem that you don’t have `app_build_command`? No. Static Spaces can work in **either** of these modes: 1. **You commit the built files** (e.g., `dist/`) and set `app_file` to the HTML entrypoint. 2. **Hugging Face builds for you** by running `app_build_command` on every update and then serving the output from a special build ref (`refs/convert/build`). ([Hugging Face](https://huggingface.co/docs/hub/en/spaces-sdks-static "Static HTML Spaces")) So missing `app_build_command` is only a problem if `dist/index.html` is not present (or not where `app_file` points) in the repo revision the Space is serving. * * * ## Why it “worked at first” and then later changed to “Static SDK is not supported” That message is a _configuration-level_ failure. In practice it usually comes from one of these: ### 1) Your README config is not being parsed as Spaces configuration (very common) Spaces only read settings from the **YAML front-matter block at the very top of `README.md`**. ([Hugging Face](https://huggingface.co/docs/hub/en/spaces-config-reference "Spaces Configuration Reference")) If you literally added: ```md sdk: static app_file: dist/index.html ``` …but **not** inside a top-of-file YAML front-matter block, Hugging Face may ignore it and fall back into a “configuration error” state. **What “correct” looks like:** ```md --- sdk: static app_file: dist/index.html --- ``` **Pitfalls that break parsing** - The YAML block is **not the first thing** in the README (badges/text above it). - It’s inside a Markdown code fence (```). - It contains placeholders or invalid YAML. - It was edited later and became malformed. There are public examples where a misconfigured/template README ends up showing the same “Static SDK is not supported” configuration error page. ([Hugging Face](https://huggingface.co/spaces/huggingface/okta-saml-integration-guide "Okta SAML integration guide - a Hugging Face Space by ...")) **Why the delay?** - The Space can appear fine until a rebuild/restart causes Hugging Face to re-evaluate config strictly, or until a platform-side validation change takes effect. * * * ### 2) Your Space is still set to **ZeroGPU** from the old Gradio setup ZeroGPU has a hard constraint: **ZeroGPU Spaces are exclusively compatible with the Gradio SDK** , not static. ([Hugging Face](https://huggingface.co/docs/hub/en/spaces-zerogpu "Spaces ZeroGPU: Dynamic GPU Allocation for Spaces")) **Why the delay?** - It might run briefly (or show cached content), then once the runtime config is enforced/rebuilt it flips into an error state. **Fix** - Space **Settings → Hardware** : switch away from ZeroGPU to a CPU tier (or standard GPU where applicable), then rebuild. * * * ### 3) Dev Mode is enabled **Dev Mode is not available for static Spaces.** ([Hugging Face](https://huggingface.co/docs/hub/en/spaces-dev-mode "Spaces Dev Mode: Seamless development in Spaces")) **Fix** - Space **Settings → Dev Mode** : disable, then rebuild. * * * ### 4) `app_file` path format/validation changed (edge case) A recent “it randomly stopped working” case was caused by `app_file` syntax being slightly off and fixed by changing `./index.html` → `index.html`. ([Hugging Face Forums](https://discuss.huggingface.co/t/my-space-randomly-stopped-working-no-application-file/170511 "My space randomly stopped working. "No application file"")) Your `dist/index.html` form is the recommended pattern in the docs, but it’s worth verifying you didn’t accidentally use a leading `./` or `/` in the actual README. ([Hugging Face](https://huggingface.co/docs/hub/en/spaces-sdks-static "Static HTML Spaces")) * * * ### 5) `dist/` is missing (or stale) in the revision being served If you don’t use `app_build_command`, Hugging Face serves whatever is committed. If `dist/index.html` isn’t present (or you pushed a commit without rebuilding locally), you can land in a broken state. **Fix** - In the Space “Files” view, confirm `dist/index.html` exists on the current commit and matches `app_file`. * * * ## What I would do for _your_ case (fastest path) ### Step 1 — Make the README config unquestionably valid Put this **as the first lines** of `README.md` (no text above it): ```md --- sdk: static app_file: dist/index.html --- ``` This is required because Spaces configuration is read from the README YAML block. ([Hugging Face](https://huggingface.co/docs/hub/en/spaces-config-reference "Spaces Configuration Reference")) ### Step 2 — Check Settings for static-incompatible modes - If Hardware is **ZeroGPU** → change to CPU. ([Hugging Face](https://huggingface.co/docs/hub/en/spaces-zerogpu "Spaces ZeroGPU: Dynamic GPU Allocation for Spaces")) - If **Dev Mode** is enabled → disable it. ([Hugging Face](https://huggingface.co/docs/hub/en/spaces-dev-mode "Spaces Dev Mode: Seamless development in Spaces")) ### Step 3 — Verify the entrypoint exists Confirm the repository (current commit) contains: `dist/index.html` and that it loads without needing server-side routing. * * * ## “Should we add `app_build_command` anyway?” It’s optional, but often improves reliability for teams because it prevents “forgot to commit dist” and makes deploys reproducible. Static docs describe this build mode: Hugging Face runs your build command on each update and serves the output from `refs/convert/build`. ([Hugging Face](https://huggingface.co/docs/hub/en/spaces-sdks-static "Static HTML Spaces")) A typical config: ```md --- sdk: static app_build_command: npm ci && npm run build app_file: dist/index.html --- ``` (You can use bun, but the most predictable path is using the toolchain Hugging Face documents directly—`npm run build`—unless you’ve verified bun availability in the build environment.) ([Hugging Face](https://huggingface.co/docs/hub/en/spaces-sdks-static "Static HTML Spaces")) * * * ## Quick checklist mapping to your symptoms - You pasted config **without** `---` front-matter → very likely cause. ([Hugging Face](https://huggingface.co/docs/hub/en/spaces-config-reference "Spaces Configuration Reference")) - Space previously used **ZeroGPU** with Gradio → likely cause. ([Hugging Face](https://huggingface.co/docs/hub/en/spaces-zerogpu "Spaces ZeroGPU: Dynamic GPU Allocation for Spaces")) - Dev Mode enabled during debugging → likely cause. ([Hugging Face](https://huggingface.co/docs/hub/en/spaces-dev-mode "Spaces Dev Mode: Seamless development in Spaces")) - `app_file` format subtly changed (`./…`) → possible. ([Hugging Face Forums](https://discuss.huggingface.co/t/my-space-randomly-stopped-working-no-application-file/170511 "My space randomly stopped working. "No application file"")) ---
**Author:** ![ggcristian](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/ggcristian/32/47208_2.png) [@ggcristian](https://discuss.huggingface.co/u/ggcristian)\ **Post date:** [February 8, 2026, 11:05am UTC](https://discuss.huggingface.co/t/hf-space-static-sdk-is-not-supported/173178/3 "2026-02-08T11:05:43Z")
No more problems since I re-built the site. I guess there was a problem with the previous space cache (using gradio SDK) and the new one using Static SDK ---
**Author:** ![ggcristian](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/ggcristian/32/47208_2.png) [@ggcristian](https://discuss.huggingface.co/u/ggcristian)\ **Post date:** [February 10, 2026, 9:32am UTC](https://discuss.huggingface.co/t/hf-space-static-sdk-is-not-supported/173178/4 "2026-02-10T09:32:52Z")
Woops, same issue, worked for 2 days, today it shows again the “Static SDK is not supported”. Is there a way I can see the logs to troubleshoot possible causes and problems? Is Static SDK without a build command not free? The space is this one: [TuRTLe Leaderboard - a Hugging Face Space by HPAI-BSC](https://huggingface.co/spaces/HPAI-BSC/TuRTLe-Leaderboard) Here is the `README.md`: `title: TuRTLe Leaderboard` `emoji: 🐢` `colorFrom: gray` `colorTo: green` `sdk: static` `app_file: dist/index.html` `pinned: true` `license: apache-2.0` `short_description: A Unified Evaluation of LLMs for RTL Generation.` ---
**Author:** ![ggcristian](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/ggcristian/32/47208_2.png) [@ggcristian](https://discuss.huggingface.co/u/ggcristian)\ **Post date:** [February 10, 2026, 4:16pm UTC](https://discuss.huggingface.co/t/hf-space-static-sdk-is-not-supported/173178/5 "2026-02-10T16:16:54Z")
I run a duplicated private HF space in my personal account and hasn’t had any Configuration Error at all ---
**Author:** ![John6666](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/john6666/32/27664_2.png) [@John6666](https://discuss.huggingface.co/u/John6666)\ **Post date:** [February 11, 2026, 5:38am UTC](https://discuss.huggingface.co/t/hf-space-static-sdk-is-not-supported/173178/6 "2026-02-11T05:38:09Z")
The below long output is purely a general observation. Personally, when encountering frequent minor yet peculiar errors like this, I’ve found it wise to also consider the possibility that the site is undergoing some changes, causing unstable behavior, or that some incorrect flags are set in the space… (When caused by incorrect flags, the same code often runs without issues in a separately created space. For caching issues, creating a separate space is usually the simplest fix.)🤔 * * * ## What that error actually means On Hugging Face Spaces, **“Static SDK is not supported” is a _configuration-layer_ failure** , not a “your JS crashed” runtime failure. It typically appears when the Hub **can’t (or won’t) apply `sdk: static` for that Space**, so it falls back to a generic “configuration error” page (the one that shows the “Base README.md template”). You can see the exact same config-error page pattern in other public Spaces, e.g. `lmarena-ai/lmarena-leaderboard` and `victor/sveltekit-space`. ([Hugging Face](https://huggingface.co/spaces/lmarena-ai/lmarena-leaderboard "LMArena Leaderboard - a Hugging Face Space by lmarena-ai")) * * * ## Is `app_build_command` required? No. Hugging Face supports two “static” modes: 1. **Commit built assets** (your approach): you push `dist/` and set `app_file` to the HTML entry point. 2. **Build on Hugging Face** : you set `app_build_command`, and HF runs it on updates, then serves the output. ([Hugging Face](https://huggingface.co/docs/hub/en/spaces-sdks-static "Static HTML Spaces - Hugging Face")) So the absence of `app_build_command` is only a problem if **`dist/index.html` is missing or wrong**. In _your_ repo, the config is present and correctly formatted as front-matter, and `dist/index.html` exists. ([Hugging Face](https://huggingface.co/spaces/HPAI-BSC/TuRTLe-Leaderboard/blob/main/README.md?code=true "README.md · HPAI-BSC/TuRTLe-Leaderboard at main")) * * * ## Can you see logs for this kind of failure? ### 1) Where logs normally are For “normal” (container-based) Spaces, HF exposes logs via the **Logs tab / Logs UI**. ([Hugging Face Forums](https://discuss.huggingface.co/t/debugging-spaceses-application/71242 "Debugging Spaceses Application - Spaces")) ### 2) What that means for Static Spaces A pure static Space **does not run an app server** , so there are typically: - **no container runtime logs** , because there’s no long-running container - **only build logs if you use `app_build_command`** (because then HF actually runs a build job) ([Hugging Face](https://huggingface.co/docs/hub/en/spaces-sdks-static "Static HTML Spaces - Hugging Face")) When you’re in **Configuration error** , you often won’t get meaningful “logs” because the platform is failing _before_ a build/run phase starts. * * * ## The most common causes (and fixes) ### Cause A — The Space is in a mode that Static doesn’t support (most likely in Gradio→Static migrations) Two settings are frequent culprits: #### A1) ZeroGPU still enabled HF’s ZeroGPU doc explicitly says: **“ZeroGPU Spaces are exclusively compatible with the Gradio SDK.”** ([Hugging Face](https://huggingface.co/docs/hub/spaces-zerogpu "Spaces ZeroGPU: Dynamic GPU Allocation for Spaces")) **Fix** - Space **Settings → Hardware** - Switch **away from ZeroGPU** to a CPU tier (or dedicated GPU), then rebuild/restart. #### A2) Dev Mode enabled HF Dev Mode doc explicitly says: **Dev Mode is not available for static Spaces.** ([Hugging Face](https://huggingface.co/docs/hub/en/spaces-dev-mode "Spaces Dev Mode: Seamless development in Spaces")) **Fix** - Space **Settings → Dev Mode** - Disable it, then rebuild/restart. **Why it “worked for 2 days”** These settings can look fine until a rebuild/restart/validation pass happens (sleep/wake, infra reschedule, manual restart), then the platform enforces the incompatibility and flips to config error. * * * ### Cause B — HF is not actually using your README config (YAML parsing / precedence issues) HF reads Space config from the **YAML front-matter block at the very top of README**. ([Hugging Face](https://huggingface.co/docs/hub/en/spaces-config-reference "Spaces Configuration Reference")) Common pitfalls: - Anything (badges, headings) above the `---` block - Putting the YAML inside a markdown code fence - YAML becoming invalid after an edit In your current `README.md`, the front-matter _looks correct_ in the file view. ([Hugging Face](https://huggingface.co/spaces/HPAI-BSC/TuRTLe-Leaderboard/blob/main/README.md?code=true "README.md · HPAI-BSC/TuRTLe-Leaderboard at main")) Still, if you edited via UI and introduced invisible formatting issues, it can cause intermittent “config not applied” behavior. **Fix** - Ensure the README starts exactly like this (first byte of file is the first `-`): - Commit a small change to the YAML block (e.g. toggle `pinned`), push, then revert (forces config re-evaluation). * * * ### Cause C — Static build steps may be paywalled in some situations Hugging Face’s static docs describe `app_build_command` as supported. ([Hugging Face](https://huggingface.co/docs/hub/en/spaces-sdks-static "Static HTML Spaces - Hugging Face")) However, multiple public Spaces currently show a **configuration error stating** : > “Static space builds require a paid plan. Subscribe to Team or Enterprise …” ([Hugging Face](https://huggingface.co/spaces/paloma-tfrere/fontmap "Fontmap - a Hugging Face Space by paloma-tfrere")) So: - **Static without `app_build_command`** : generally works as simple hosting (your approach). - **Static with `app_build_command`** : may trigger the paid-plan gate in some accounts/orgs (based on the error HF itself shows). ([Hugging Face](https://huggingface.co/spaces/paloma-tfrere/fontmap "Fontmap - a Hugging Face Space by paloma-tfrere")) If you add `app_build_command` just to “get logs”, you might hit that gate. **Workarounds if you need reproducible builds without HF build** - Build in CI and commit/push `dist/` (what you’re doing) - HF’s own blog suggests a “two-space” pattern: a Docker “builder” Space that builds and deploys to a static “site” Space. ([Hugging Face](https://huggingface.co/blog/severo/build-static-html-spaces "Build static HTML spaces")) * * * ### Cause D — Platform-side regression/outage (less common, but real) When very large/high-profile Spaces also show “Static SDK is not supported”, it can indicate an HF-side regression rather than your repo (example: `lmarena-ai/lmarena-leaderboard` showing the same configuration error page). ([Hugging Face](https://huggingface.co/spaces/lmarena-ai/lmarena-leaderboard "LMArena Leaderboard - a Hugging Face Space by lmarena-ai")) **What you can do** - Apply the fixes in A/B first (they’re quick and within your control) - If still broken, open a forum thread with: * * * ## What I would do for _your_ Space (ordered, fastest signal first) 1. **Check Settings → Hardware** If it’s **ZeroGPU** , switch to CPU. (Static + ZeroGPU is incompatible.) ([Hugging Face](https://huggingface.co/docs/hub/spaces-zerogpu "Spaces ZeroGPU: Dynamic GPU Allocation for Spaces")) 2. **Check Settings → Dev Mode** If enabled, disable it. (Static + Dev Mode is unsupported.) ([Hugging Face](https://huggingface.co/docs/hub/en/spaces-dev-mode "Spaces Dev Mode: Seamless development in Spaces")) 3. **Force a config refresh** 4. **Do not add `app_build_command` just for troubleshooting** unless you’ve confirmed your org/account won’t hit the “static build requires paid plan” gate. ([Hugging Face](https://huggingface.co/spaces/paloma-tfrere/fontmap "Fontmap - a Hugging Face Space by paloma-tfrere")) 5. If it still flips back after a day or two: Create a **brand-new Static HTML Space** under the same org and push only a minimal `dist/index.html` + README front-matter. If _that_ also breaks, it strongly points to **org-level restrictions or HF-side behavior** , not your app bundle. * * * ## Good references and similar cases - **Official docs** - **Logs / debugging** - **Similar failures** If you want the single most likely fix given “Gradio → Static” + “works, then breaks after ~2 days”: **ZeroGPU or Dev Mode still enabled in Settings** (static-incompatible), with the failure surfacing on a rebuild/revalidation. ([Hugging Face](https://huggingface.co/docs/hub/spaces-zerogpu "Spaces ZeroGPU: Dynamic GPU Allocation for Spaces")) ---
**Author:** ![ggcristian](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/ggcristian/32/47208_2.png) [@ggcristian](https://discuss.huggingface.co/u/ggcristian)\ **Post date:** [February 11, 2026, 2:14pm UTC](https://discuss.huggingface.co/t/hf-space-static-sdk-is-not-supported/173178/7 "2026-02-11T14:14:32Z")
We are not using ZeroGPU, and **Spaces Dev Mode is part of [PRO](https://huggingface.co/pro)** so we are not using that either 😃 This morning I tried cleaning up `git lfs` files, but still another config error. I have now deployed the space as a docker container instead, let’s see if this solves the issue ☹ ---
**Author:** ![ggcristian](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/ggcristian/32/47208_2.png) [@ggcristian](https://discuss.huggingface.co/u/ggcristian)\ **Post date:** [February 13, 2026, 7:19am UTC](https://discuss.huggingface.co/t/hf-space-static-sdk-is-not-supported/173178/9 "2026-02-13T07:19:15Z")
Deploying it as a Docker container seems to have solved the problem 😃 ---
**Author:** ![system](https://us1.discourse-cdn.com/hellohellohello/original/2X/d/de4155eb4aa4108ecb32a1389d7cc37ae69f88b7.png) [@system](https://discuss.huggingface.co/u/system)\ **Post date:** [February 13, 2026, 7:20pm UTC](https://discuss.huggingface.co/t/hf-space-static-sdk-is-not-supported/173178/10 "2026-02-13T19:20:13Z")
This topic was automatically closed 12 hours after the last reply. New replies are no longer allowed.