Deploy and maintain ML applications on Hugging Face Spaces

A skill for building, deploying, and maintaining Hugging Face Spaces applications - Gradio, Docker, or Static SDKs, ZeroGPU and dedicated hardware, model loading, debugging, secrets, inference providers, and community grants. Setup checks the hf CLI is installed and the user is logged in via hf auth whoami, noting the canPay/isPro flags that gate hardware choices, and recommends installing the companion hf-cli skill. A Space is a git repo using one of three SDKs: Gradio (Python, fast iteration, ZeroGPU support), Docker (arbitrary container for non-Python stacks or pre-built templates like Streamlit/Argilla/Shiny, no ZeroGPU), or Static (plain HTML or a built React/Svelte/Vue project for in-browser ML via transformers.js/WebGPU/WASM, no hardware needed). Hardware tiers: cpu-basic (2 vCPU/16GB, free) and ZeroGPU/zero-a10g (dynamic per-request GPU on NVIDIA RTX PRO 6000 Blackwell, large=48GB/1x quota or xlarge=96GB/2x quota, free for the creator but visitor-quota-limited at ~5min free/40min Pro/60min Enterprise, Gradio-only and PyTorch-first, requires a PRO/Team/Enterprise plan) are both free; dedicated GPUs (T4, L4, A10G, L40S, A100, H200) are billed hourly to the creator and only available if canPay=True. A non-PRO user wanting ZeroGPU can still build on cpu-basic, code for ZeroGPU, then request a community grant. Before building, search for prior art with hf spaces search and read an existing similar Space's app.py/requirements.txt to avoid blind iteration. SDK/hardware defaults absent an explicit user request: Gradio+ZeroGPU for a public ML demo; dedicated GPU only when the model's sole inference path is genuinely non-PyTorch with heavy init (marginal non-torch tools inside a torch-main pipeline are fine on ZeroGPU, initialized inside @spaces.GPU); cpu-basic for tiny/CPU-bound models or API-proxy Spaces; Static for browser-side ML or project pages; Docker for non-Python containers. When sourcing a model from GitHub, estimate VRAM as bf16 ~= params_B x 2 GB (48GB fits <=24B params at bf16, more with quantization); if a model genuinely won't fit, Inference Providers can avoid hosting it entirely. Creating a Space uses hf repos create <namespace>/<name> --type space --space-sdk <gradio|docker|static> with --flavor selecting hardware (zero-a10g for ZeroGPU, omitted for cpu-basic), --secrets KEY=val for values hidden from visitors (API keys, gated-repo HF_TOKEN), --env KEY=val for visible non-sensitive config, and visibility flags --public/--private/--protected (protected keeps the app reachable but the repo/Files tab private) - critically, the README YAML's hardware: field is silently ignored; hardware is set only via --flavor at creation or hf spaces settings <id> --hardware <name> afterward. Building the app requires specific required README frontmatter fields.

Use it whenever the user asks to create or host an app on Hugging Face, port code onto Spaces, choose between Gradio/Docker/Static SDKs, pick hardware (free vs. ZeroGPU vs. dedicated GPU), or debug an existing Space.

Given a model or app to host, it produces the SDK and hardware choice, the hf repos create command with correct flavor/secrets/env/visibility flags, and the README frontmatter plus app code needed to make the Space functional.

hf repos create <namespace>/<name> --type space --space-sdk gradio --flavor zero-a10g

Uses the hf CLI (huggingface_hub) for Space creation, secrets, and hardware settings, pairs with the hf-cli companion skill, and can fall back to Inference Providers instead of self-hosting when a model won't fit available hardware.

Developers building and hosting ML demos or applications on Hugging Face Spaces who need to choose the right SDK and hardware tier (especially navigating ZeroGPU's PyTorch-only, Gradio-only, PRO-plan constraints), configure secrets correctly, and avoid the common README hardware: field trap that silently does nothing.