> ## Documentation Index > Fetch the complete documentation index at: https://developers.telnyx.com/llms.txt > Use this file to discover all available pages before exploring further. # Deploy and Operate ## Deploy ```bash theme={null} telnyx-acp deploy --dry-run # the plan; writes nothing telnyx-acp deploy # asks once, then ships; --yes in scripts ``` The first `deploy` registers the agent and builds it, which typically takes about ten minutes (`deploy` waits up to 25); every `deploy` after that is a new revision, and `versions` lists the earlier ones (`rollback` is refused today; see [Beta Limitations](#beta-limitations)). A project with a phone number, an email inbox or a channel is asked once for the account's webhook public key, stored as the `TELNYX_PUBLIC_KEY` secret; in scripts, store it beforehand with `telnyx-acp add secret TELNYX_PUBLIC_KEY`. With `email` set, `deploy` finds or creates the inbox, subscribes its domain to `email.received` and prints the address. With `web` set, it prints the page's URL and the embed tag; the page is public from then on. A phone number's line ends with what its texting cannot do, when the number's features say so: `domestic texts only: this number cannot receive or send international SMS, so a phone abroad cannot reach it`. ### When a Deploy Fails Most failures happen before anything ships, as a list of problems that each name the field and the fix: ```text theme={null} telnyx-acp: agent.json has 1 problem model: "openai/gpt-4o-mini" is a openai model, which the inference API serves only with your own key in the OPENAI_API_KEY secret — telnyx-acp add secret OPENAI_API_KEY (dev reads OPENAI_API_KEY from .env), or use a Telnyx-hosted model such as "meta-llama/Llama-3.3-70B-Instruct" ``` The same list comes from `telnyx-acp validate`, so a project can be checked without deploying. A number in `phone` that is not in the account, or not active yet, stops the `deploy` and is named. A secret the model or a channel needs, missing from the platform, is named with the `add secret` command that stores it. A build that fails ends the `deploy` with exit 1 and the platform's reason on the first line; `agent.json` records no new revision (a `TELNYX_PUBLIC_KEY` stored on the way stays). `telnyx-edge ship status --logs` has the build's records, `telnyx-acp versions ` lists the ships and their status, and `telnyx-acp status` shows which revision is active. ## Status ```bash theme={null} telnyx-acp status ``` The function's state and active revision (with the note `deploy` wrote), the actor type, each number with what answers on it, each webhook (`✓` when it points at this agent, "changed outside the CLI: now …" when something else repointed it), and the address. `--json` carries the same as data. ## Logs ```bash theme={null} telnyx-acp logs --since 30m # the function's and the actor's records, interleaved telnyx-acp logs --since 30m --type invocations # each request: conversation, method, status, duration telnyx-acp logs --tail # the function's stream, live ``` Runtime records are one JSON line per event; [logs](/docs/agents/cli/logs) explains each line. `--since` is a duration such as `10m`, `2h`. ## Versions and Rollback ```bash theme={null} telnyx-acp versions support-agent # every revision, the active one marked, the git SHA at ship time telnyx-acp rollback support-agent # point traffic at an earlier one; webhooks untouched ``` A revision whose build failed cannot be rolled back to and is shown with the reason. ## Invoke and RPC ```bash theme={null} telnyx-acp invoke support-agent --conversation alice "hi" # one turn; the reply from the state stream telnyx-acp invoke support-agent --conversation alice --stream "…" # each assistant message as it lands telnyx-acp text "…" # one SMS to its number, from one of the account's telnyx-acp rpc support-agent --conversation alice receive "hi" "+15550001111" "msg-1" telnyx-acp rpc support-agent --conversation alice approve ``` `invoke` is one text turn: it posts the text to the conversation's instance over the mount and reads the reply back. A run paused for an approval, a canceled run and a run that completed without saying anything each end `invoke` with a line that says so instead of a timeout. `rpc` calls any `@rpc` method on the instance with its arguments as JSON; a method that is not `@rpc` is refused as the agent refuses it, with no stack trace. ## Secrets ```bash theme={null} telnyx-acp add secret OPENAI_API_KEY # prompts for the value (stdin when piped); stores and binds it telnyx-acp remove secret OPENAI_API_KEY ``` Values never touch `agent.json` or a command line; the error for a rejected secret names it, never its value. ## Delete ```bash theme={null} telnyx-acp delete support-agent --dry-run # the plan, by id; touches nothing telnyx-acp delete support-agent # prints exactly what changes and asks; --yes in scripts ``` Each wired artifact's webhook goes back to its pre-deploy value (left alone if something else repointed it), each number goes back where it was and the artifacts `deploy` created are deleted, the inbox and webhook `deploy` created are removed, then the function, then the actor type. The actor type is deleted once the function's teardown has settled; `delete` retries for about two minutes, and a type still there after that ends `delete` with exit 1 and the `telnyx-edge actors delete` command to run, `deployed` and `.telnyx/` already cleared. Project files stay; `deployed` leaves `agent.json` and `.telnyx/` is removed, so the next `deploy` registers the agent afresh. A webhook that will not restore stops the verb before the function goes, with two exceptions `delete` reports and moves past: an artifact already deleted outside the CLI (`already gone from the platform; nothing to restore`), and one that had no webhook before the agent and whose API refuses a blank one (`webhook still points at the agent … clear or delete it in Mission Control`; a Call Control application is one). The artifacts `deploy` created for a bare number are deleted with the number, never restored. `--json` lists them as `gone` and `unclearable`. ## Beta Limitations * **Pre-release.** `@telnyx/acp` is a pre-release on npm. Each beta is published as `latest` until the first stable version ships, and a release can change the behavior these pages describe. * **No control plane API.** `telnyx-acp` drives `deploy`, `status`, `logs`, `versions` and `rollback` from the client, through `telnyx-edge`. `telnyx-acp list` is reserved for that API and is not available yet. * **One address per project.** One project is one function with one address, and the active revision is the only one addressable. There is no staging slot or traffic split; separate environments are separate projects with their own names. * **No rollback.** The platform refuses a rollback for a function that owns its actor type, which every agent the CLI deploys does. The way back is the project checked out at the earlier commit, which `versions` names by its git short SHA, and deployed again. * **No way to end one conversation.** There is no command to end one conversation and clear its state. `delete` removes the agent and every conversation with it. * **Bundled packages.** `deploy` links the CLI's own `@telnyx/acp` and `@telnyx/edge-runtime` into the bundle, so the versions pinned in an exported project's `package.json` do not change what ships.