Skip to content

Documentation / Guides / Production readiness

Production readiness

Treat provider composition and bot behavior as one reviewed deployment artifact.

Before traffic

  • Pin the exact approved VAANI artifact and verify its digest.
  • Pin compatible LiveKit/provider plugin versions; align patch versions.
  • Validate all prompt, language, model, voice, tool, fallback, transfer, recording, and result-publisher configuration.
  • Prove the main call flows and terminal failures offline.
  • Run non-connecting preflight for secrets and infrastructure names.
  • Run credentialed canaries only in an authorized environment.
  • Define a new-call rollback and running-call drain plan.

If the application came from the companion Starter CLI, its passing offline backend/frontend checks are a baseline, not a live acceptance gate. Add credentialed provider, LiveKit room, SIP/routing, security, and deployment evidence for the actual environment before traffic.

Deadlines and fallback

Set lifecycle and operation budgets from an end-to-end call SLO. Retries consume the existing absolute deadline. Declare only behaviorally acceptable fallbacks with ExplicitFallback; never silently downgrade language, tool support, privacy, or response behavior.

Provider circuit behavior and normalization should remain runtime mechanics. The consumer chooses whether a particular failure should retry, fall back, transfer, apologize, or end within the supported policy surface.

Security and secrets

  • Use explicit credential sources and scopes.
  • Resolve credentials as late as possible and never cache them in consumer state, setup, logs, prompts, or results.
  • Keep SIP numbers/trunks and transfer destinations behind named routes.
  • Close tool schemas and authorize every tool server-side.
  • Redact transcript capture when full text is not necessary.
  • Treat recording as an explicit per-call legal/business decision.
  • Keep GCS objects private and result tables append-only.

Observability

Monitor provider-neutral dimensions:

  • call outcomes and lifecycle phase durations;
  • startup failures separately from owned call outcomes;
  • provider segments and normalized error categories/codes;
  • update, tool, transfer, recording, and Judge dispositions;
  • result publication delivery reports;
  • teardown forced rate and resource leaks;
  • usage/cost completeness—not just totals.

Correlate with safe call_id, result_digest, route IDs, and delivery idempotency keys. Do not log raw provider responses or credentials.

Rollback

Keep the previous consumer composition installable. A safe rollback:

  1. stops assigning new calls to the new entrypoint;
  2. routes new calls to the previous pinned composition;
  3. lets running calls finish on their original runtime/adapter snapshot;
  4. verifies one result and resource drain for both populations;
  5. does not mutate published call results.

Current validation boundary

The docs and examples are offline-first. Live provider, SIP, GCS, and PostgreSQL credentials are not available in the documentation environment, so those successes are deferred. Groq live validation is also outside the current tested path.

Next: troubleshoot deployments or private distribution.