Technical Overview

How Varen is actually built: where your data lives, what happens when you ask a question, how models are chosen, and how the system is secured and kept up to date. This page describes the platform as it exists today, including the boundaries it does not yet cross.

The local node difference

The mainstream AI model — the one used by Anthropic, OpenAI, Google, and most of the industry — is a "trust us with your data" model. The provider's cloud is the system of record. Every conversation you have, every file you upload, and every preference the service remembers about you lives on their servers, under their retention terms, behind their account settings. Your control is a policy promise: a toggle in a settings page, a data-processing agreement, an assurance that deletion requests are honoured.

Varen inverts that arrangement. The system of record is a node — a small server you control, running on your own hardware or in a cloud account that belongs to you. Your conversations, uploaded files, knowledge base, profile, and search indexes are stored on that node. The Varen control plane has no customer content store: it holds your account, your licence, your node's connection state, and your billing records — the operational data needed to run the service — and nothing that constitutes your work.

The honest version of this claim is about where data rests, not a claim that data never moves. When you ask a question, the question and the context retrieved for that turn are sent to a hosted AI provider so an answer can be generated. That is a deliberate, per-turn crossing — not a standing copy of your workspace on someone else's infrastructure. The difference from the incumbents is that the provider never becomes the permanent home of your data. See Privacy & Data for the full data-handling reference.

Two planes: control and data

Varen is split into a control plane and a data plane, and the split is architectural rather than a configuration option.

The control plane (Varen's SaaS) runs the public service at varen.tech. It handles sign-in and session tokens, account and licence records, node registration and connectivity, request routing, model access, usage metering, and billing. It keeps its operational records in PostgreSQL and uses Redis for caching. It is not the store for your conversations, files, or knowledge.

The data plane is your node: a small Docker Compose stack running the Varen node software, the Qdrant vector database, and Ollama for local embeddings. All durable content lives in the node's data directory and volumes on the host machine. The node makes only outbound connections — it is never exposed to the public internet.

Your browser runs the Varen desktop app, a client-side web application served from varen.tech. It talks to the control plane over HTTPS; when it needs something from your node, the control plane relays that traffic through the encrypted tunnel the node maintains.

The path of a question

When you send a message, this is what happens:

1. Your browser sends the turn to the control plane over HTTPS, authenticated with your session token.
2. The control plane identifies your node and relays the turn to it through the encrypted tunnel.
3. The node searches its local indexes — your files, knowledge base, and profile — for material relevant to the question. The vector search uses embeddings computed locally on the node; nothing leaves the machine at this step.
4. The control plane classifies the question — subject matter, which adviser domains apply, whether current information from the web would help — and assembles the prompt: your question, the retrieved context, and the relevant facts.
5. The prompt is sent to a model through the model gateway, and the response streams back to your browser token by token.
6. The finished answer is stored on your node as part of the session. The control plane records only the usage — model, token counts, cost — for your ledger.

Why multi-model

No single AI model is the best at everything. Claude is good at many things, but not all. ChatGPT is good at different things, but not all. Gemini has its own strengths again, and open-weight models are improving quickly. A platform tied to one vendor inherits that vendor's weaknesses as well as its strengths — and has nowhere to go when that vendor has a bad day.

Varen is deliberately multi-model. Rather than picking one provider, Varen maintains a model catalogue behind a gateway and assigns models to roles: a fast, inexpensive model classifies each question; a strong reasoning model writes the final answer; specialist models handle document extraction, analysis, and background tasks. Each role has fallback models, so a provider outage or a slow endpoint degrades gracefully instead of failing.

The catalogue today draws on the Claude, GPT, and Gemini families, with open-weight models included where they earn their place. Because models are assigned per role rather than hard-wired into the product, the catalogue evolves as better models appear — Varen aims to use the best of all of them, and the routing improves without you changing anything. You never pick a model; the platform matches the model to the task.

Web search and the Australian focus

Varen can consult the live web when a question calls for current or external information. A search gateway — aggregating independent search indexes — runs alongside the control plane. Each turn is assessed: if the question depends on recent events, current rules, prices, or sources outside your workspace, a web search runs and the results are considered alongside your local context. Results appear in a collapsible Web results panel, and any result can be fetched into your workspace as a permanent asset. See Lens & Web Search for the user-facing detail.

Two things make the search integration unusual. First, searches can be scoped to curated, authoritative domains — for Australian legal, tax, and government questions, results can be drawn preferentially from official sources rather than the open web's loudest voices. Second, where currency matters, news sources are included so answers reflect what is true this week, not what was true at a model's training cut-off.

The Australian focus is deliberate and runs deeper than search. The adviser library is built with Australian law and practice in mind — the ATO, Centrelink, the Fair Work Act, Medicare and the PBS, the NDIS, and state and territory tenancy law are treated as first-class context, not edge cases. The interface speaks Australian English, and billing is in Australian dollars.

Memory and knowledge

Each workspace accumulates a structured knowledge base: facts you have stated, insights the system has inferred, and a derived statement of the workspace's intent. Your profile — stable context about who you are — is stored once per node and applies across every workspace on it. All of it is queryable, visible, and editable, and all of it lives on the node. The mechanics are covered in Knowledge & Profile.

Where inference happens

It is worth being precise about what runs where, because "local" is a word the industry uses loosely.

Local on your node: document storage, conversation history, the knowledge base, vector indexing and search, and the embedding models that make retrieval work. Your corpus is never sent to a third party to be indexed.

Hosted: classification, model-based file processing, and — always — the generation of final answers. Every reply you read is produced by a hosted model that received your question and the retrieved context for that turn; Varen does not currently offer fully local answer generation. PDF extraction is split: pages with a usable text layer are converted by Varen's own stateless tools service (mechanical parsing, no third party), while pages without one — scanned images, vector charts — reach an external vision provider only through your explicit per-page selection. The Privacy & Data page covers the tiers.

Security and tenant isolation

Varen is multi-tenant, and isolation is enforced at each boundary rather than assumed. Browser sessions use signed tokens over TLS. Nodes are authorised by licence key and connect outbound through an encrypted WireGuard tunnel with authenticated gRPC — the node is never reachable from the public internet. Accounts, licences, nodes, workspaces, and sessions are owned and checked as separate scopes, so one tenant's content is never addressable through another's credentials. Public endpoints are rate-limited at the edge, and billing and administration surfaces are restricted and audited.

Upgrades and operations

The node is designed to run unattended on customer hardware. Published node images are multi-architecture and served from Varen's own registry. When an update is released, the control plane flags the node for reload; a small watcher on the host pulls the new image and recreates the stack, preserving all data and volumes. Day-to-day operations — start, stop, logs, status, reload, uninstall — are handled by a single varen command installed alongside the node. The operational detail is in Installation.

Where the node can live

The sovereignty model is the same in every topology — durable content lives on the node — but who controls the hardware differs. Running the node on your own equipment gives you full physical and operational control. Running it in your own cloud account (AWS, Hetzner, DigitalOcean, or similar) keeps the infrastructure yours, with the usual provider-level access that comes with any cloud tenancy. Managed hosting may be available on request; because operator access and backup arrangements matter for sovereignty, confirm the specifics with us before relying on it. The trade-offs are discussed in Privacy & Data.