Drop a folder of Python files into a Git repo, point Hugging Face at it, and a minute or two later you have a public URL running your model for whoever clicks the link. That is the whole bargain of Hugging Face Spaces, and it explains why the platform quietly became the default demo layer for open machine learning.
Spaces started in 2021 as a hosting side project for Gradio apps. It now holds several hundred thousand of them: image generators, speech transcribers, OCR tools, retrieval-augmented chatbots, robotics visualisers, and a long tail of abandoned experiments. Plenty are genuinely useful. Plenty are broken. Knowing which is which, and how to build one that isn’t, is most of the skill.
What the free tier actually gives you
The free CPU tier is more generous than people assume: 2 vCPU, 16 GB of RAM, 50 GB of ephemeral disk, no credit card. That covers scikit-learn models, small ONNX inference, and anything CPU-bound that finishes in a few seconds.
The catch is sleep. A free Space with no traffic for 48 hours goes to sleep and wakes on the next request, so the first visitor after a quiet weekend waits through a container build. For a portfolio piece that’s acceptable. For anything with real users it isn’t.
The hardware menu above CPU
Paid GPU tiers bill by the hour and start around $0.40/hr for a 16 GB T4, climbing from there through A10G and A100 configurations. ZeroGPU is the more interesting option: instead of renting a whole card, a Space can request a slice of shared H200 capacity at runtime and burn through a daily quota instead.
- CPU basic — free, 2 vCPU and 16 GB RAM, sleeps after 48 hours idle.
- Nvidia T4 — roughly $0.40/hr for 16 GB of VRAM, the workhorse tier for diffusion demos and 7B-class models.
- A10G and A100 — from about $1.50/hr upward, for large vision-language models and anything memory-bandwidth hungry.
- ZeroGPU — shared H200 slices for PRO accounts, metered as quota rather than hourly rental.
- Persistent storage — a paid add-on mounted at /data. Without it, every file your app writes disappears on restart.
Gradio, Streamlit, or your own Dockerfile
The default SDK is Gradio, and the reason is speed. A working interface is often a dozen lines of Python wrapped around a predict function. If you want to see how far that stretches, wiring multi-step AI workflows in Gradio covers chaining components, queues, and shared state without leaving Python.
Streamlit is the other supported path, similar in shape but more dashboard-flavoured. There’s also a static HTML SDK for apps that need no backend at all.
Then there’s Docker, which is where Spaces stop being a toy. You supply the Dockerfile, choose the base image, pin the CUDA version, install whatever system libraries you need. It’s also where people lose an afternoon, usually to the same mistake: the app has to listen on port 7860 or the health check never passes. Not 8000. Not 5000. 7860.
Why Spaces became the demo layer for open models
Open the model card for almost any noteworthy release and there’s a link to a live demo. That convention didn’t come from nowhere. A Space is versioned, reproducible, and publicly linkable, and it costs nothing to point a thousand strangers at it. No domain, no TLS certificate, no cluster.
The result is that a lot of momentum in open weights is now visible through these demo pages, which is part of what this survey of the open model landscape keeps running into. When a lab wants to prove a checkpoint is real rather than a leaderboard entry, the demo URL does more work than the benchmark table.
Diffusion tools are the clearest case study. The jump from a locally installed Stable Diffusion web UI to a hosted Space is mostly plumbing: a few sampling calls, a scheduler, and a lot of interface glue. Rebuilding AUTOMATIC1111 with a Gradio workflow shows how much of that stack is UI rather than inference.
The unglamorous parts nobody mentions
Secrets don’t travel when you duplicate
API keys and tokens go into the Space settings and arrive as environment variables. Duplicating someone’s Space copies the code, not their secrets. A freshly duplicated app with an external API dependency will crash on first boot until you add your own key.
Storage doesn’t survive a restart by default
Ephemeral disk means a SQLite file, a user upload, or a downloaded checkpoint can vanish between sessions. The failure mode is worse than it sounds because it’s silent: the upload appears to work, and the file is simply gone an hour later.
Cold starts are model downloads
A Space that pulls 7 GB of weights from the Hub on every restart feels broken to visitors. Bake the weights into the image, cache them to persistent storage on first run, or pick a smaller checkpoint.
Sorting good Spaces from dead ones
Search is noisy, so a couple of filters save time. Look for a runtime error banner at the top of the page. Check the last commit date, since a Space untouched since 2023 may still boot while its upstream API has moved on. Read the README, because the good ones explain what the model is bad at.
Duplicating is the underrated move. One click copies the whole repo into your account, where Dev Mode gives you a browser editor with a terminal and a file tree. For quick edits and dependency conflicts, it beats cloning locally.
Worth knowing too: every Gradio Space exposes a callable API. Point the gradio_client package at a Space URL and you can call its functions like local ones, which turns somebody else’s demo into a building block for your own pipeline.
When hosting it yourself makes more sense
Spaces are excellent for demos and awkward for products. There’s no uptime guarantee, billing is hourly whether anyone visits or not, and a Space seeing steady 24/7 traffic is usually cheaper on a rented GPU instance you control.
Anything that needs to touch local files, orchestrate tools, or run several models in conversation is often happier on your own hardware, which is roughly the argument behind running agentic and multimodal stacks locally. Before upgrading a Space to a bigger GPU, though, profile the thing. A surprising share of “we need an A100” problems turn out to be reloading weights on every request, and a short session with torch.profiler will show you that in about ten minutes.
Shipping a Space that still works in six months
Pin your dependencies. A requirements.txt full of unpinned packages is a countdown timer, since both transformers and gradio break APIs between minor versions. A Space that worked in March can be a red error page by August. Pin exact versions and bump them deliberately.
Keep the repo lean. Weights belong in model repos on the Hub, not committed alongside your app. Fifty MB of git history is fine. Five GB makes every rebuild painful and every visitor wait longer.
Treat the README as the landing page. Spaces render the same YAML front matter as model cards, so the title, emoji, and short description show up in search results and social previews. Five minutes there separates a demo people try from one they scroll past.
Test on the free tier before you pay for anything. If a CPU Space serves your model in under ten seconds, you may not need the GPU at all, and it’s much nicer to learn that before three weeks of billing.
Then keep the logs open during launch. The first hundred visitors will find the edge cases you didn’t: an empty upload, an emoji in the prompt, a request that times out the queue. Watch them fail, fix them, and the Space earns its place next to the model card.