Execution Model

An Edge Compute function is a Linux container running an HTTP server — one you run yourself in TypeScript and JavaScript, one run for you in Go, Python, and Java. The platform starts containers when traffic arrives, reuses them while it continues, and reclaims them — down to zero — when it stops. Everything on this page follows from that.

Request path

Route — a request to https://<func-name>-<org-nickname>.telnyxcompute.com reaches the platform (routing).
Place — a warm container takes it, or a new one starts (a cold start).
Execute — the server process handles the request and writes the response.
Keep warm — the container stays up for subsequent requests until it is recycled.

Container lifecycle

Cold start

A cold start is the first request’s cost of a new container: the image starts, the language runtime boots, your module-level code runs, and then the request is served. Put expensive setup — HTTP clients, connection pools, parsed config — at module scope so it runs once per container instead of once per request:

import * as http from "node:http";

// Module scope — runs once per container, at cold start
const startedAt = Date.now();
const cache = new Map<string, string>(); // per-container cache — not durable

const server = http.createServer((req, res) => {
  // Handler scope — runs per request
  res.writeHead(200, { "Content-Type": "application/json" });
  res.end(JSON.stringify({ containerAgeMs: Date.now() - startedAt }));
});

server.listen(process.env.PORT || 8080);

Curl that function twice: a near-zero containerAgeMs means the request paid a cold start; a growing one means the container was reused. The same split exists in every runtime — package-level vars and init() in Go, module scope or the optional start(cfg) hook in Python, application-scoped state in Quarkus. The per-language entrypoint contracts are in HTTP handler.

Warm reuse

While traffic continues, requests land on existing containers and skip initialization. Module state persists between requests on the same container — treat it as a cache keyed by container, nothing more. Two requests may or may not share a container, and the platform gives you no way to control which.

Recycling and scale to zero

Containers are reclaimed without notice: after idling, when a new revision is shipped (telnyx-edge ship — see Versions), or by platform scaling decisions. At zero traffic a function scales to zero containers; the next request pays a cold start. Treat container memory like a process that can be killed at any instant: only what you wrote to durable storage is real. See Where state lives for what “durable storage” means here. In Python, your function class may define an optional stop() hook, called on scale-down or update — use it for best-effort cleanup, never for durability.

Scaling

The platform scales the container count with concurrent load. There is no concurrency knob to configure — scaling is automatic.

Traffic pattern	Platform response
Spike	New containers start — expect cold starts
Sustained	Containers stay warm
Falling	Containers are gradually reclaimed
Zero	Scale to zero after an idle period

Request timeout

A function must respond within 30 seconds by default, 60 seconds maximum; a request that exceeds the budget is terminated with a 504. There is no func.toml field for this — see Limits for the full table. Budget outbound calls below the deadline so you return a real error instead of being cut off:

const upstream = await fetch("https://api.example.com/data", {
  signal: AbortSignal.timeout(25_000), // fail at 25 s, inside the 30 s budget
});

Triggers

HTTP is the only trigger — there are no cron, queue, or event triggers. A Telnyx webhook (a messaging profile or Call Control application pointed at your function URL) is just an HTTP request, so your function handles it like any other — see Receiving messages and Handling calls. For periodic work, call the URL from an external scheduler (a GitHub Actions cron job is enough), or use a Stateful Actor alarm to fire a callback on the platform itself.

Where state lives

Module state dies with the container, so anything that must survive needs a home:

Data	Use	Why
Per-entity state, counters, coordination	Stateful Actors (Beta)	One instance per name, serialized calls, durable writes — correct under concurrency
Cache entries, config, feature flags, sessions	KV	Globally distributed reads; opaque values up to 1 MiB with optional TTL
Files, media, large objects	Cloud Storage buckets	S3-compatible object storage

Don’t build counters or per-entity coordination on KV — concurrent read-modify-write races there, which is exactly the problem Stateful Actors exist to solve.

Next Steps

HTTP handler — the entrypoint contract per language
Limits — timeouts, memory, and payload caps
Versions — revisions, ship, and rollback

Overview

Get Started

Best Practices

Guides

Local Development

Configuration

CI/CD

Runtime APIs

Observability

CLI

Platform

For AI Agents

Execution Model

Request path

Container lifecycle

Cold start

Warm reuse

Recycling and scale to zero

Scaling

Request timeout

Triggers

Where state lives

Next Steps

​Request path

​Container lifecycle

​Cold start

​Warm reuse

​Recycling and scale to zero

​Scaling

​Request timeout

​Triggers

​Where state lives

​Next Steps

Request path

Container lifecycle

Cold start

Warm reuse

Recycling and scale to zero

Scaling

Request timeout

Triggers

Where state lives

Next Steps