There seems to be a valid case where the Persistent Storage option doesn’t appear for Enterprise orgs…?
Otherwise, it’s likely a Hugging Face bug or browser malfunction, so contact Hugging Face via email.
You are not missing a hidden toggle.
Given Hugging Face’s own docs, the option to buy persistent storage should appear in your Space’s Settings. If it doesn’t, that is almost certainly a Hugging Face–side issue (account / org / region / feature flag), not something you can fix in code or by clicking around more. (Hugging Face)
Below is the concrete picture, from first principles.
1. Background: how storage in Spaces actually works
There are three different “storages” involved. Mixing them up is what usually causes confusion.
1.1. Runtime disk (what /tmp and /data sit on)
- Every Space gets a runtime filesystem when it runs.
- On free CPU hardware that is 50 GB and ephemeral: when the Space restarts or is stopped, the contents are wiped. (Hugging Face)
- By default, everything under
/ (including /tmp) lives on that ephemeral disk.
Hugging Face’s own “Disk usage on Spaces” page states that this default disk is ephemeral and that if you need longer-term data you must either subscribe to persistent storage or use a dataset as a datastore. (Hugging Face)
So your observation:
/tmp → data gone on restart/data on free tier → also gone on restart
is exactly what the docs say should happen when you have no paid storage attached.
1.2. Persistent storage
Persistent storage is a separate paid volume that you attach to a Space.
Key properties from the docs:
-
You “upgrade your Space to have access to persistent disk space from the Settings tab.” (Hugging Face)
-
It is mounted into the container at /data. You read/write to it like a normal disk. (Hugging Face)
-
Tiers and pricing (per Space):
- Free tier: 50 GB, not persistent (this is the default runtime disk)
- Small: 20 GB, persistent, ≈ $5/month
- Medium: 150 GB, persistent
- Large: 1 TB, persistent (Hugging Face)
So under normal circumstances, once you buy “Small”, /data is on that paid volume and survives restarts. If you never buy it, /data is just another path on the ephemeral disk.
1.3. Hub repos and datasets (a separate persistence channel)
The same docs explicitly say that if you need data that outlives the Space itself you can also use a dataset repository as a data store. (Hugging Face)
That option is important for you, because it does not depend on the persistent-storage feature working.
2. What you should see in the UI
Multiple official docs and third-party guides assume the same user interface:
-
Open your Space in the browser.
-
Go to the Settings tab of that Space (not your global account settings).
-
Somewhere on that page, you see:
The JupyterLab-on-Spaces guide states this very plainly:
To set up persistent storage on the Space, you go to the Settings page of your Space and choose one of the options: small, medium and large. (Hugging Face)
The general “Disk usage on Spaces” doc also says:
You can upgrade your Space to have access to persistent disk space from the Settings tab. (Hugging Face)
And the Spaces Overview page shows storage tiers (Ephemeral, Small, Medium, Large) and tells you to click Settings and select your preferred hardware environment, including persistent storage. (Hugging Face)
So under normal conditions, after you have a card on file, the Storage card exists, and you pick a tier there.
In your case, that entire upgrade control is missing despite:
- You having a working Space.
- You understanding that
/data is ephemeral on free tier.
- You having added a payment method. (Hugging Face Forums)
That is not described in any public docs as expected behavior.
3. Why the upgrade option can be missing
There is no public page that says “persistent storage only exists for specific user plans” or “only for certain Spaces.” Instead, the docs treat it as a normal paid add-on you can always choose in Settings or via API. (Hugging Face)
Given that, your situation almost certainly comes from how your Space or account is configured on Hugging Face’s side, not from anything you did.
3.1. Region / advanced-compute constraints (especially orgs)
For Enterprise orgs, Hugging Face supports storage regions (US, EU, etc.) and explicitly says that:
Available hardware configurations vary by region, and some features may not be available in all regions, like persistent storage associated to a Space. (Hugging Face)
If your Space is:
- Under an organization that uses a non-default region, or
- Under some internal “advanced compute” configuration,
then persistent storage may be disabled for that region, and the UI will simply not show it.
3.2. Owner vs organization billing
Billing for Spaces upgrades (hardware and storage) is tied to the owner account / organization, not to each individual contributor.
- The Spaces overview and “Manage your Space” docs both say upgraded hardware and storage are requestable when you have a payment method and use
space_storage="small" or request_space_storage. (Hugging Face)
- Those API calls are sent on behalf of whichever account or org owns the Space.
If:
- The Space is under an org,
- You added a card only to your personal billing settings, and
- The org has no payment method registered,
it is plausible that the UI hides storage upgrades for that Space because the owner (the org) has no valid billing setup, even though you personally do.
There is no explicit doc line confirming “we hide the storage card when billing is missing,” but this pattern is consistent with how hardware upgrades require card or grant on the owner. (Hugging Face)
3.3. Feature flag or UI bug
HF clearly runs a lot of things via backend flags:
- For example, the Hub docs mention features “not currently exposed to end users” that HF can toggle if you email
[email protected]. (Hugging Face)
- Persistent storage itself is configurable via API (
request_space_storage) with a SpaceStorage enum (small/medium/large). (Hugging Face)
If your account or Space did not get the correct flag, the Settings UI will not render the storage selector even though the docs assume it exists. That matches exactly what you see.
Community answers on other persistent-storage problems often end with “contact HF support ([email protected], [email protected]) for paid storage issues,” which is another hint that some parts of this system are not self-service. (Hugging Face Forums)
4. Concrete checks you can do yourself
These checks will not fix a backend bug, but they help narrow down the cause before you email support.
4.1. Confirm you’re in the Space Settings, not only account settings
From the docs’ perspective, the flow is:
-
Open the Space page (e.g., https://huggingface.co/spaces/you/your-space).
-
Click the Settings tab on that Space, next to “App / Files / Community”.
-
Scroll; there should be:
- Hardware section.
- Storage section with “Ephemeral / Small / Medium / Large” or a “Persistent storage” card. (Hugging Face)
You already looked, but it is important: if the entire storage card is missing, that’s the problem. Not a “wrong place” issue.
4.2. Check whether the Space is owned by you or by an org
On the Space page, look at the identifier:
your-username/space-name → personal Space.org-name/space-name → organization-owned Space.
If it is under an organization:
- Ask an org admin to open that Space’s Settings and see whether they see a storage section.
- Confirm whether the org has a payment method in its own billing settings. (Hugging Face)
If the org has no billing configured, that increases the odds that upgrades are hidden.
4.3. Create a tiny test Space under your personal account
Create a bare-bones Gradio Space under your personal user (not the org), then:
- During creation, some templates show a storage selector (Ephemeral vs persistent) as part of the “Create Space” dialog. (Label Studio)
- After creation, open its Settings and check if a Storage section appears.
Outcomes:
- If the test Space does show storage options but your MSc Space does not, the problem is specific to that existing repo (a broken flag or older configuration).
- If neither Space shows storage options, this is more likely account-level (or region-level) gating.
4.4. Optional: try the Python API from outside Spaces
If you are comfortable with Python, you can directly call the public API to request storage and see what error you get:
from huggingface_hub import HfApi, SpaceStorage
api = HfApi(token="hf_...") # use a user token with write access
repo_id = "OWNER/SPACE_NAME" # e.g. "littlewoko/my-msc-space"
api.request_space_storage(repo_id=repo_id, storage=SpaceStorage.SMALL)
This is the documented way to add persistent storage programmatically. (Hugging Face)
- If this returns something like “feature not available” or
403, that suggests a permission / plan / region gate.
- If it
200s but the UI still shows no storage card, that suggests a pure UI bug.
Either way, the response is something you can attach to your support message.
5. How to get it fixed: contacting Hugging Face
For anything involving paid features, the official path is via Hugging Face support:
When you email them, include:
-
A link to the affected Space.
-
A screenshot of that Space’s Settings tab, showing that there is no Storage / persistent storage section.
-
A short description:
- You understand
/data is ephemeral on free tier.
- You have a card configured in billing settings.
- You cannot see any way to request Small / Medium / Large persistent storage, contrary to the docs. (Hugging Face)
-
Optionally: the status code and message from request_space_storage if you tried the API.
From public documentation, there is no setting you can change to “un-hide” this; HF staff need to check the Space’s region, owner, and internal flags.
6. What to do for your MSc experiments right now
You want to start experiments this week. You do not need to wait for HF to fix persistent storage to get reliable logging.
The safe design is:
Treat the Space as stateless compute and UI.
Treat persistence as remote: a dataset repo or external DB.
6.1. Using a Hub dataset as your “database”
The storage docs explicitly recommend using a dataset repository as a durable store when you need data that outlives the Space. (Hugging Face)
Pattern:
- Create a dataset repo, for example
your-username/msc-session-logs.
- Create an HF token with write access.
- In the Space, set that token as a secret (Settings → Secrets). (Hugging Face)
- When a user finishes a session, append a JSON or CSV record to the dataset via
huggingface_hub.
Very simple example:
import json, uuid, datetime as dt
from huggingface_hub import HfApi
DATASET_ID = "your-username/msc-session-logs" # dataset repo
api = HfApi(token=os.environ["HF_TOKEN"]) # set HF_TOKEN as a Space secret
def log_session(data: dict):
session_id = str(uuid.uuid4())
ts = dt.datetime.utcnow().isoformat()
path_in_repo = f"logs/{ts}_{session_id}.json"
api.upload_file(
repo_id=DATASET_ID,
repo_type="dataset",
path_in_repo=path_in_repo,
path_or_fileobj=json.dumps(data).encode("utf-8"),
)
This gives you:
- One JSON file per session under
logs/, persisted on the Hub.
- Data independent of the Space’s runtime disk.
- Easy offline analysis: you can clone the dataset and run your MSc analysis locally.
This is exactly the type of pattern the docs suggest in their “Dataset storage” section. (Hugging Face)
6.2. External database (if you prefer “classic” infra)
You can also use a managed DB (Postgres, Supabase, Firebase, etc.) and send logs from the Space over HTTPS. This is the same pattern many teams follow when using Spaces as a front end and keeping state in their own infra. (Hugging Face)
Tradeoffs:
- More moving parts and credentials.
- More control and potentially easier integration with university data systems.
6.3. Where persistent storage fits if/when it works
If HF later fixes your persistent storage UI:
- Use
/data mainly for caches and local working files (e.g. HF_HOME=/data/.huggingface so models and datasets do not re-download every time). (Hugging Face)
- Keep the authoritative research data (logs, labels, outputs used in the thesis) in a dataset or DB, which is easier to clone, back up, and reference in your write-up. (Hugging Face)
That way, your experiment does not depend on the fate of a single Space’s attached disk.
7. Summarised next steps
- You are not doing anything wrong. Docs say the persistent storage selector should appear in your Space’s Settings; if it is missing, that is inconsistent with the documented behavior. (Hugging Face)
- Check basics: Confirm the Space owner (you vs org), verify billing for that owner, and test with a fresh personal Space. This distinguishes account-level, org-level, and repo-level issues. (Hugging Face)
- Optionally probe via API: Call
request_space_storage with SpaceStorage.SMALL and see whether you get “not allowed” vs success; include that in your support message. (Hugging Face)
- Escalate to Hugging Face: Email
[email protected] (and if you like, [email protected]) with Space link, screenshots, and a short description that the persistent storage UI is missing despite the docs. (Hugging Face)
- For your MSc this week: Implement logging to a Hub dataset or external DB now, and treat persistent storage as an optional future optimization for speed/caching rather than the primary data store. (Hugging Face)
This keeps your experiment robust and unblocked, regardless of how quickly HF resolves the missing upgrade option.