While workarounds on the user side may be possible in some cases, the actual cause might still be unknown. A bug?
When “Persistent storage” is not shown in a Space’s Settings (no storage tier selector at all), the usual meaning is: the Hub UI does not think that Space is currently eligible to attach paid storage under the account context you are viewing. This is almost never caused by your app code.
Background that explains the symptom
A Space has “runtime disk,” and by default it is 50 GB and not persistent. Anything written there can vanish on restart or stop. (Hugging Face)
Persistent storage is a paid add-on that is mounted at /data and survives restarts. Hugging Face’s docs say you normally enable it from the Space Settings by choosing a storage tier. (Hugging Face)
So if the storage selector is missing, the issue is usually one of: billing scope, permissions, region availability, or billing state/UI bug.
Causes and fixes
Cause 1: Billing was added to the wrong scope (personal vs organization)
Compute billing can be tracked from the billing dashboard in your user’s or organization’s settings menu. (Hugging Face)
Organizations specifically allow admins to manage the org’s payment method and billing info and to set roles. (Hugging Face)
What this looks like
- You add a credit card under your user account.
- The Space is owned by an organization.
- The org has no valid payment method set, so the Space upgrade UI stays hidden.
Fix
- Switch to the organization context in settings (HF explicitly mentions a context switcher for this). (Hugging Face)
- Ensure the organization billing settings have a valid credit card (compute services only support credit cards). (Hugging Face)
- Reload the Space Settings page and check again.
Cause 2: You lack permission to purchase upgrades in that org
Even if you can push code, org roles can restrict who can manage paid settings. HF’s org docs explicitly tie roles and billing management to admins. (Hugging Face)
Fix
- Have an org admin open the Space Settings and check whether they can see storage tiers.
- If the admin can see it but you cannot, it is a permissions/UI gating issue. The admin must attach storage or adjust your role.
Cause 3: Storage Regions block the feature in your selected region
If your org uses Storage Regions, Hugging Face warns that “some features may not be available in all regions,” explicitly including persistent storage associated to a Space. (Hugging Face)
What this looks like
- Everything billing-related is correct.
- The UI still never shows persistent storage options for Spaces in that region.
Fix
- Check which region the Space uses.
- If you can, try a Space in a different region where the feature is available.
- If you cannot change region, you usually need HF support to confirm availability for your org’s region.
Cause 4: Payment method is “saved” but the upgrade system does not recognize it (stuck billing state)
There are reports where the UI says a payment method was saved, but upgrades still insist “add a payment method,” and the card is not usable in billing settings. (Hugging Face Forums)
In that state, the storage selector may remain hidden.
Fix
- Re-add the card in the correct scope (org vs user).
- Ensure the card supports 3D Secure and recurring online payments; HF calls this out for declined cards, and also notes some issuer/country constraints. (Hugging Face)
- If it remains stuck, you likely need HF billing support to reset/reattach billing state.
Cause 5: UI bug or feature flag mismatch (backend supports it, UI does not)
Sometimes the Settings UI fails to show the control even though the backend can attach storage. In these cases, the most reliable workaround is to call the backend API directly.
Hugging Face documents managing Space storage via huggingface_hub, including requesting and deleting storage. (Hugging Face)
Solutions and workarounds you can use immediately
Workaround A: Attach persistent storage via API (bypasses the UI)
This is the same action the UI would normally perform:
# pip install -U huggingface_hub
from huggingface_hub import HfApi, SpaceStorage
api = HfApi(token="hf_...") # needs permission on OWNER/SPACE
api.request_space_storage(repo_id="OWNER/SPACE_NAME", storage=SpaceStorage.SMALL)
Hugging Face documents request_space_storage(...) and also delete_space_storage(...). (Hugging Face)
Important constraints:
- You cannot downgrade storage tier. To go smaller, you must delete storage first (data loss). (Hugging Face)
- Deleting storage loses data permanently. (Hugging Face)
Workaround B: Use a dataset repo as your persistent datastore
HF explicitly recommends this as an alternative when you need persistence beyond ephemeral disk. (Hugging Face)
This avoids the whole persistent-storage UI path and is often better for logs, artifacts, and user uploads you want to version.
Workaround C: Make persistent storage actually useful by moving caches to /data
Once storage is attached, /data persists. HF recommends setting:
HF_HOME=/data/.huggingface
so model and dataset downloads are cached on the persistent volume and do not re-download after restarts. (Hugging Face)
Quick verification checklist (to confirm it’s truly fixed)
- Write a test file to
/data/test.txt.
- Restart the Space.
- Confirm
/data/test.txt still exists. Persistent storage is mounted at /data and persists across restarts. (Hugging Face)
Billing gotcha: persistent storage is billed until deleted, even if the Space is not running. (Hugging Face)
Summary
- Missing persistent storage UI usually means billing scope mismatch, org permissions, region limits, or a billing-state/UI bug. (Hugging Face)
- Fastest workaround is the API call
request_space_storage, which bypasses the UI. (Hugging Face)
- Alternative persistence: dataset repo. (Hugging Face)
- After it works, move caches to
/data via HF_HOME and remember storage is billed until deleted. (Hugging Face)