Managing secrets
Thesecrets commands take positional arguments:
telnyx-edge ship each function that uses it.
Reading secrets
As environment variables — every language
Each secret is injected into all functions in your organization as an environment variable named after its key. No declaration needed:- TypeScript / JavaScript
- Python
- Go
- Quarkus (Java)
Through the typed binding — TypeScript
TypeScript projects can additionally declare a[[secrets]] binding in func.toml and read the secret through env.SECRETS:
env.SECRETS.get accepts only the literal union of declared handles — a typo’d handle fails to compile — and the in-code handle is decoupled from the stored key name, so you can swap name in the manifest without touching code. The binding SDK is TypeScript-only today; other runtimes use the injected environment variables.
Enforced when [[secrets]] is declared: a binding named SECRETS and duplicate [[secrets]] handles are hard errors — ship fails. An [env_vars] entry named SECRETS only warns (it shadows the env.SECRETS namespace), so rename it. See Bindings for how the env namespace works.
Rotating a secret
add with an existing key overwrites its value:
Scoping and local development
Secrets are organization-scoped. There is no per-environment scoping (dev/staging/prod) today — if you need separation, encode it in the key name (DEV_DATABASE_PASSWORD, PROD_DATABASE_PASSWORD) and pick one in code.
There is no local secrets emulation in the CLI. When running a function locally, export the same names as ordinary environment variables:
Troubleshooting
Next Steps
- Environment variables — the full picture of what lands in your container’s environment
- Bindings — the declare →
types→envpattern all bindings share - Configuration —
[[secrets]]and every other manifest key