telnyx-edge is the command-line tool for Edge Compute: it scaffolds function projects, deploys them, and manages the resources they bind. This page covers every command in v0.5.9.
Installation
The CLI ships as GitHub release binaries only — it is not on npm and there is no package-manager install.
Each tarball extracts into a versioned directory containing the
telnyx-edge binary:
auth
auth login or auth api-key set to authenticate the CLI, then auth status to confirm the credential works.
new-func
-l / --language selects the runtime and -n / --name sets the function name. On success the API response contains the function’s UUID func_id. Rapid successive calls can hit HTTP 429 rate limits.
What each scaffold contains:
The entrypoint contract differs per language — see HTTP handler.
ship
ship uploads, builds, pushes, and deploys the function named by the directory’s func.toml. There is no environment flag — staging and production are separate functions. Umbrella projects (telnyx.toml) are bundled client-side before upload: the module graph rooted at main is compiled into a single file with esbuild (TypeScript/JavaScript only), and the manifest is included so the platform can deploy any [[actors]] it declares.
On success, ship prints the live URL — stable across deploys:
{func-name}-{func-id-prefix}.telnyxcompute.com — see Routes & Domains. Each successful ship also produces an immutable revision (revisions, rollback).
ship status
--logs adds a snippet underneath when the platform sent one: always for a build failure, and for a deploy failure only when it was a startup crash. Read-only.
The
<function> argument accepts a function name or id (resolved like inspect).
list
--page (default 1) and --page-size (default 25).
inspect
logs
Requires CLI v0.5.1 or newer.
[timestamp] [level] message. The level is best-effort and frequently wrong on stack traces — a multi-line error arrives as several separate lines.
--since and --last are clamped rather than refused when they exceed the maximum. Warnings (incomplete result, truncated output) go to stderr so they never contaminate piped output.
The <function> argument accepts a function name or id (resolved like inspect).
log-export
Requires CLI v0.5.3 or newer.
logs. See Log export.
set flags:
Naming neither
--runtime nor --invocations exports both. set is a full replace, not a patch. get accepts --json and emits {"configured": bool, "data": ...|null}.
status
https://api.telnyx.com. Run it first when any other command misbehaves.
revisions
ship produces an immutable revision — see Versions & Rollback.
rollback
deploy_ok can be rolled back to; get ids from revisions list. Your source tree is untouched — the next ship deploys whatever is on disk, as a new revision.
secrets
Secrets are organization-scoped key-value pairs for sensitive data. The arguments are positional — there are no--name/--value flags:
add on an existing key overwrites it. Values are injected at deploy time, so ship each function that uses a changed secret.
Functions read secrets two ways, and both are always true: every secret is injected as a plain environment variable into all functions in your organization, and TypeScript functions can additionally declare a [[secrets]] binding and read through the typed env.SECRETS.get(). See Secrets for both surfaces.
bindings
Manages the org-level Telnyx credential (one per organization) behind the Telnyx API binding. The per-function flow needs none of these commands — declaring[telnyx] in func.toml wires the binding automatically on ship.
types
env surface from your manifest (func.toml or telnyx.toml), folding every declared binding into one global Env interface:
Declarations only — no JavaScript, no runtime glue, no source edits. Re-run after changing any binding declaration.
types generates a .d.ts consumed by tsc — it has no effect on js, go, python, or quarkus runtimes. Bindings on those runtimes are reached over REST instead; see Bindings.storage
storage kv covers namespace create/list/get/delete, and storage kv key covers put/get/list/delete including server-side TTL and prefix listing. Full flags and examples live in the KV CLI reference.
storage sqldb manages SQL databases: create/list/get/delete, execute for running SQL against a database out-of-band, export for dumping a database as a .sql file, and migrations for versioned schema files. It requires CLI v0.3.0 or newer — see the SQL Databases CLI reference for the full flags and examples.
actors
inspect reports the actor type’s live instance count; instances lists the persisted instances (type/id pairs, e.g. Counter/alice); logs and metrics show recent activity — see Stateful Actor observability. Output renders backend state — never inferred from local files.
actors logs
Requires CLI v0.5.8 or newer; --tail requires CLI v0.5.10 or newer.
--type, both streams print interleaved by time: runtime is the console.log/error output from your own method bodies; invocations is one platform-recorded record per method call (auto-RPC, fetch(), or alarm()), so it reports traffic even for a type that logs nothing.
With --tail, the command switches to live mode instead: it stays attached and streams new lines as they arrive (Ctrl-C stops cleanly). --since and --last are ignored in live mode; --type and --instance filter it the same way as history mode. With --json, live mode emits one JSON object per line. Sessions are severed roughly every 10 minutes by the API edge proxy; the CLI reconnects automatically with backoff, but lines emitted during the gap are lost — use history mode when completeness matters.
--since and --last are clamped rather than refused when they exceed the maximum.
Runtime lines print as [timestamp] [level] message. Invocation lines print as [timestamp] instance method outcome <duration>ms, where outcome is ok or an error outcome.
<type> accepts an actor type name or id (resolved like actors inspect).
actors metrics
Requires CLI v0.5.8 or newer.
24h.
Stored state is the type’s total ctx.storage.sql size across all its instances over the window, not a per-instance figure — per-instance point-in-time size stays on actors instances.
--since is capped at 90h: past the backend’s invocation-window budget, request/latency/byte-size fields would come back null while CPU, memory, and storage kept reporting, so the CLI refuses wider windows rather than return a partial response.
<type> accepts an actor type name or id (resolved like actors inspect).
metrics
Requires CLI v0.5.2 or newer. Shows a deployed function’s recent request and resource metrics: request count, success/error rates, latency percentiles (p50/p95/p99), CPU, and memory over a--sincewindow (default24h, max168h).
actors metrics <type> — covers StatefulActor types and additionally reports stored state size.
dev
Requires CLI v0.5.6 or newer. Runs atelnyx.tomlproject locally in Docker — the function runtime and its StatefulActors (KV, SQL, alarms) — served athttp://127.0.0.1:8787, with hot reload on save. Needs Docker with Compose v2.17 or later; the first run downloads about 1 GB of runtime images.
[[secrets]], [telnyx], [storage.*], [[ratelimits]]) are not available locally and are listed at startup. See Local Development for the full guide, including how to reset the local environment and delete persisted state.
domains
Manages custom domains for a function. After adding a hostname, verify domain ownership and upload your own TLS certificate before serving HTTPS traffic.deployments
Requires CLI v0.5.2 or newer. Shows a function’s deploy history including why deploys failed — each ship’s build, deploy, and rollback outcome.
config
Views and changes persistent CLI preferences stored in~/.telnyx-edge/config.toml (for example, confirmation-prompt behavior). Authentication and endpoint settings are managed by auth and shown by status, not by this command.
reset-func
created state — preserving its id, name, and config — so you can fix the code and ship again. Allowed only from a terminal failure state (build_failed, deploy_failed, delete_failed); a healthy function can’t be reset (use delete-func), and an in-progress operation must finish first.
delete-func
Related
- Configuration — every
func.toml/telnyx.tomlkey the CLI reads - CI/CD — install, authenticate, and ship from a pipeline
- Versions & Rollback — how revisions and rollback behave
- KV CLI — the full
storage kvsurface - SQL Databases CLI — the full
storage sqldbsurface, includingexecute,export, andmigrations - Stateful Actors — the projects behind
--actorand theactorscommand