Custom domains now available for Edge Compute Functions

You deployed a function to Edge Compute. It works. The URL is api-w4xq.telnyxcompute.com. That is not a URL you can put in front of customers, hand to a partner, or wire into a production webhook. You need your own domain.

Most serverless platforms solve this by auto-provisioning a managed TLS certificate through their own CA or a partner like Let's Encrypt. You point your DNS at their edge and they handle the rest. That is convenient and works well for teams who do not have specific certificate requirements. The tradeoff is that you lose control over the certificate chain. You cannot bring a certificate from your own PKI, cannot pin a specific intermediate, and cannot use a CA that your security team mandates. When compliance dictates which CAs are approved, a managed certificate is not a solution.

Custom domains for Edge Compute Functions are now available in open beta. You bring your own PEM certificate and private key. The platform handles routing and serves the certificate you uploaded, but it never owns it. The CA is yours, the rotation schedule is yours, and the certificate chain is yours.

Why bring your own certificate matters

Every serverless platform that auto-provisions TLS makes the same trade: convenience for control. The managed path is the default, and on most platforms it is the only path.

That works for most teams. It does not work for teams who operate under compliance regimes that dictate which CAs are approved, or who need to chain to an internal PKI, or who have a security team with opinions about the certificate chain. For those teams, a managed cert blocks deployment rather than enabling it. They need to serve their function from their own domain with a certificate their security team issued.

Telnyx's Edge Compute Functions now support that workflow. You upload a PEM-encoded certificate and private key through the telnyx-edge CLI. The platform provisions routing, terminates TLS at the edge, and serves your certificate to every request. Certificates are stored encrypted with AES-GCM. There are no restrictions on certificate type, key size, or chain length beyond requiring PEM format and a non-expired cert whose SAN or CN matches your domain. TLS 1.2 and 1.3 are supported, with HTTP/2.

How to add a custom domain

The workflow is three CLI commands: claim the domain, verify DNS, upload your certificate. First, add a [[domains]] block to your telnyx.toml. See the CLI reference for installation and setup.

[[domains]]
hostname = "api.acme.com"

Then run the CLI to add the domain, verify ownership, and upload your cert:

telnyx-edge domains add api.acme.com <function_id>
# Add the TXT record to your DNS provider, then verify
telnyx-edge domains verify api.acme.com
telnyx-edge domains cert upload api.acme.com --cert cert.pem --key key.pem

When you run domains add, the platform generates a verification token. You add a TXT record at _telnyx-verification.api.acme.com with the value telnyx-verify=<token> and run domains verify to confirm ownership. Verification is one-time, so you can update or replace certificates freely without re-verifying DNS. The whole flow takes a few minutes if your DNS provider propagates quickly. See the custom domains docs for the full walkthrough.

You need telnyx-edge CLI v0.5.0 or later. Domain management is also available through the REST API.

Zero-downtime migration with simultaneous routing

When you add a custom domain, the default *.telnyxcompute.com URL does not go away. Both URLs serve traffic at the same time, which means you can migrate without a cutover. Existing traffic keeps hitting the default URL while you point new traffic at your custom domain. You update your DNS at your own pace, and the default URL becomes a fallback you can keep or remove.

If a certificate expires, the custom domain stops serving traffic but the default URL keeps working. Your function does not go down. You rotate the certificate with telnyx-edge domains cert upload and the custom domain comes back, all while the default URL serves traffic continuously. The failure mode is graceful: the custom domain goes dark, but the function itself stays live.

You can also point multiple custom domains at the same function. The limit is 25 custom domains per organization with no per-function restriction, so api.acme.com and api2.acme.com can both route to one deployment. DNS verification is per-domain, not per-function, so adding a second domain to an existing function is the same three-command flow.

Where custom domains fit in Edge Compute

Custom domains are a feature of Functions, the compute entry point for Edge Compute. Functions run in containers alongside KV for key-value storage, Stateful Actors for per-entity state, Cloud Storage for bulk objects, and Inference for model serving on owned GPUs. Components reach each other through bindings with zero network hops, removing the cross-vendor latency that stacks up when you rent compute, storage, and inference from different providers.

Custom domains extend that platform by giving your functions a URL that belongs to you, secured by a certificate you control. Both URLs work, so nothing breaks during migration or cert rotation.

Get started

Custom domains are available now in open beta. You need telnyx-edge CLI v0.5.0 or later.

Read the Edge Compute docs to get started, or get your API key by signing up at telnyx.com/sign-up to deploy your first function.