Skip to main content
Most AI applications need credentials to call external services — Hugging Face tokens for gated models, database URLs, third-party API keys, or private Docker registry credentials. Secrets let you store these values securely on fal instead of hardcoding them in your code or committing them to version control. Once set, secrets are encrypted and their values are never displayed again. Secrets are injected into your runners as environment variables when they start. You access them via os.getenv() just like any other environment variable. Secrets can be scoped to specific environments (e.g., different API keys for staging vs production) and are separate from the platform environment variables that fal injects automatically.

Setting Secrets

You can set secrets from the Dashboard, the CLI, or the Python SDK.

Dashboard

Navigate to Dashboard > Secrets to create, edit, and delete secrets. Select the environment (e.g., main, staging) from the dropdown, then add your key-value pairs. Values are encrypted and never displayed after creation.

CLI

You can set multiple secrets in a single command. To target a specific environment, use the --env flag:

Python SDK

Accessing Secrets at Runtime

Secrets are available as standard environment variables inside your app. Use os.getenv() to read them in setup(), endpoint handlers, or anywhere else in your runner code.
Secrets are injected when a runner starts. If you update a secret, running runners keep the old value. Only new runners (from a new deploy or scale-up) pick up the updated value. To force all runners to use the new value, redeploy your app with fal deploy.

Secrets During Build

For security, secrets are not available as environment variables during the image build stage. The built image is cached and may be shared across environments, so injecting secrets into the build would risk leaking them. Instead, use the ${} substitution syntax in your requirements list. fal replaces ${SECRET_NAME} with the secret value at build time without exposing it in the cached image.
This is the only way to use secrets during dependency installation. The substitution happens server-side before pip runs, and the token is not stored in the final image.

Docker Build Secrets

If you use a custom container image, you can pass build-time secrets via the secrets parameter on ContainerImage. These are mounted as Docker build secrets (via --mount=type=secret) and are available inside your Dockerfile during the build but not persisted in the final image.

Secrets Per Environment

Secrets can be scoped to specific environments, letting you use different credentials for development, staging, and production. When you deploy to an environment, the runner receives the secrets set for that environment.
If a secret is not set for a specific environment, the runner does not fall back to the main environment’s value — the variable is simply not present.

Managing Secrets

Listing

List your secrets to see their names, environments, and creation dates. Values are never displayed.
To list secrets for a specific environment:

Removing

Delete a secret to prevent it from being injected into new runners:
Running runners are not affected by deletion. The secret is removed from new runners only.