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 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. AI usage
per session is small (a few short calls), and the fast tier handles almost
all of it, so per-chat AI cost is typically fractions of a cent.

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.

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.