> ## Documentation Index > Fetch the complete documentation index at: https://developers.telnyx.com/llms.txt > Use this file to discover all available pages before exploring further. # Configuration > Every function is configured through one TOML manifest — func.toml or telnyx.toml. This is the complete reference: the identity block, environment variables, and every binding declaration, with links to the bindings documented in their own sections. Every Edge Compute project has a TOML manifest at its root. It is the one place a function is configured: it identifies what `telnyx-edge ship` deploys and declares the bindings the runtime resolves onto `env`. Everything below is a block in that file. There are two forms: * **`func.toml`** (classic) — a single function. Written by `telnyx-edge new-func`, which also registers the function server-side, so the UUID `func_id` is already filled in. Declares `[env_vars]`, `[telnyx]`, `[[secrets]]`, `[storage.kv.]`, `[storage.cloudstorage.]`, `[storage.sqldb.]`, and `[[ratelimits]]`. * **`telnyx.toml`** (umbrella) — a JavaScript or TypeScript project with a top-level `main` entry, bundled client-side on `ship`. Declares the same binding blocks plus `[[actors]]`, which classic projects cannot. `telnyx-edge types` reads either form and writes `telnyx-env.d.ts`, typing `env.` for each declaration. Configuration changes take effect on the next `telnyx-edge ship` — there is no live update; re-run `telnyx-edge types` after changing a supported binding declaration so `telnyx-env.d.ts` matches the manifest. The binding blocks — `[telnyx]`, `[[secrets]]`, `[storage.kv.]`, `[storage.cloudstorage.]`, `[storage.sqldb.]`, `[[actors]]` (umbrella only), and `[[ratelimits]]` — each resolve to a handle on `env`. This page documents their **manifest keys**; the [bindings catalogue](/docs/edge-compute/runtime/bindings#catalogue) lists every binding at a glance — declaration and `env` surface — and each block below links to its full documentation. ## func.toml `new-func` writes the minimal manifest — and because it registers the function server-side at scaffold time, the UUID `func_id` is already in it: ```toml theme={null} [edge_compute] func_id = "7819cf01-39a8-400e-9bce-3d792ffa4017" func_name = "demo-ts" # For environment variables and secrets: # Use telnyx-edge secrets add # Secrets are injected as environment variables into all your functions ``` A manifest using every available block: ```toml theme={null} [edge_compute] func_id = "7819cf01-39a8-400e-9bce-3d792ffa4017" # written by new-func — the function ship deploys func_name = "demo-ts" # → https://demo-ts-7819cf01-3.telnyxcompute.com (name + func_id prefix) [env_vars] # plain string env vars, injected on each deploy LOG_LEVEL = "info" MAX_RETRIES = "3" [telnyx] # pre-authenticated Telnyx API client binding = "MY_TELNYX" # → env.MY_TELNYX (TS); also injects TELNYX_API_KEY [[secrets]] # typed handle onto a stored secret binding = "STRIPE_KEY" # → env.SECRETS.get("STRIPE_KEY") name = "STRIPE_API_KEY" # the key stored with `secrets add` [storage.kv.MY_KV] # KV namespace binding — block key is the handle id = "550e8400-e29b-41d4-a716-446655440000" # → env.MY_KV [storage.cloudstorage.ASSETS] # Cloud Storage bucket binding — block key is the handle bucket_name = "my-assets" # → env.ASSETS; an existing bucket region = "us-east-1" # us-central-1 | us-east-1 | us-west-1 | eu-central-1 | ap-southeast-1 | ca-central-1 [storage.sqldb.DB] # SQL database binding — block key is the handle id = "550e8400-e29b-41d4-a716-446655440000" # → env.DB; the database UUID ``` There is no `language` key (the runtime comes from the project files the scaffold creates), no build block, and no timeout key — the request timeout is a platform property (default 30 s, maximum 60 s; see [Limits](/docs/edge-compute/platform/limits)). ### \[edge\_compute] — identity | Key | Value | | ----------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `func_id` | The function's UUID, written by `new-func` when it registers the function server-side. This — not the directory — is what `ship` deploys, so swapping `func.toml` files switches deploy targets (the [CI/CD staging pattern](/docs/edge-compute/deploy#staging-and-production) relies on this). | | `func_name` | The function name, and the first part of the invoke URL: `https://{func_name}-{func_id-prefix}.telnyxcompute.com` (the suffix is derived from `func_id`; `telnyx-edge ship` and `list` print the exact host). See [Routes & Domains](/docs/edge-compute/configuration/routing). | ### \[env\_vars] — environment variables Free-form key-value pairs injected as process environment variables on each deploy. All values are strings; changes take effect on the next `ship`; values are plaintext in git — put credentials in secrets instead. **Dive in: [Environment Variables](/docs/edge-compute/configuration/environment-variables).** ### \[\[secrets]] — secret bindings | Key | Value | | --------- | -------------------------------------------------------------------- | | `binding` | The handle your code passes to `env.SECRETS.get()`. | | `name` | The stored secret key, from `telnyx-edge secrets add `. | The binding is the typed TypeScript surface; independently of it, every secret is injected as an environment variable into all functions in your organization. **Dive in: [Secrets](/docs/edge-compute/configuration/secrets).** ### \[telnyx] — Telnyx API binding | Key | Value | | --------- | --------------------------------------------------------------------------------------------------------- | | `binding` | The property on `env` — `env.` is a pre-authenticated Telnyx SDK client in TypeScript functions. | Declaring the block also injects a `TELNYX_API_KEY` environment variable into the container — this is how non-TypeScript runtimes call the Telnyx API over plain REST. **Documented in [Telnyx API binding](/docs/edge-compute/telnyx-api).** ### \[storage.kv.\] — KV namespace binding | Key | Value | | ------------------ | -------------------------------------------------------------------------------------- | | block key `` | The handle — a name you choose. `env.` is a `KvNamespace` (get/put/delete/list). | | `id` | The KV namespace UUID, from `telnyx-edge storage kv create`. | Multiple blocks are allowed — each becomes its own `env` property. `telnyx-edge types` generates `KvNamespace` types for these blocks since CLI v0.2.4. **Documented in the [KV quick start](/docs/edge-compute/kv/quick-start).** ### \[storage.cloudstorage.\] — Cloud Storage bucket binding | Key | Value | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------- | | block key `` | The handle — a name you choose. `env.` is a `CloudStorageBucket` (get/put/head/delete/list). TypeScript-only, via `@telnyx/edge-runtime` ≥ 0.3.0. | | `bucket_name` | The name of an existing Cloud Storage bucket — the binding points at a bucket, it doesn't create one. | | `region` | The bucket's region: `us-central-1`, `us-east-1`, `us-west-1`, `eu-central-1`, `ap-southeast-1`, or `ca-central-1`. | Multiple blocks are allowed — each becomes its own `env` property. The runtime injects the credential, so no access key or secret key appears in your code. **Documented in [Cloud Storage binding](/docs/cloud-storage/bindings).** ### \[storage.sqldb.\] — SQL database binding | Key | Value | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------- | | block key `` | The handle — a name you choose. `env.` is a `SqlDatabase` (prepare/batch/exec). TypeScript-only, via `@telnyx/edge-runtime` ≥ 0.9.0. | | `id` | The database UUID, from `telnyx-edge storage sqldb create`. Binding by name, or creating a database from the manifest, is rejected before deploy. | Multiple blocks are allowed — each becomes its own `env` property, and two blocks carrying different ids are two separate databases. The id is checked when the function ships: an id that does not exist, belongs to another organization, or has not finished provisioning fails the deploy (currently as a generic `HTTP 500` that does not name the binding). **Documented in [SQL Databases](/docs/edge-compute/sqldb).** ## telnyx.toml The umbrella manifest replaces `[edge_compute]` with top-level keys and adds `[[actors]]`. On `ship`, the module graph rooted at `main` is bundled into a single file with esbuild (TypeScript/JavaScript only) and the manifest ships with it. ```toml theme={null} name = "account-svc" # function name main = "src/index.ts" # entry module — exports the fetch handler (and the actor class) compatibility_date = "2026-05-01" [[actors]] binding = "ACCOUNT" # the property on env — your handle type = "Account" # the class to instantiate per name [[ratelimits]] name = "API_LIMIT" # → env.API_LIMIT.limit({ key }) limit = 100 # successful checks per key and window period = 60 # fixed window in seconds: 10 or 60 [telnyx] # same binding blocks as func.toml binding = "MY_TELNYX" [[secrets]] binding = "GREETING" name = "DEMO_GREETING" ``` | Key | Value | | -------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `name` | Function name, used by the platform to register the function. | | `main` | Entry module — the root of the client-side esbuild bundle. | | `compatibility_date` | Runtime compatibility pin. | | `[[actors]]` | Actor bindings — `binding` is the `env` property, `type` the class to instantiate per name. Ship-time constraints (identifier rules, uniqueness, the 32-character type cap) are specified in the [Stateful Actors configuration reference](/docs/edge-compute/stateful-actors/api-reference/configuration). | | `[[ratelimits]]` | Rate limiter bindings — `name` becomes the `env` property, `limit` is the per-key budget, and `period` is the fixed window in seconds (`10` or `60`). | The project shape — one module exporting both the actor class and a `fetch` handler — is covered in [Project Structure](/docs/edge-compute/stateful-actors/guides/project-structure). `telnyx-edge new-func --actor` scaffolds it. **Documented in [Stateful Actors](/docs/edge-compute/stateful-actors)** — the [configuration reference](/docs/edge-compute/stateful-actors/api-reference/configuration) covers the `[[actors]]` block in full. ### \[\[ratelimits]] — per-key rate limiting | Key | Value | | -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `name` | Binding handle. It is uppercased and hyphens become underscores (`api-limit` → `env.API_LIMIT`). The resulting handle must be identifier-safe and unique across every binding in the manifest. | | `limit` | Positive integer: the maximum successful checks for one key in a window. | | `period` | Integer window duration in seconds. Only `10` and `60` are supported; duration strings such as `"60s"` are invalid. | | `namespace_id` | Optional. Functions sharing a `namespace_id` and a `name` share one set of counters; without it each function counts on its own. A positive integer as a string (`"1001"`) — not a KV namespace ID. | Multiple blocks are allowed and operate independently. The platform provisions their internal counter storage; there is no rate limiter resource to create first. **Documented in [Rate limiting](/docs/edge-compute/rate-limiting).** ## Configured outside the manifest The manifest references resources that exist outside it by name or ID — you create each one separately, and the block only points at it: * **Secret values** — stored server-side with `telnyx-edge secrets`; `[[secrets]]` and the injected environment variables only reference the key. See [Secrets](/docs/edge-compute/configuration/secrets). * **KV namespaces** — created with `telnyx-edge storage kv create`; `[storage.kv.]` only references the namespace `id`. See the [KV quick start](/docs/edge-compute/kv/quick-start). * **Cloud Storage buckets** — created in the [Mission Control portal](https://portal.telnyx.com/#/storage/buckets) or over the [S3-compatible API](/docs/cloud-storage/quick-start); `[storage.cloudstorage.]` only references an existing bucket by `bucket_name`. See [Cloud Storage binding](/docs/cloud-storage/bindings). * **SQL databases** — created with `telnyx-edge storage sqldb create`; `[storage.sqldb.]` only references the database `id`. See the [SQL Databases quick start](/docs/edge-compute/sqldb/quick-start). Rate limiters are the exception: a `[[ratelimits]]` block creates a platform-managed binding during deployment, so no separate resource or customer KV namespace is required. ## Ship-time validation Binding handles and `[env_vars]` names share one `env` namespace. `ship` (and `types`) enforce two hard rules and warn on a third: * **Duplicate `[[secrets]]` handles are rejected** — `ship` fails, because `env.SECRETS.get("")` would be ambiguous. * **A binding (or actor) named `SECRETS` is rejected** when a `[[secrets]]` block is declared — it conflicts with the `env.SECRETS` namespace. * **A name collision between `[env_vars]` and a binding — including an `[env_vars]` entry named `SECRETS` — only warns.** Both land on `env`, so one shadows the other and `ship` proceeds; rename one. * **Each `[[ratelimits]]` block in `telnyx.toml` is validated before upload.** `name` must be non-empty, exact names must not repeat, `limit` must be positive, and `period` must be `10` or `60`. The deployment service also rejects names that collide after normalization or with another binding section, and applies the same rules to a block declared in `func.toml`. ## Related * [Bindings catalogue](/docs/edge-compute/runtime/bindings#catalogue) — every binding at a glance: declaration and `env` surface for Telnyx API, Secrets, KV, Object storage, SQL databases, and Actors * [Environment variables](/docs/edge-compute/configuration/environment-variables) — everything that lands in the container's environment * [Secrets](/docs/edge-compute/configuration/secrets) — both access surfaces for `[[secrets]]` * [Telnyx API binding](/docs/edge-compute/telnyx-api) — the `[telnyx]` block and the `env.` client * [KV quick start](/docs/edge-compute/kv/quick-start) — the `[storage.kv.]` block and `KvNamespace` * [Cloud Storage binding](/docs/cloud-storage/bindings) — the `[storage.cloudstorage.]` block and `CloudStorageBucket` * [SQL Databases](/docs/edge-compute/sqldb) — the `[storage.sqldb.]` block and `SqlDatabase` * [Stateful Actors configuration](/docs/edge-compute/stateful-actors/api-reference/configuration) — the `[[actors]]` block in full * [Rate limiting](/docs/edge-compute/rate-limiting) — the `[[ratelimits]]` block and `env..limit({ key })` * [CLI reference](/docs/edge-compute/reference/cli) — `new-func` writes the manifest; `ship` and `types` read it