Configuration

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.<NAME>], and [storage.cloudstorage.<NAME>].
telnyx.toml (umbrella) — a 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.<binding> 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 binding declaration so telnyx-env.d.ts matches the manifest. The binding blocks — [telnyx], [[secrets]], [storage.kv.<NAME>], [storage.cloudstorage.<NAME>], and [[actors]] (umbrella only) — each resolve to a typed handle on env. This page documents their manifest keys; the 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:

[edge_compute]
func_id = "7819cf01-39a8-400e-9bce-3d792ffa4017"
func_name = "demo-ts"

# For environment variables and secrets:
# Use telnyx-edge secrets add <name> <value>
# Secrets are injected as environment variables into all your functions

A manifest using every available block:

[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

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).

[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 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.

[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.

[[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 <key> <value>`.

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.

[telnyx] — Telnyx API binding

Key	Value
`binding`	The property on `env` — `env.<binding>` 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.

[storage.kv.<NAME>] — KV namespace binding

Key	Value
block key `<NAME>`	The handle — a name you choose. `env.<NAME>` 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.

[storage.cloudstorage.<NAME>] — Cloud Storage bucket binding

Key	Value
block key `<NAME>`	The handle — a name you choose. `env.<NAME>` 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`, or `eu-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.

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.

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

[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.

The project shape — one module exporting both the actor class and a fetch handler — is covered in Project Structure. telnyx-edge new-func --actor scaffolds it. Documented in Stateful Actors — the configuration reference covers the [[actors]] block in full.

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.
KV namespaces — created with telnyx-edge storage kv create; [storage.kv.<NAME>] only references the namespace id. See the KV quick start.
Cloud Storage buckets — created in the Mission Control portal or over the S3-compatible API; [storage.cloudstorage.<NAME>] only references an existing bucket by bucket_name. See Cloud Storage binding.

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("<handle>") 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.

Bindings catalogue — every binding at a glance: declaration and env surface for Telnyx API, Secrets, KV, Object storage, and Actors
Environment variables — everything that lands in the container’s environment
Secrets — both access surfaces for [[secrets]]
Telnyx API binding — the [telnyx] block and the env.<binding> client
KV quick start — the [storage.kv.<NAME>] block and KvNamespace
Cloud Storage binding — the [storage.cloudstorage.<NAME>] block and CloudStorageBucket
Stateful Actors configuration — the [[actors]] block in full
CLI reference — new-func writes the manifest; ship and types read it

Overview

Get Started

Best Practices

Guides

Local Development

CI/CD

Runtime APIs

Observability

CLI

Platform

For AI Agents

Configuration

func.toml

[edge_compute] — identity

[env_vars] — environment variables

[[secrets]] — secret bindings

[telnyx] — Telnyx API binding

[storage.kv.<NAME>] — KV namespace binding

[storage.cloudstorage.<NAME>] — Cloud Storage bucket binding

telnyx.toml

Configured outside the manifest

Ship-time validation

​func.toml

​[edge_compute] — identity

​[env_vars] — environment variables

​[[secrets]] — secret bindings

​[telnyx] — Telnyx API binding

​[storage.kv.<NAME>] — KV namespace binding

​[storage.cloudstorage.<NAME>] — Cloud Storage bucket binding

​telnyx.toml

​Configured outside the manifest

​Ship-time validation

​Related

func.toml

[edge_compute] — identity

[env_vars] — environment variables

[[secrets]] — secret bindings

[telnyx] — Telnyx API binding

[storage.kv.<NAME>] — KV namespace binding

[storage.cloudstorage.<NAME>] — Cloud Storage bucket binding

telnyx.toml

Configured outside the manifest

Ship-time validation

Related