What are edge functions and how they work

Takeaways

• Edge functions are server-side code that runs at data centers distributed around the world, as close to the user as possible, instead of in one central region.
• Traditional serverless solves scaling. Edge functions solve geography. A Lambda still runs in a single region, so a user on the other side of the planet still waits for the round trip.
• There are two ways to run code at the edge. V8 isolates boot in under a millisecond but restrict you to JavaScript, TypeScript, and Web Standard APIs. Containers give you the full runtime at the cost of a heavier deployment unit.
• Telnyx Functions runs containers on Telnyx-owned infrastructure co-located with carrier points of presence, and with GPU capacity in supported locations, so a function, a phone call, and a model inference can share a building.
• Pick a platform by asking what runtime you need, how far your users are from your compute, and whether the infrastructure underneath is owned or rented.

What are edge functions

The idea is simple. Move the code to the user instead of making the user wait for the code. Edge functions are server-side functions that execute at whichever of a platform's globally distributed data centers sits closest to the incoming request, rather than at a single origin in one region. The platform handles the routing, runs your code at that location, and returns the response without a trip to a central server.

The reason this matters is physics. Light moves through fiber optic cable at roughly 200,000 km/s, about two thirds of its speed in a vacuum, because the glass has a refractive index near 1.47. Researchers measuring real fiber paths have documented this constraint in detail. A request from Tokyo to a server in Virginia covers around 13,000 km each way, and no amount of application tuning changes that number. Google's performance guidance is blunt about it: you cannot beat physics, and serving content geographically close to users is the most effective way to reduce round-trip time.

That distance shows up in behavior. Research from Think with Google found that 53% of mobile site visits are abandoned if a page takes longer than three seconds to load.

Traditional serverless does not fix this. Serverless removed server management and gave you automatic scaling, which is a real problem solved. But a function deployed to us-east-1 runs in us-east-1 no matter who calls it. Edge functions move the code instead of asking the user to wait.

How edge functions work

Every edge platform does two things. It distributes your code to many locations, and it routes each request to the closest one. Where platforms differ is what they run inside those locations.

V8 isolates

Isolate-based platforms run your code inside a lightweight sandbox in a shared V8 process, the same isolation model browsers use to separate tabs. There is no container to start and no operating system to boot, so an isolate can be ready in well under a millisecond.

export default {
 async fetch(request) {
 return new Response("Hello from the edge");
 },
};

The tradeoff is the runtime. Isolates expose Web Standard APIs such as fetch, Request, Response, and Streams rather than a full Node.js environment. Node compatibility on these platforms has improved, but it remains partial. If your code depends on a native module, a language other than JavaScript or TypeScript, or a framework that assumes a real filesystem, an isolate is the wrong shape.

Containers

Container-based edge platforms run a normal process. You write an HTTP server in whatever language you already use, and the platform deploys that container to its edge locations. Nothing about your dependencies, your runtime, or your framework has to change.

import { createServer } from "node:http";

const port = Number(process.env.PORT ?? 8080);

createServer((req, res) => {
 res.writeHead(200, { "content-type": "application/json" });
 res.end(JSON.stringify({ ok: true }));
}).listen(port);

Containers are heavier than isolates. That is the honest tradeoff. Platforms mitigate it by keeping containers pre-deployed at the edge rather than starting them per request, which removes the boot cost from the request path without removing the full runtime.

Telnyx Functions takes the container approach and supports JavaScript, TypeScript, Python, Go, and Java through Quarkus. The Edge Compute docs cover the full runtime and configuration model.

Distribution and routing

Once your code is at multiple locations, the platform's routing layer handles the rest. Anycast or equivalent routing sends each request to the nearest healthy node. You deploy once. The platform decides where each request lands.

Edge functions vs serverless functions

Both are serverless in the sense that you do not manage servers. They solve different problems, and the differences are concrete enough to put in one place.

When to use each

Use regional serverless when the work is long, the data lives in one region anyway, and latency is not the binding constraint. Nightly reports and queue consumers belong in Lambda.

Use isolate-based edge functions when the work is small, stateless, and latency sensitive. Rewriting a header or checking a token is exactly what isolates are for.

Use container-based edge functions when you need proximity to the user and a real runtime at the same time. Anything involving a Python ML library, a Go binary, an existing framework, or a dependency that assumes a filesystem lands here.

Most production architectures combine them. Put the perimeter logic at the edge, keep the heavy asynchronous work in a region, and let each layer do the thing it is good at.

Edge function use cases

Webhook processing at the edge

Webhooks are latency sensitive by design. The sender expects a fast acknowledgement, and slow responses trigger retries. Running the receiver at the edge means validation and signing happen near the sender rather than after a transcontinental hop. The Telnyx code examples repository includes edge-compute-webhook-proxy-python, which validates incoming voice and SMS webhooks, adds edge timestamps, HMAC-signs the payload, and forwards it to your backend.

def handler(request):
 payload = request.json()
 if not verify_signature(request.headers, payload):
 return response(401, {"error": "invalid signature"})
 enriched = {**payload, "edge_received_at": now_iso()}
 forward_to_origin(enriched)
 return response(200, {"ok": True})

Geo-routing

Route callers by where they actually are. US callers get an English agent, LATAM callers get Spanish with localized greetings, and EU callers get a flow that collects explicit recording consent before anything is stored, which is one of the lawful bases for processing under GDPR Article 6. The routing decision happens at the edge node that received the request, so it costs almost nothing. See edge-geo-smart-router-python in the same repository.

