AI/TLDR

What Are Hugging Face Spaces? Free AI App Hosting

You will understand what Hugging Face Spaces are, how they host Gradio/Streamlit/Docker apps for free, and how to share your first AI demo.

BEGINNER10 MIN READUPDATED 2026-06-14

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 — illustration
Hugging Face Spaces — cdn-codaio.imgix.net

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.

SDKWhat you writeBest for
GradioA Python function wrapped in a Gradio InterfaceML demos — text, image, audio in/out, fastest to ship
StreamlitA Python script that renders a data-style web appDashboards and multi-widget apps with more layout control
DockerYour own Dockerfile defining the whole environmentFull control — any language, custom server, FastAPI, etc.
StaticPlain HTML / CSS / JS filesA 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.

README.md (the front-matter header)yaml
---
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.

app.pypython
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()
requirements.txttext
gradio
anthropic

You 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.

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_file or SDK. If the README front-matter says sdk: gradio but your file is named main.py, the build can't find your app. Match app_file to 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.txt or the build fails with a ModuleNotFoundError.
  • 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"].

Further reading