Hugging Face Spaces Can Expose Variables—Store Keys as Secrets

Hugging Face Space variables are publicly viewable, so store API keys, access tokens and other credentials as Space secrets, not in variables or repository files. Secrets supply private configuration to the running app, while variables are suitable only for values whose disclosure is harmless.

A secure deployment also requires checking the repository and its history, replacing secrets after duplication, selecting appropriate hardware and configuring sleep or pause behavior. If a credential has already been committed, logged or saved as a public variable, remove it from the Space and rotate it at its provider.

1. Define what the repository may reveal

A Space is an application backed by a Git repository. Public Spaces expose their source and running app and can be cloned; protected Spaces keep source private while the app remains reachable through its embed URL or a configured custom domain; private Spaces restrict both source and app access to the owner and collaborators. The official Spaces overview also states that variables are public and copied to duplicates, whereas secrets are private, cannot be read back from Settings after being set and are not copied automatically.

Visibility is therefore not a substitute for secret management. Even a private repository may later gain collaborators or change visibility, so credentials should stay outside committed files. Before the first push, search the working tree for token prefixes, authorization headers, database connection strings and copied environment files.

If the project already has commits, inspect its history as well. Deleting a key in the newest revision does not erase it from older Git objects; this is the risk described in the explanation of how Git history retains exposed keys. Once a real credential enters repository history, treat removal and provider-side rotation as separate tasks.

2. Classify every configuration value

Use a variable for non-sensitive configuration such as a model repository identifier, a feature flag or a public service URL. Put billing credentials, database passwords, private tokens, signing material and third-party API keys in secrets. A practical test is simple: if publishing the value beside the source would create access, cost or impersonation risk, it is not a variable.

Add values in the Space Settings page and read them through the runtime environment instead of embedding them in Python, JavaScript, a Dockerfile, build arguments or the README. For non-static Spaces, Hugging Face exposes variables and secrets to the app as environment variables. Secret values should not be printed during startup, included in exception messages or returned by diagnostic endpoints.

Static Spaces are a special case: their variables and secrets are made available to client-side JavaScript. Anything delivered to a browser must be considered obtainable by the user, regardless of whether the settings field is labelled as a secret. A static frontend that needs a private credential should call a server-side component that holds and uses the credential instead of shipping it to the browser.

Name configuration entries by purpose, such as PAYMENT_API_KEY, without embedding the value in a filename or command. Keep a separate inventory of each secret’s owner, provider, permission scope and rotation procedure, but never copy the secret value into that inventory.

3. Treat a duplicate as a new security boundary

When a Space is duplicated, review inherited variables because public variables can carry source-specific endpoints, repository identifiers or operational settings into the copy. Secrets require deliberate reconfiguration, so the new deployment should receive credentials owned by its operator rather than values borrowed from the source Space.

Before starting the duplicate, confirm its owner, visibility, hardware and storage configuration. Then add each required secret and make the application fail clearly at startup when a required value is missing. A visible configuration error is safer than silently using a fallback account or an unintended public endpoint.

Use the duplication boundary to narrow permissions. A demonstration that only reads one private model does not need a broadly privileged token, and separate deployments should not share a credential merely for convenience. This makes one compromised or retired Space less likely to affect unrelated applications.

4. Constrain hardware before traffic arrives

Begin with the lowest hardware tier that can run the workload, then upgrade from measured need. Hardware changes are not immediate because the Space reloads, so distinguish the requested hardware from the currently active runtime before assuming an upgrade or downgrade has completed.

The Hub library management guide documents methods for adding secrets and variables, inspecting runtime state, requesting hardware, pausing and restarting a Space, and setting an inactivity timeout. It says upgraded hardware does not stop by default; a paused Space remains inactive until its owner restarts it, while a sleeping Space starts again when a visitor returns. The guide also notes that changing secrets or hardware restarts the app.

Set a sleep time when creating, duplicating or upgrading a paid Space. For a demo needed only during a presentation or test window, pause it when the window closes. Record the intended hardware and inactivity policy with the deployment configuration so that a later rebuild does not restore an open-ended compute commitment.

5. Complete the launch check and rotate exposed keys

Review the deployment from the perspective of someone who can access its public source and outputs. Exercise failure paths without printing complete environment objects, request headers or authorization data, and inspect both build and runtime logs for accidental disclosure.

1. Confirm that no credential appears in current files, commit history, the README, build arguments or logs.
2. Confirm that every variable is safe to disclose and suitable for future duplicates.
3. Confirm that every required secret exists in the destination Space and has only the permissions the app needs.
4. Confirm that repository visibility and application access match the intended audience.
5. Confirm that active hardware, the sleep timer and the pause plan match the budget.
6. Deploy, test authentication with limited privileges and inspect failure output for leaked values.

If a key was committed, printed publicly or stored as a variable, moving it into secrets does not invalidate the exposed copy. Revoke or refresh the old credential at its provider, create a replacement with narrower permissions where possible and update the Space secret. For Hugging Face credentials specifically, the User Access Token guidance recommends one token per application, fine-grained tokens for production and deletion or refresh when a token leaks.

Retest authentication after rotation and delete obsolete secret entries. The completed Space should expose only intentional public configuration, refuse to start without required private values and stop consuming upgraded compute according to its documented inactivity policy.

Also read:

• Hugging Face Spaces Leaked 11,557 Keys—Git History Is the Hidden Trap
• OpenAI–Hugging Face AI Breach: What Happened and How to Respond
• How Your Ecommerce Store can make More Money Without more Traffic