Skip to main content

​
Telnyx Compute — Documentation Index

Edge compute functions, runtime bindings, stateful actors, and private networking. One section of the Telnyx developer docs (https://developers.telnyx.com). Root index: https://developers.telnyx.com/llms.txt · Full content for this section: https://developers.telnyx.com/development/llms/compute-llms-full-txt.md

​
Subsections

Focused per-subsection files (index + full content):

​
Overview

  • Edge Compute: Edge Compute is Telnyx’s platform of compute primitives — functions, stateful actors, KV, object storage, and SQL — for building and deploying applications to the Telnyx edge. It’s particularly power…

​
Functions

  • Functions: Functions are the compute primitive of Telnyx Edge Compute — an HTTP server in a container, deployed to Telnyx’s edge network and wired to KV, stateful actors, object storage, and the Telnyx API.
  • Quickstart: Install the CLI, scaffold a function in the language of your choice, ship it, and curl the live URL — about five minutes.
  • Best Practices: Production patterns for Edge Compute functions — configuration, connection reuse, KV caching, state placement, error handling, and observability without a platform logging surface.
  • AI Assistants and Edge Compute: Use a Telnyx Edge Compute function as the backend for dynamic variables and webhook tool calls — no separate server required.
  • Local Development: Edge Compute functions are ordinary programs in containers — run and test them locally with each language’s native tooling; a standalone function needs no emulator.
  • 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…
  • Environment Variables: Functions run as containers, so configuration arrives as ordinary environment variables — declared in the project manifest, injected from secrets and bindings, or set by the platform.
  • Secrets: Organization-scoped values for sensitive data, managed with the CLI. Every function receives them as environment variables; TypeScript functions can also read them through a typed binding.
  • CI/CD: Deploy Edge Compute functions from CI: install a pinned CLI release, authenticate with an API key, and ship — working pipelines for GitHub Actions, GitLab CI, and CircleCI.
  • Routes & Domains: Every deployed function gets a public HTTPS URL — https://{func-name}-{org-nickname}.telnyxcompute.com — and HTTP requests to that URL are the only way a function is invoked.
  • Versions & Rollback: Every successful ship produces an immutable revision. revisions list shows a function’s deploy history; rollback instantly retargets traffic to a previous revision — no rebuild, no re-upload.
  • Overview: What the platform provides to your code at runtime — the container execution environment, the per-language entrypoint contract, and the bindings that connect your code to platform resources.
  • Execution Model: Functions run as Linux containers scaled with traffic: cold starts, warm reuse, scale to zero, a 30-second (max 60) request budget, HTTP as the only trigger, and no durable memory.
  • HTTP Handler: The per-language entrypoint contract — which file the platform runs, the signature you implement, who owns the HTTP server, and who answers health probes.
  • Overview: Typed, pre-authenticated handles to platform resources, resolved by the runtime from a manifest declaration.
  • Overview: Call the Telnyx API from Edge Compute through a pre-authenticated binding — no API keys in your code.
  • Quick Start: Declare, type, and ship a function that returns your Telnyx account balance through the binding.
  • API Reference: The Telnyx API binding is a pre-authenticated client handle — discover its resources and methods through generated types or the client method reference.
  • Receiving Messages: Handle inbound SMS on Edge Compute — your function is the messaging profile webhook, and replies go out on-net with no 10DLC campaign.
  • Handling Calls: Answer inbound calls on Edge Compute via Call Control — your function is the Call Control app webhook; answer the call and play audio.
  • Observability: There is no platform logs, metrics, or traces surface today — observability is the CLI’s control-plane views, your function’s /health endpoint, and structured events your function emits to a sink you…
  • CLI Reference: Every CLI command in v0.2.5 — install from GitHub release binaries, authenticate, scaffold, deploy, and manage revisions, secrets, bindings, storage, and actor types.
  • Pricing: Telnyx Edge Compute functions bill on two meters — requests and CPU time — with a monthly free tier of 3.6M requests and 36M CPU-milliseconds.
  • Limits: Resource limits for Telnyx Edge Compute functions: request timeout (30 s default, 60 s max), memory, body size, code size, deployment rate, and KV storage caps.

​
Stateful Actors (Beta)

  • Stateful Actors: A stateful actor is a single-threaded server that owns one entity’s state. The platform runs one instance per name, routes every call for that name to it, runs your methods one at a time, and persist…
  • Stateful Actors Quick Start: Scaffold an Account Stateful Actor, deploy it, and prove per-account isolation, safe concurrent debits, and persistence.
  • How It Works: A stateful actor is a single-threaded server with durable, flush-before-ack storage — one per entity. Derive the execution model from first principles, then map it mechanism-by-mechanism to what you’…
  • Execution Model: The four guarantees a stateful actor’s runtime makes: exactly one instance per name, one call at a time, writes durable before the caller sees a result, and only persisted state survives. Each maps t…
  • Lifecycle & Placement: Where a stateful actor instance runs, when it is activated and evicted, and what survives a restart. Instances are placed on first touch, evicted when idle, and restarted on deploy or host failure —…
  • Addressing: Reach a stateful actor instance by name. idFromName is deterministic — the same name always lands on the same instance; newUniqueId mints a fresh one. Both return a stub you call methods on.
  • Overview: The Stateful Actor API surface — the StatefulActor base class, ActorContext, per-instance storage, the actor binding (ActorNamespace / ActorStub), alarms, configuration, and errors.
  • Base Class: The StatefulActor base class — subclass it, declare async methods, and they become RPC-callable from a stub. Holds this.ctx and this.env.
  • Actor Context: The this.ctx object on a StatefulActor — the instance’s identity, per-key storage, single alarm, one-shot init, and its live WebSockets.
  • Actor Storage: Per-key persistent storage for a Stateful Actor, accessed as this.ctx.storage — get/put/delete/list/transaction plus the alarm API. Writes that return successfully are persisted at turn granularity.
  • Actor Namespace: The env.<BINDING> handle your function calls into — idFromName (deterministic) and newUniqueId (random), both returning an ActorStub.
  • Actor Stub: The client handle returned by idFromName / newUniqueId. Calling a method on the stub is an RPC to that one actor instance.
  • Actor Alarms: Schedule deferred work from inside a Stateful Actor method using the single per-actor alarm. At-least-once delivery with automatic redelivery on failure; make your handler idempotent.
  • Configuration: The telnyx.toml [[actors]] block that declares an actor binding — binding (the env property) and type (the class to instantiate per name).
  • Errors: Errors the Stateful Actor runtime can surface — BlockConcurrencyTimeoutError, ActorOutputGateError, ActorMethodTimeoutError, ActorFetchTimeoutError, and CodecError.
  • Project Structure: A Stateful Actor project is one module that exports two things — the actor class and a fetch handler — wired together by an [[actors]] binding in telnyx.toml.
  • Local Development: Run a Stateful Actor project locally with telnyx-edge dev — a full function + actor stack in Docker where env.<BINDING> calls resolve and actor state survives hot reloads.
  • Shared Actors: Reach one Stateful Actor type from multiple functions on the same account by declaring the same type under different bindings — the owner ships the class, the reference ships none.
  • When to Use Stateful Actors: Use a stateful actor when an entity has state that must be mutated coherently across many requests. Use a plain function for stateless work, and a database for cross-entity transactions or bulk queri…
  • Key-Value: Each Stateful Actor has private, durable, per-key storage at this.ctx.storage — get/put/delete/list plus atomic transaction(). Values round-trip through a codec. Reach for it by default; use SQL when…
  • SQL: Each Stateful Actor has a private, durable, embedded SQLite database at this.ctx.storage.sql — synchronous exec() with positional binds, typed rows, a single-pass cursor, and transactionSync() for at…
  • WebSockets: Terminate a live WebSocket on a Stateful Actor: the function authenticates once at the handshake, then inbound messages dispatch one at a time on the owning instance — single-threaded, with durable s…
  • Connection Lifecycle & Limits: How WebSocket connections to a Stateful Actor begin and end: the handshake guarantees, the close-code table, today’s duration budget, a reconnect pattern, and the frame, queue, and handler limits.

​
Network

  • Network Overview: Overview of Telnyx Programmable Networking — private networks, gateways (IGW, PGW, WGW, VXC), and how to build global software-defined connectivity.
  • Coverage: Check Telnyx Programmable Networking coverage by region and point of presence (PoP). View global PoP locations for cloud connectivity and SD-WAN deployments.
  • Networks Configuration: Create and manage Telnyx Programmable Networks — private virtual networks that connect your sites, clouds, SIMs, and gateways with software-defined routing.
  • WireGuard Gateway Setup: Configure a WireGuard Gateway (WGW) on Telnyx Networking to terminate WireGuard VPN tunnels from clients into your private cloud network.
  • Linux Configuration: Configure a Linux device as a WireGuard peer to connect to a Telnyx WireGuard Gateway. Includes keys, peer settings, and systemd service setup.
  • macOS Configuration: Configure a macOS device as a WireGuard peer to connect to a Telnyx WireGuard Gateway. Set up keys, peer endpoints, and the WireGuard macOS app.
  • Windows Configuration: Configure a Windows device as a WireGuard peer to connect to a Telnyx WireGuard Gateway. Includes the WireGuard Windows client and tunnel config.
  • Internet Gateway (IGW): Configure an Internet Gateway (IGW) on a Telnyx network to provide internet egress for your private cloud, edge, or SD-WAN-connected resources.
  • Private Wireless Gateway (PGW): Configure a Private Wireless Gateway (PGW) to route Telnyx IoT SIM traffic into your private network. Includes APN, IP, and policy configuration.
  • VXC Introduction: Overview of Telnyx Virtual Cross Connect (VXC) availability, pricing, and API structure for connecting to AWS, Azure, and Google Cloud.
  • Coverage & Availability: Check Virtual Cross Connect (VXC) availability across cloud providers and regions using the Telnyx coverage API before provisioning.
  • Pricing: Monthly recurring charges for Telnyx Virtual Cross Connects (VXC) by bandwidth tier, plus guidance on cloud provider connectivity costs.
  • VXC API: Provision and manage Virtual Cross Connects (VXC) on Telnyx Networking via API. Create direct cloud connections to AWS, GCP, Azure, and partner networks.
  • AWS Direct Connect: Step-by-step guide to provisioning a Telnyx Virtual Cross Connect (VXC) to AWS Direct Connect, including VPC setup and BGP configuration.
  • Google Cloud Interconnect: Step-by-step guide to provisioning a Telnyx Virtual Cross Connect (VXC) to Google Cloud Interconnect, including VLAN attachment and BGP setup.
  • Azure ExpressRoute: Step-by-step guide to provisioning a Telnyx Virtual Cross Connect (VXC) to Azure ExpressRoute, including circuit setup and BGP configuration.

​
API Reference (Compute)

​
Regions

​
Networks

​
WireGuard Interfaces

​
Private Wireless Gateways

​
Public Internet Gateways

​
Virtual Cross Connects

​
Global IPs