Secrets — API keys, database passwords, SSH private keys, tokens — must never be stored in anDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/trycua/cua/llms.txt
Use this file to discover all available pages before exploring further.
Image spec or committed to source control. The correct approach is to read them from the host environment at runtime and inject them into the sandbox only when needed. This page explains the injection patterns, what to avoid, and best practices for both cloud and local workflows.
The golden rule
Inject secrets at runtime via shell
Read credentials from the host environment withos.environ, then pass them into the sandbox using sb.shell.run. The sandbox’s shell session holds the values only for as long as the sandbox is running — they are not written to disk or stored in any persistent spec.
Each
sb.shell.run call is a fresh shell invocation. Environment variables set with export in one call are not available in the next call. Use a multi-command script (below) when you need them to persist across commands.Multi-command script with persistent env vars
Combine all commands into a single shell script so the exported variables remain in scope for every step:Non-sensitive config with Image.env()
UseImage.env() only for values that are safe to store in plaintext — log levels, feature flags, port numbers, environment names. Never use it for credentials.
Copy secret files into the sandbox at runtime
SSH private keys, TLS certificates, and similar secret files should be copied into the sandbox after it starts, not baked in withImage.copy(). Read the file contents on the host, write them inside the sandbox with appropriate permissions.
Using a .env file locally
For local development, keep secrets in a.env file (never committed to version control) and load them with python-dotenv before starting any sandboxes.
.env to .gitignore immediately:
Cloud vs local secret management
- Cloud (cua.ai)
- Local
When running cloud sandboxes, store secrets in your CI/CD provider’s secret store (GitHub Actions secrets, GitLab CI variables, etc.) or a secrets manager (AWS Secrets Manager, HashiCorp Vault). Pull them into your runner’s environment and inject at runtime.
Best practices summary
| ✅ Do | ❌ Don’t |
|---|---|
Read secrets from host os.environ | Hardcode secrets in Python source |
Inject at runtime via sb.shell.run | Store secrets in Image.env() |
Use .env + python-dotenv locally | Commit .env files to version control |
| Use your CI/CD provider’s secret store | Pass secrets as command-line arguments |
| Set strict file permissions on key files | Log or print secret values |
Use Image.copy() only for non-secret files | Bake credentials into image layers |