FAQ

Answers to the questions MSP buyers and reviewers ask most. Deeper detail lives in the Requirements, Configuration Reference, and Operations Runbook.

Does AVA need Redis, PostgreSQL, or any external database?

No — by design. AVA runs as a single Node.js process with SQLite (via Prisma) for persistence and in-memory state for the live queue and engineer presence. This is a deliberate architecture choice, not a shortcut: at helpdesk scale (a small engineering team, dozens of concurrent chats) a distributed cache and a client-server database add operational surface — another service to patch, monitor, and back up — without buying anything. One container, one process, one database file. If the process restarts, persistent data (sessions, messages, engineers) is in SQLite and live state is rebuilt from it.

How much load can one instance handle?

The architecture is sized for the reality of an MSP helpdesk: roughly up to 6 concurrent engineers and around 30 concurrent chat sessions on a modest Docker host. The app process targets ~250 MB of RAM inside a 768 MB container cap. Each engineer is additionally limited to a configurable number of simultaneously active chats (MAX_ACTIVE_SESSIONS, default 2, range 1–10) so nobody silently drowns; further clients wait in the visible queue. If your helpdesk is substantially larger than this, talk to us before buying — see Support.

Is AVA multi-tenant? Can I serve several MSP brands from one install?

One deployment = one tenant. Each AVA instance serves a single MSP with a single AutoTask instance, a single Entra ID tenant, and a single brand identity. All of that identity is environment-driven (see White-label), so standing up a second brand means standing up a second instance — which, given the single-container footprint, is a small ask. There is no shared-database multi-tenancy, and therefore no cross-tenant data-isolation risk to reason about.

Which AI providers are supported? Am I locked into one?

AVA's AI layer is provider-agnostic (built on the Vercel AI SDK). Two model tiers are configured independently by env var:

• LLM_FAST — triage/classification, the engineer AI helpers (/draft, /rewrite, /summarize, "Draft all with AI") and other quick calls (default anthropic/claude-haiku-4-5-20251001)
• LLM_QUALITY — the final ticket summary (default anthropic/claude-sonnet-4-6)

Supported providers: Anthropic, OpenAI, Google (Gemini), and OpenRouter (which itself fronts many more models). Switching is a one-line env change plus that provider's API key — no code change. See Configuration → AI / LLM.

Can I run AVA without AI entirely?

Not as a switch, no — an API key for your configured provider is required at boot, because triage is part of the core flow (it classifies each incoming chat and drives ticket priority/issue-type mapping). What you can count on: every AI call is wrapped in graceful degradation — if a triage or summary call fails or times out, the chat proceeds with safe defaults (normal priority, raw description) rather than blocking a client. Automatic AI usage per session is small (a few short calls on the fast tier), so it typically costs fractions of a cent per chat. The engineer AI helpers run only when an engineer asks for them, and are capped per chat and per engineer per hour (AI_MAX_CALLS_PER_SESSION, AI_MAX_CALLS_PER_ENGINEER_PER_HOUR); setting AI_MAX_CALLS_PER_ENGINEER_PER_HOUR=0 turns all engineer AI off while triage keeps working.

Where does my data live? What leaves my server?

AVA is fully self-hosted — there is no vendor cloud, no telemetry, and no phone-home. Chat transcripts, session records, and uploads live in SQLite and a local uploads volume on your Docker host, under your jurisdiction and your backup policy (Operations).

Data leaves your server only for the integrations you configured, each to your own accounts:

What load does AVA put on my AutoTask API?

Light and bursty, proportional to chat volume — a handful of REST calls at session start (company/contact matching, ticket creation) and a handful at close (notes, transcript, time entry, attachments, status update). Slowly changing metadata — picklists, ticket statuses, billing codes — is cached in-process for an hour rather than re-fetched per chat. The AutoTask client respects rate-limit responses with exponential backoff and never blindly retries non-idempotent creates, so it can't duplicate tickets or hammer a struggling zone. A typical helpdesk's AVA traffic is a rounding error against AutoTask's API thresholds.

Can engineers leave notes the client won't see?

Yes. The reply box has a Reply | Internal note toggle. Internal notes are visible to your team only: they appear as cards in the dashboard transcript, are posted to the AutoTask ticket as Internal Only notes, and are included (labelled) in the chat transcript attached at close. They are never shown on the client's chat page, in client emails, in the client-facing AutoTask note, or in AI text written for the client. See the Engineer console guide.

Can engineers update the AutoTask ticket without leaving the chat?

Yes. The chat's Ticket panel (or /status and /priority) changes the ticket's status and priority after an explicit confirmation. Priority editing needs your P1–P4 priority mapping configured (AutoTask setup, Step 6); the Complete status is set in wrap-up. Your AutoTask workflow rules still apply to these changes, so review them before go-live.

Which browsers are supported?

Current versions of the evergreen browsers — Chrome, Edge, Firefox, and Safari. The client chat page is intentionally lightweight (a form, a chat pane, WebSockets) and has no exotic browser requirements. Legacy browsers without WebSocket support (e.g. Internet Explorer) are not supported.

Does it work on mobile?

The client chat page is responsive and works well on phones — useful when a client follows a chat link from email. The engineer dashboard is built desktop-first (it's a multi-pane workspace: queue, active chats, context panel) but degrades gracefully to smaller screens with a mobile top-bar layout. Engineers will be happiest on a desktop; there are no native mobile apps.

Do my clients need an account or password to use the chat?

No. A client opens the chat page, fills in name/email/description (protected by invisible reCAPTCHA v3), and gets a signed, expiring session token scoped to that one chat — no registration, no password, nothing to provision or reset. Engineers, by contrast, authenticate through your Microsoft Entra ID (O365) tenant with group-based authorization — no separate credential store to manage on either side.

Is there an embeddable website widget?

No — AVA is a standalone chat page by design, typically linked from an RMM systray icon, a support portal, or an email signature. A standalone page avoids the classic embed problems (third-party script weight on customer sites, CSP conflicts, cross-origin storage) and lets one hardened page receive the full security treatment. Support links can carry hints (e.g. device identity from a NinjaOne systray link) as URL parameters.

What does the NinjaOne integration do, and is it safe?

It's an optional, default-off device-at-a-glance card in the engineer dashboard: while chatting, the engineer sees the client machine's health (boot, disk, AV, patches, alerts) resolved from your NinjaOne instance, plus a deep link to open the device in NinjaOne. The credential you create for it is scoped monitoring-only — it physically cannot modify devices. An optional, separately-flagged enrichment step can attach the device to the AutoTask ticket. With its env vars unset, the feature is entirely absent. See Configuration → NinjaOne.

How do upgrades and schema migrations work?

Releases are git tags; upgrading is a build-before-swap Docker flow (the old stack keeps serving while the new image builds), and the container entrypoint syncs the database schema automatically on every start — additive migrations require no manual steps. Rollback to the previous tag is equally mechanical. Full procedure: Operations Runbook; release-by-release notes: Changelog.

Can I rebrand it as my own helpdesk?

Yes — that's a first-class feature, not a hack. Company name, descriptor, logo, monogram, tagline, welcome message, support phone, portal links, business hours, timezone, and even the AI's description of your clientele are all environment variables read at runtime. The White-label guide is the checklist.

How is AVA licensed, and where do I get support?

AVA is commercial software — see the LICENSE file in the distribution and the Support & Licensing page for contact channels, response expectations, and how to report bugs.