What support covers
Aywa support should focus on the runtime software, installer, license activation, registry access, update process, runtime readiness, and reproducible voice/session issues.
Covered by Aywa
Runtime releases, installer behavior, license renewal, registry pulls, API compatibility, runtime bugs, and support-bundle analysis.
Owned by the operator
VPS/cloud account, network policy, provider accounts, telephony contracts, backups, DNS, TLS, secrets, and incident response.
Support bundles
A support bundle gives Aywa enough context to debug a runtime without asking the customer to paste raw logs, provider secrets, phone numbers, or call payloads into a ticket.
aywa support-bundle --redactIncluded
Runtime version, instance id, license state, readiness summary, recent errors, dependency status, and redacted config keys.
Redacted
API keys, provider tokens, bearer headers, passwords, SIP auth values, webhook secrets, and sensitive payload fragments.
Optional
Call ids, timestamps, and customer-approved log windows for a specific incident.
Never assumed
Aywa should not require raw audio, full transcripts, or provider secrets for ordinary support triage.
Update channels
Production customers should stay on stable. More aggressive channels can exist for
design partners and staging environments, but should not be the default production path.
stableDefault production channel. Security fixes and validated runtime updates.candidatePre-stable builds for staging validation with selected customers.betaPrivate preview builds for design partners and non-critical test environments.aywa update --channel stableSafe update flow
Updates should be boring: preflight, backup check, pull, restart, readiness, then rollback if the runtime fails to become ready.
Check license, registry access, disk space, Docker status, and dependency readiness.
Confirm recent Postgres and artifact backups before changing production.
Pull the signed release artifact and restart the runtime service.
Require /readyz, metrics, and CLI status before the update is accepted.
Rollback
The updater should keep the previous working release available locally. If the new release fails readiness or the operator rolls back manually, the runtime returns to the last known-good image.
aywa update --channel stable
aywa status
aywa rollback --to previousRegistry and license access
Updates are tied to an active subscription and valid license state. The runtime should keep operating through the signed lease window, while registry pulls and new activations depend on valid access.
Active licenseRuntime can renew leases and pull allowed update channels.Grace windowRuntime warns the operator and keeps operating while renewal is restored.Expired accessNew activations and registry updates stop. Customer data remains in customer infrastructure.Support request checklist
A useful support request should include the smallest reproducible context, not the largest raw data dump.
Runtime context
Runtime version, channel, deployment target, region, and recent update history.
Incident window
Start/end time, affected assistant/call ids, and whether the issue is reproducible.
Provider path
LLM, STT, TTS, telephony, storage, and analytics providers involved.
Redacted bundle
Attach aywa support-bundle --redact output whenever possible.