A/B testing

Assign variants at the edge and you avoid a client-side flash and an origin round trip. edge-ivr-ab-tester-python splits callers across IVR flows, tracks completion rates per variant, and promotes the winner once results reach statistical significance.

AI inference at the edge

This is where co-location changes the math. A voice agent that has to reach a model in another region pays the network cost on every turn, and conversational quality degrades quickly as that number climbs.

Telnyx puts GPU capacity in the same buildings as its telephony PoPs. When it lit up a GPU PoP in Paris in July 2025, it reported sub-200ms round-trip time for voice AI across Europe, and it reported the same threshold for APAC after deploying GPUs in Sydney that October.

Read that number the way it is scoped. Sub-200ms is reported for regions where a GPU PoP and the telephony PoP share a facility, not as a global average. That scoping is the useful part, because it tells you what to ask any edge inference vendor: which locations, and how far is the model from the network. Pair the co-location with Voice AI and the model, the media path, and your business logic all stay inside one network.

The same architecture runs open-source models, so you can point a function at a new model the week it releases and compare it against your current one on your own traffic, rather than waiting for a vendor's release cycle to reach you.

Rate limiting and auth at the perimeter

Rejecting a bad request at the edge is cheaper than rejecting it at the origin, and it keeps abusive traffic off your backend entirely. Token validation, quota checks, and IP reputation all work well as edge functions because the decision needs no origin state beyond a fast KV lookup.

Choosing an edge function platform

Work through these questions in order.

1. What runtime do you need? If your code is JavaScript or TypeScript and touches nothing outside Web APIs, an isolate platform will be fast and cheap. If you need Python, Go, Java, or a native dependency, you need containers.
2. How much cold start can you tolerate? Isolates win on raw boot time. Pre-deployed containers remove the boot from the request path, which matters more than the theoretical floor for most workloads.
3. How wide is the footprint, and where does it actually matter? More PoPs is not automatically better. What matters is coverage where your users are.
4. What can the function talk to without a network hop? Storage, state, and inference reachable from inside the platform beat the same services behind a public API and an auth handshake.
5. Is the infrastructure owned or rented? This determines who controls capacity, pricing, and data residency over the long term.

How the platforms compare

Cloudflare Workers pioneered isolate-based edge compute and has the largest footprint of the group. Cloudflare's published network footprint lists data centers in more than 330 cities across over 125 countries. It is excellent at what it does. The constraint is the runtime, which is JavaScript and TypeScript on Web Standard APIs with partial Node compatibility.

Vercel Edge Functions offered strong developer experience for teams already in the Next.js ecosystem. Vercel has since deprecated standalone Edge Functions for new projects and points teams toward Vercel Functions with the Node.js runtime and Fluid compute, which effectively retires the constrained-runtime approach for new projects.

Deno Deploy is TypeScript-first and has added native npm support, which widened what you can import considerably. It remains a JavaScript-runtime platform.

Telnyx Functions is the container option, and the difference is what sits underneath. Telnyx holds carrier licenses in more than 30 countries and runs its own private backbone, its own PoPs, and GPU capacity placed alongside them. A function can sit next to the model it calls and next to the Voice API controlling the call it is reasoning about, on one network, on one bill.

Telnyx started at Layer 0 with carrier licenses and a private backbone, then added GPU capacity at the edge on top of it. Most platforms in this category start at the application layer and rent everything below it.

Owning the full network, from the PSTN through to inference, is the reason edge compute and telecom belong together. Voice AI is the workload where latency is not a metric on a dashboard, it is the product. A pause the caller can hear is a failed conversation. Controlling every hop is what makes the budget for that pause big enough to work with.

Ship in three steps

The workflow is deliberately short. Scaffold a function, write a server, ship it, get a URL.

telnyx-edge new-func my-function
telnyx-edge ship

The shape of the flow is what matters here. Check the Functions quickstart for the current CLI syntax, required flags, and authentication step before you run anything. You get a public URL with automatic TLS and distribution across Telnyx edge locations, plus configuration for KV namespaces and storage.

Frequently asked questions

What are edge functions? Edge functions are server-side functions that run at data centers distributed globally instead of in one central region. Each request is routed to the nearest location and executed there, which cuts the network round trip for users far from a traditional origin server.

How do edge functions work? The platform replicates your code across many edge locations. When a request arrives, routing sends it to the closest healthy node, the function executes there, and the response returns from that node. Platforms run this code either in V8 isolates or in containers.

What is the difference between edge functions and serverless functions? Both remove server management. Serverless functions run in a single cloud region and can execute for up to 15 minutes on Lambda. Edge functions run in many locations at once and are optimized for short, latency-sensitive work close to the user.

Are edge functions faster than AWS Lambda? For a globally distributed audience, usually yes, because the network distance is shorter and cold starts are lower. For long-running or compute-heavy jobs where the data already lives in one region, Lambda is often the better fit.

Can edge functions run Python or Go? On isolate-based platforms, no. Those run JavaScript and TypeScript. On container-based platforms like Telnyx Functions, yes. Telnyx supports JavaScript, TypeScript, Python, Go, and Java through Quarkus.

Build on the edge with Telnyx

Edge functions remove the distance between your code and your users. Telnyx removes the distance between your code, your storage, your models, and your phone network, because all of it runs on infrastructure Telnyx owns.

Write a server in the language you already use, run telnyx-edge ship, and get a public URL served from the same network that carries the calls.

Explore Telnyx Functions or read the Edge Compute docs to get started.