Duplicate it, and the app becomes yours to change

One click is the whole difference

On any Space, the menu at the top right has Duplicate this Space. You choose an owner, a name, public or private, and hardware: free CPU is the default and stays the default unless you pick otherwise. A few seconds later there is a copy in your account, running your build, with no queue but yours.

This is the single most valuable thing on the Hub for someone who does not write much code, because it converts using a tool into owning a tool. Duplicating is also how you handle sensitive files: the code now runs in a container you control, and you can make it private so nobody else can reach it.

What you actually get

Usually three files.

• app.py: the whole program. For a Gradio Space this is typically a model load, a function, and a description of the interface. Under two hundred lines is normal.
• requirements.txt: the Python packages to install at build time.
• README.md: which is also the deployment configuration, because the YAML block at the top is read by the Hub:

---
title: Background Remover
sdk: gradio
sdk_version: 4.44.0
app_file: app.py
suggested_hardware: cpu-basic
---

Edit any file in the browser. Committing triggers a rebuild, and the Logs tab shows the build output and the running application’s output separately. When something goes wrong, the traceback is one click away in there. This is the habit that separates people who can fix a Space from people who delete it and try another.

The failure you will meet first

You duplicate a Space written two years ago. It builds, then dies with a TypeError about an unexpected keyword argument. Nothing you did is wrong. The sdk_version line was absent or loose, the build picked a newer Gradio, and an argument was renamed between major versions.

The fix is to pin: set sdk_version in the README to the version the original was written against, and pin the packages in requirements.txt that matter. It is the same lesson as pinning a model revision in lesson one, and for the same reason: anything unpinned changes under you eventually.

Hardware is a rental, so treat it like one

Settings lets you change hardware on a running Space. This is where people get a surprising bill, and the mechanism is worth stating plainly.

Free hardware sleeps. Paid hardware does not, by default. The 48-hour sleep that pauses idle free Spaces is a cost-control measure for the Hub, and it does not apply to a GPU you are renting. A rented GPU bills for wall-clock time from the moment it starts until you pause it or downgrade it, whether or not anyone uses the Space. Leaving one on over a weekend costs the same as using it hard for the weekend.

So: rent the GPU, do the work, and then either pause the Space or set it back to CPU basic. In Settings there is also a sleep timer for paid hardware: set it to something small, like fifteen minutes, the moment you upgrade. Do it before you start the job, not after, because after is when you forget.

Secrets and variables

Settings has a Variables and secrets section. Variables are visible to anyone; secrets are stored encrypted, handed to your code as environment variables, never shown on the page, and not carried over when somebody duplicates your Space: they are prompted for their own. Read them normally:

import os

token = os.environ["HF_TOKEN"]

What you must never do is put the key in app.py. A public Space’s files are public, permanently and to everyone, and the next lesson is about exactly what that costs.

When the free GPU you need is somewhere else

If what you want is a one-off render rather than a hosted app, renting is often the wrong shape. Kaggle notebooks give roughly thirty GPU-hours a week free with a verified phone number, which is a generous allocation and enough to fine-tune a small model. Colab’s free tier is smaller and can be interrupted. Both let you pull models and datasets straight from the Hub, so the skills transfer completely.

Do this now

Duplicate one Space you use. Change one visible string in app.py (a title, a label, a default value) commit, and watch the rebuild in the Logs tab. That loop is the whole of deploying software on this platform.