telnyx-edge binary, authenticate with auth api-key set, and run ship. This page gives you those steps as working pipelines for GitHub Actions, GitLab CI, and CircleCI, plus the patterns for staging/production and rollback.
The three steps every pipeline runs
- The CLI ships as GitHub release binaries only — it is not on npm and there is no package manager formula. There is also no un-versioned “latest” asset:
releases/latest/download/...URLs return 404. Pin a version in aTELNYX_EDGE_VERSIONvariable so bumping is a one-line change. For arm64 runners, use thelinux-arm64asset. telnyx-edgedoes not read aTELNYX_API_KEYenvironment variable on its own. Store your API key as a CI secret and runtelnyx-edge auth api-key set "$TELNYX_API_KEY"as a pipeline step — it persists the key to~/.telnyx-edge/config.tomlfor the rest of the job.shiphas no environment flag. It deploys the function identified byfunc.tomlin the shipped directory, and its flags are--from-dirand--timeoutonly. Staging and production are separate functions.
ship prints the function’s live URL (https://{func-name}-{org-nickname}.telnyxcompute.com — see Routes & Domains). The URL is stable across deploys.
GitHub Actions
A complete workflow that tests on every push and deploys on pushes tomain. Only the install, authenticate, and ship steps are Telnyx-specific — the test job is ordinary npm and assumes a committed lockfile and a test script (the scaffold ships neither); substitute your project’s own checks.
TELNYX_API_KEY.
GitLab CI
TELNYX_API_KEY as a masked variable under Settings → CI/CD → Variables. The ubuntu:24.04 image runs as root, so no sudo is needed.
CircleCI
TELNYX_API_KEY as a project environment variable (Project Settings → Environment Variables) or in a context.
Staging and production
There is no--env flag and no environment promotion — ship always deploys the function that func.toml names. Environments are separate functions, e.g. my-api-staging and my-api, each with its own URL, secrets bindings, and revision history.
Register both once, locally (new-func creates the function server-side and writes its UUID func_id into that directory’s func.toml — this is a one-time setup step, not a CI step):
func.toml files in the repo; each pipeline job copies the matching one into place before shipping:
func.toml, the two files can also point at per-environment resources — for example a separate KV namespace id per environment.
func.toml swap, keep one function directory per environment and ship each with telnyx-edge ship --from-dir <path>. If staging and production live in different Telnyx accounts, store one API key secret per account and reference the right one in each job.
Rollback
Every successfulship produces an immutable revision. Rolling back retargets traffic to a previous revision instantly — no rebuild, no re-upload:
deploy_ok can be rolled back to. You can wire these commands into a manually triggered pipeline job (e.g. workflow_dispatch on GitHub Actions), but they work just as well from a laptop — rollback does not need your source tree.
A git revert + re-ship also works, but it goes through a full build; rollback is the fast path.
Smoke test after deploy
The function URL is stable, and the TypeScript/JavaScript scaffold answers/health with 200 — on other runtimes, point the check at a route your function serves. A post-deploy check is one step:
telnyx-edge rollback as above. There is no platform metrics or logs surface to poll — see Observability for what your function should emit instead.
CI secrets vs. function secrets
Two different things:
Function secrets are not deployed from CI variables — manage them with the CLI (the arguments are positional). Values are injected into function containers at deploy time, so re-ship a function after changing a secret it uses. See Secrets.
Troubleshooting
Next Steps
- CLI reference — every command and flag.
- Versions & Rollback — how revisions and rollback work.
- Secrets — runtime secrets for your functions.
- Observability — what you can (and can’t) see after a deploy.