In plain English
You wrote a small AI app on your laptop. It runs when you type python app.py, a browser tab opens, and you can chat with it or upload an image. Then a friend asks, can I try it? Now you have a problem: the app only lives on your machine, only runs while your laptop is on, and "just send me the code" means they have to install Python and your dependencies before anything works.

Hugging Face Spaces solves exactly that. A Space is a free home on the internet for one small AI app. You put your app's files in a Space repository, Hugging Face builds and runs the app for you, and you get back a public web address like huggingface.co/spaces/yourname/your-app. Anyone with the link opens it in a browser and uses your app. No install, no server to rent, no DevOps.
The everyday analogy: writing the app is like cooking a great dish in your own kitchen. A Space is the little food stall on a busy street where you set that dish out so passers-by can taste it. You still made the food; the stall just gives it an address and keeps it warm so strangers can walk up and try it without being invited into your kitchen.
Why it matters
For a beginner, the gap between "it works on my laptop" and "a stranger can use it" is where most projects quietly die. Spaces removes the boring, intimidating part of that gap so you can focus on the app itself.
- A real, shareable URL. Your demo gets a stable link you can drop into a message, a portfolio, a job application, or a README. That single link is often more convincing than a paragraph describing what you built.
- No servers to manage. You never touch Linux, NGINX, SSL certificates, or a cloud console. Hugging Face provisions the machine, installs your dependencies, and keeps the app online. Updating the app is just pushing new files.
- Free to start. Every Space gets a free CPU tier — enough for an LLM-API chatbot, a text tool, or a light demo. If you later need a GPU to run an open model locally inside the Space, you can attach one as a paid upgrade, but you don't need it to begin.
- Built for AI demos. Spaces is made by the same company as the model hub, so loading a model, reading a dataset, or wrapping a model in a UI is the path of least resistance, not a fight.
Who should care? Anyone learning to build with AI. It is the natural finishing move for almost every starter project — your first chatbot, a chat-with-your-PDF app, a semantic search demo — turning "I built this" into "here, click and try it."
How it works
A Space is, underneath, a Git repository with one special file that tells Hugging Face how to run it. When you push changes, the platform reads that file, builds the app, and starts it. That is the whole loop.
The three ways to build a Space
When you create a Space you pick a SDK — the framework your app uses. This decides how Hugging Face builds and serves it.
| SDK | What you write | Best for |
|---|---|---|
| Gradio | A Python function wrapped in a Gradio Interface | ML demos — text, image, audio in/out, fastest to ship |
| Streamlit | A Python script that renders a data-style web app | Dashboards and multi-widget apps with more layout control |
| Docker | Your own Dockerfile defining the whole environment | Full control — any language, custom server, FastAPI, etc. |
| Static | Plain HTML / CSS / JS files | A frontend with no Python backend |
For a first project, Gradio is the usual choice: it turns a single Python function into a working web UI in a few lines, and it is maintained by Hugging Face itself, so it drops straight into a Space.
The config that makes it a Space
Every Space repo has a README.md that begins with a small YAML front-matter block. Those few lines — not a complicated config file — are what tell the platform which SDK to use and which file to run.
---
title: My First AI App
emoji: 🤗
colorFrom: indigo
colorTo: pink
sdk: gradio
app_file: app.py
pinned: false
---
# My First AI App
A tiny demo. Type something and see what it does.Alongside that README you put your code (app.py) and a requirements.txt listing the Python packages you need. Hugging Face installs those packages, runs app.py, and exposes the Gradio UI at your Space's URL. The diagram below is the full journey from your files to a live link.
Once it's live, the app runs on a hosted machine called the runtime. On the free CPU tier the Space "sleeps" after a stretch of no visitors and wakes up — taking a few seconds to restart — when someone next opens the link. That is normal for free hosting, not a bug.
A first Space, in practice
Here is the complete app behind a minimal Gradio Space. It calls a model through an API and returns the reply. Three files — this app.py, a one-line requirements.txt, and the README above — are an entire deployable AI app.
import os
import gradio as gr
from anthropic import Anthropic
# The API key is NOT in the code. It is read from a Space secret
# you set in Settings -> Variables and secrets.
client = Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])
def reply(message, history):
msg = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=500,
messages=[{"role": "user", "content": message}],
)
return msg.content[0].text
# gr.ChatInterface turns the function above into a full chat UI.
demo = gr.ChatInterface(reply, title="My First AI App")
if __name__ == "__main__":
demo.launch()gradio
anthropicYou create the Space on the website (choosing the Gradio SDK), then either drag these files into the web uploader or git push them to the Space's repo. Hugging Face builds it and, a minute or two later, your chat app is live at a public URL.
Spaces vs. running it yourself
Spaces is not the only way to put an app online, but for an AI demo it removes the most steps. Here is how it compares to the other common options a beginner runs into.
- Free CPU tier, optional GPU
- Built for ML demos
- Push a repo, get a URL
- No server setup at all
- Sleeps when idle (free tier)
- You rent and pay hourly
- Total control, total work
- Install OS, Python, web server
- Manage SSL, ports, updates
- Stays up only while you pay
- Free, instant, private
- Nobody else can reach it
- Dies when you close the lid
- No public URL to share
- Fine for building, not sharing
The honest summary: build and debug on your laptop, then publish to a Space the moment you want someone else to try it. Reach for a full cloud VM only when you outgrow a single small app — when you need a custom backend, a database, heavy always-on traffic, or fine-grained control that the managed Space doesn't give you.
Common pitfalls
Most first-Space problems are small and predictable. Knowing them up front saves an afternoon of confusion.
- Wrong
app_fileor SDK. If the README front-matter sayssdk: gradiobut your file is namedmain.py, the build can't find your app. Matchapp_fileto the real filename. - Missing dependency. It ran on your laptop because the package was already installed there. The Space starts clean, so every import must appear in
requirements.txtor the build fails with aModuleNotFoundError. - Hardcoded secrets. Covered above, but it is the number-one beginner mistake: a key in the code is public the instant you push. Use Space secrets.
- Expecting instant, always-on response. On the free tier the Space sleeps when idle and takes a few seconds to wake. If you need it warm 24/7 or faster hardware, that is what the paid tiers and GPU upgrades are for.
- Reading the wrong logs. When a Space won't start, the Logs tab (build logs and runtime logs) tells you exactly why. Read it before guessing — the error is almost always spelled out there.
Going deeper
Once the basic loop clicks — push files, get a URL — a few more capabilities are worth knowing as your projects grow.
Hardware tiers. The free tier is CPU-only, which is plenty for apps that call a model through an API. If you want to run an open-weight model inside the Space (loading the weights yourself), you'll need an attached GPU, available as a paid upgrade. The rule of thumb: calling someone else's hosted model stays cheap; running the model yourself needs hardware.
Visibility and persistence. A Space can be public or private. Note that the free runtime's local disk is ephemeral — files your app writes can vanish when the Space restarts or sleeps. For data that must survive, write to an external store or a dataset repo rather than a local file. Persistent storage is a paid add-on.
Secrets, variables, and the Hub. Beyond hiding API keys, Space secrets let your app authenticate to the Hugging Face Hub to pull a private model or push results to a dataset. This is what turns a static demo into something that reads and writes real artifacts — the Space becomes a small node in a larger pipeline, not just a toy page.
Where to go next. The natural progression is: get any app live, then make it do something real. Wrap one of the starter builds — a chatbot, a chat-with-PDF tool, or a writing assistant — in Gradio and publish it. The deployment step stays the same no matter how clever the app gets, which is exactly the point: Spaces makes shipping the easy part so you can spend your effort on the idea.
FAQ
What is a Hugging Face Space?
A Space is a free, hosted home for a single AI web app. You push your app's files (code, a requirements.txt, and a README with a small config header) to a Space repository, and Hugging Face builds and runs the app, giving you a public URL anyone can open in a browser. It is different from a model or dataset repo, which hold files to download rather than a running app.
Is Hugging Face Spaces free?
Yes, every Space includes a free CPU tier, which is enough for chatbots that call a model through an API and most light demos. You only pay if you upgrade to a GPU (to run open models inside the Space) or want persistent storage and an always-on, non-sleeping runtime.
How do I deploy a Gradio app to Spaces?
Create a new Space and choose the Gradio SDK, then add three things: your app.py with a Gradio interface, a requirements.txt listing your packages, and a README whose front-matter sets sdk: gradio and app_file: app.py. Upload them through the website or git push to the Space repo, and Hugging Face builds and serves it automatically.
What's the difference between Gradio, Streamlit, and Docker Spaces?
They are the build options you choose when creating a Space. Gradio wraps a Python function in a UI and is the fastest path for ML demos; Streamlit is better for dashboard-style multi-widget apps; Docker uses your own Dockerfile for full control over the environment, any language, or a custom backend like FastAPI.
Why does my Space go to sleep?
On the free CPU tier, a Space pauses after a period with no visitors to save resources, then wakes up — taking a few seconds to restart — the next time someone opens the link. This is normal behavior, not an error. Paid hardware tiers can keep a Space always on.
How do I keep my API key safe in a Space?
Never put the key in your code, because a Space repo is public by default and a committed key is leaked instantly. Instead add it under Settings, in Variables and secrets, then read it in your app with os.environ["YOUR_KEY_NAME"].