If your LiveKit agent already works, begin with the problem you want a new host to solve. A phone connection, a model provider and an application host are separate parts of the system. Changing one does not always require replacing the others.
LiveKit on Telnyx is a beta service for hosting LiveKit agents on Telnyx infrastructure. It creates a hosting alternative to LiveKit Cloud. You can also use Telnyx SIP with LiveKit without adopting that hosting service. Our recommendation is to evaluate the smallest change that solves your current problem, then use the checklist below if a hosting move still makes sense.
1. Decide what actually needs to change
Choose the scope of your LiveKit evaluation
Scroll the table horizontally to see every column.
| Your problem | First experiment | What stays under your control |
|---|---|---|
| Phone connectivity or carrier choice | Try a Telnyx SIP connection to your existing LiveKit setup. | Your application host, booking tools and conversation logic. |
| One model's cost or behavior | Evaluate a supported model integration with the rest of the call path held constant. | Your host and business workflow, unless the integration requires another change. |
| Hosting cost or operational fit | Run a separate LiveKit-on-Telnyx deployment and compare it with Cloud. | Your business rules and backend; verify every host-dependent setting. |
Write a one-sentence success criterion before opening either console. For example: 'We need to diagnose failed booking updates from call logs without a second support ticket.' That is testable. 'The new platform should be better' is not a migration requirement.
2. Inventory dependencies before copying the agent
Telnyx describes its hosting as compatible with the LiveKit framework and documents deployment through the LiveKit CLI. Framework compatibility is a useful starting point; it does not verify your application's operating setup. Build an inventory from your current deployment rather than assuming a successful import means the migration is complete.
- Runtime: language and package versions, container build, required system packages and startup command.
- Models: exact providers, versions, voice identifiers, credentials and any provider-side limits.
- Phone path: number, inbound and outbound routing, dispatch rules, caller metadata and transfer destination.
- Business tools: backend URLs, authentication, network access, request timeouts and duplicate-write protection.
- Operations: secrets, logs, recordings, alerts, retention needs and the person responsible for investigating failures.
Give each dependency an owner and a verification result. Keep credentials in the host's secret configuration rather than in a shared worksheet. Use a separate test number and synthetic customer records so that evaluation calls cannot change real appointments.
3. Keep the first comparison controlled
Deploy the smallest working version of your existing workflow. Keep the prompt, booking backend, model configuration and call scenarios comparable where supported. If you change the model at the same time, record that change: a different voice or response time cannot then be attributed to hosting alone.
For an appointment-change agent, start with one appointment type. The caller supplies the required identity details, chooses an available slot and receives confirmation only after the backend saves the change. A natural-sounding reply without the saved booking is a failed task.
4. Use a pass/fail worksheet
Suggested acceptance cases for an appointment-change migration
Scroll the table horizontally to see every column.
| Test case | Pass condition | Evidence to keep |
|---|---|---|
| Normal appointment change | Exactly one booking changes to the caller's requested available slot. | Call identifier and before/after synthetic booking records. |
| Slot disappears mid-call | The agent offers another slot and does not confirm the rejected change. | Booking response and the caller-facing answer. |
| Backend times out | The change remains unconfirmed; retries cannot create a duplicate. | Tool request identifier, timeout and final booking state. |
| Caller interrupts a confirmation | The final saved details match the final agreed request. | Conversation record and saved appointment. |
| Human destination does not answer | The caller receives your chosen fallback rather than an unexplained disconnect. | Transfer outcome and the caller's next experience. |
| Rollback rehearsal | The test number reaches the original working agent again. | Routing change, confirmation call and time taken. |
Run each case repeatedly and include overlapping calls at your expected busy period. Record successes and failures as counts. Keep the application version, provider configuration and call path with the results so that a later change does not silently invalidate them.
5. Compare the complete bill and migration effort
LiveKit Cloud meters resources including agent sessions, inference and observability, with plan allowances. Telnyx advertises waived session fees during its hosting beta. A temporary waiver is useful for evaluation, but it does not establish the permanent cost of your application.
- Fix the workload: connected minutes, peak simultaneous calls, number count, destinations and transfer behavior.
- List fixed plan charges and included allowances before adding overages.
- Separate agent hosting, calling, model usage, recordings and monitoring; use the billing unit for each.
- Count external model usage once, even if a host consolidates other services onto one invoice.
- Request the terms after beta discounts end, then add the engineering and support hours required by the move.
For example, 1,000 caller minutes is not automatically 1,000 minutes for every billable component. Transfer legs, recorded time and model tokens can have different quantities. Keep a measured quantity, unit rate, allowance and billing provider on each worksheet line. Leave an unknown charge marked 'needs estimate' instead of treating it as zero.
6. Set the rollback rule before switching a live number
Keep the previous deployment and routing configuration available. Define who can restore the route, what failure triggers that action and how you will check calls after the change. Do not retire the working setup until the replacement meets your acceptance cases and an agreed observation period.
Stay with the current setup if the new host does not solve the stated problem or the savings depend on terms you cannot confirm. Move when the same business task works reliably, your team can investigate failures and the complete cost justifies the change. The useful outcome is a documented operating decision, not merely a successful first call.
Still choosing the architecture?
Compare the hosting routes, phone connections, transfer responsibilities and cost components before preparing a migration.
Read LiveKit Agents vs Telnyx