Zanus AI server: quote-only vs building your own

What Zanus AI sells, as of October 2026

Zanus AI sells a private AI server for a business, and the question behind most searches for it is what the same private AI server costs to build yourself. The short version: the appliance is a no-code box, priced by quote, that arrives configured and can run with no internet connection at all. The do-it-yourself version is a rented GPU (graphics processing unit) server running open-weight LLMs (large language models) behind an inference server, a chat interface, a vector store and an agent framework, and it needs one person who can run Linux. Which path is right turns on four things: who does the engineering, where the data is allowed to live, whether you can feed a 6 kW machine, and how many tokens a day you really use.

Everything here about Zanus comes from zanusai.com as read on 11 October 2026, except the Front Office plan prices and plan-list wording, which come from its live pricing data as read on 8 October 2026; that data did not load when we checked again on 11 October. The company describes itself as "a privately held American C-Corp specialized in high-tech AI solutions and engineering, headquartered in Pompano Beach, Florida", which its own page places in the greater Fort Lauderdale area. It says its hardware and software are "designed and assembled in the USA".

The product has three layers. Front Office AI is the part your customers talk to: phone, web chat, quotes and bookings. Back Office AI is what its own page heads "the company AI operating system", and the Airtight AI page counts "15+ modules". The functions named across the site include AI chat, client records, jobs, documents, scheduling, automations and an AI API (application programming interface). To the question "Do we need developers on our side?" the Back Office page answers "No. You need the person who knows the process." The third layer, Private On-Premises AI, is the same system on Zanus hardware inside your building. The site's menu now files it under the name Airtight AI, "on-premises AI servers", and calls it a separate product from the hosted plans. It runs "Zanus OS", it is sold with "Permanent licenses, fully owned", and it is "air-gap capable", taking offline update packages when you keep it off the internet.

On models, the server page says the box runs "the leading open-weight families", "chosen and sized with you at configuration", and that you can "swap or add models any time: new weights are a download". It does not name the families, the GPUs, the RAM or the storage size beyond "RAID 10 NVMe". On power, the server page asks for a "Standard 50A circuit at 115 or 220V" and gives "6 kW maximum" at full load, and describes the unit as silent and office-friendly, with no server room needed. On price, the box is "by RFQ" (request for quotation), "sized on GPU memory (models), RAM/context, and tokens per day". There is no public price for the hardware. The hosted Front Office plans did list prices in the live pricing data on 8 October 2026: five plans, from AI ANSWER at $329 a month to AI PRIVATE at $2,495 a month, or $3,290 to $24,950 a year with about 16.7% off for paying yearly, and AI PRIVATE was sold yearly only. None of them is the appliance. Even AI PRIVATE, described as "COMPLETE on your own isolated environment", is a hosted tenant, and the Front Office pricing page sends anyone who wants AI on their own premises to the AI servers, "a separate product, priced by quote". Delivery of the server is quoted at about three weeks, configured.

That is the public spec. Nothing below adds to it or guesses past it.

What the same private AI server looks like when you build it

The appliance bundles four things you can rent and assemble yourself: a GPU, an inference server that loads open-weight models, a chat interface for people, and a vector store with an automation layer that turns your documents into answers. The Linux part takes an afternoon. The business modules take weeks, and that gap is the real difference between the two paths.

Pick the box first. A CPU-only VPS (virtual private server) with 16 GB to 32 GB of RAM runs 7B and 8B models for one or two people at a time, at speeds you should measure in tokens per second before anyone depends on it. A rented GPU with 24 GB of VRAM (the memory on the graphics card) runs 8B models fast enough for a small team and fits models up to about 30B at 4-bit; 48 GB to 80 GB is the 70B class. Which models fit which card is worked through in what AI models you can self-host at each memory size.

Install the inference server. Ollama's Linux install is one line, and the full walkthrough lives in running Ollama on a VPS to self-host an LLM:

curl -fsSL https://ollama.com/install.sh | sh
sudo systemctl status ollama
ollama -v

systemctl status ollama should read active (running). On a machine with no GPU the installer prints WARNING: No NVIDIA/AMD GPU detected. Ollama will run in CPU-only mode. and continues, which is fine for testing and slow for users.

Pull a model and talk to the API. The service listens on port 11434 on the loopback address only:

ollama pull qwen3:8b
curl http://127.0.0.1:11434/api/generate \
  -d '{"model":"qwen3:8b","prompt":"Reply with one word: ready","stream":false}'

A healthy reply is a JSON object with a response field and "done":true. A reply of {"error":"model requires more system memory (6.4 GiB) than is available (3.8 GiB)"}, with your own two figures, means the weights do not fit in RAM, so pick a smaller model or a smaller quantization.

Add the chat interface. Open WebUI is the usual choice, and its README gives one command for the case where Ollama runs on the same host:

docker run -d -p 3000:8080 \
  --add-host=host.docker.internal:host-gateway \
  -v open-webui:/app/backend/data \
  --name open-webui --restart always \
  ghcr.io/open-webui/open-webui:main

Browse to port 3000 on the server's address, create the first account (it becomes the admin), and open the model list. If the list is empty, the cause is the loopback binding above: inside the container, host.docker.internal resolves to the host's Docker bridge address, and Ollama is listening on 127.0.0.1 only, so the connection is refused. docker logs open-webui shows Cannot connect to host host.docker.internal:11434. Fix it with a systemd override:

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"

sudo systemctl daemon-reload
sudo systemctl restart ollama

0.0.0.0 means every interface, including the public one. From this point the API is reachable from the internet unless the firewall blocks port 11434, and the API has no password of its own, so secure the Ollama API endpoint before you load a single company document. If Open WebUI is heavier than you want, there are lighter Open WebUI alternatives that talk to the same port.

Add the vector store. Qdrant runs as one container. Bind it to loopback, since only the applications on the box should reach it:

docker run -d --name qdrant --restart always \
  -p 127.0.0.1:6333:6333 -p 127.0.0.1:6334:6334 \
  -v qdrant_storage:/qdrant/storage \
  qdrant/qdrant
curl http://127.0.0.1:6333/collections

The check returns {"result":{"collections":[]},"status":"ok"} plus a timing field on a fresh install. Open WebUI has a built-in document store that is enough for a small library; Qdrant is for when an agent framework needs to query embeddings directly.

If more than a handful of people will use it at once, swap Ollama for vLLM, which batches requests across users on the GPU. The official image is the whole install:

docker run -d --runtime nvidia --gpus all \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -p 127.0.0.1:8000:8000 --ipc=host \
  vllm/vllm-openai:latest --model Qwen/Qwen3-8B

If Docker answers that it could not select device driver with GPU capabilities, the NVIDIA Container Toolkit is not installed, so Docker has no way to hand the card to the container. Install the toolkit and restart Docker, then run the command again. When to prefer each server is covered in Ollama versus vLLM.

The last layer is the one the appliance calls modules. On the rented path it is an agent framework that reads from the vector store, calls the model, takes actions against your other systems, and logs what it did. The candidates and what each is good at are compared in the best self-hosted AI agents, and if the agent needs to remember users across sessions, a self-hosted Mem0 memory server gives it that. None of this exists until you configure it, and that is the part of the appliance you are actually paying for.

Cost: a quote against a monthly bill

There is no Zanus number to put here, and inventing one would be worse than useless. What the site does say is how the quote is sized: on GPU memory for the models and RAM for the context, and on your tokens per day. Those are the same variables that set the price of the rented path, so you can at least build your side of the comparison honestly.

On the rented side the cost is a fixed monthly rent for the GPU plus the time of whoever runs it. The rent does not change whether the card sits idle or runs flat out. That makes the comparison against a pay-per-token API a break-even problem: divide the monthly rent by the blended price per million tokens of the API you would otherwise use, and the result is the number of millions of tokens a month (multiply by 1,000,000 for tokens) you must actually push through the box before owning the GPU is cheaper than renting tokens. Below that volume the API wins on money. The arithmetic, with the traps around idle time and batch size, is in GPU VPS versus API tokens: where the break-even sits.

On the appliance side the shape is different: a capital purchase, a permanent software license, electricity, and the same tokens-per-day sizing done for you at quote time. A quote sized for today's volume is also a ceiling. Growing past it means another quote, while a rented GPU is a plan change.

Who does the engineering

The appliance's pitch is that nobody does. Asked "Do we need developers on our side?", the vendor answers "No. You need the person who knows the process." That is the whole point. You still run a business process change, since staff must learn new tools and someone must upload the knowledge and write the phone menu, but no one has to know what a systemd unit is.

The rented path needs one person who can do all of the commands above without help, and then keep doing them. Concretely, that person owns the operating system updates, the Docker images, the firewall and TLS (transport layer security) certificates, the backups of the vector store and the chat history, the model updates, and the monitoring that tells them the GPU driver broke after a kernel update. Budget a day for the first install and a few hours a month after that. Then budget the real work: nothing on the rented path comes with a clients table, a supplier list, a calendar or a booking flow. Each of those is an integration you write against your existing systems, or an agent framework you configure and then defend when it does something odd. If nobody on staff wants that job, the "no developer" answer is worth more than any hardware spec.

Where the data lives

The appliance's strongest claim is physical. "Your data never leaves your building: no cloud, no sharing, no third-party access" describes a machine you can unplug from the network and still use. For a clinic or a law firm with a contract that says data stays on premises, that is the axis that decides, and no VPS matches it.

Say this plainly for the rented path: a VPS is a computer in someone else's datacenter. Your prompts, your documents, the model's answers and the vector index are processed in RAM on a host the provider owns, and they sit on a disk the provider can physically reach. "Private AI" on a VPS means private from the model vendor and from the public internet, and nothing more. Your hosting provider can still reach it, and a customer or an auditor who asks where the data is will get the name of a city rather than the name of a room in your building. Encryption at rest protects the disk if it is pulled. It does not protect what is in memory while a model is answering.

Even that much privacy is configuration, not a default. The Open WebUI command above publishes port 3000 on every interface, so its login page is on the public internet until you put it behind a private network or a reverse proxy, close sign-ups and set group permissions. TLS encrypts the connection; it does not keep strangers away. Open WebUI's sharing guide also notes that "The share dialog can also upload a chat to the Open WebUI Community site", so turn off Community Sharing in the admin settings, or set ENABLE_COMMUNITY_SHARING=false before the first start, if nothing may leave the server.

The middle position is your own hardware in a rack you rent, or a dedicated server nobody else shares. That keeps the model freedom and the monthly bill of the rented path while closing most of the physical gap. It also brings back the part the appliance removes: someone has to build the machine.

Power and space

A 6 kW machine is not an office PC. A standard wall socket in the United States is a 15 A or 20 A circuit; the server page asks for a 50 A circuit, which is what an electric range or a fast electric-vehicle charger uses, so an electrician is part of the install. Zanus's Airtight AI page, describing the same on-premises line, says instead that its servers run on "Standard AC circuits", "the outlets already in your building", so ask which applies to the configuration you are quoted. The site says the box is silent and office-friendly and only draws its peak while working. The idle draw is not published.

Electricity is the one running cost you can put a number on, because it is arithmetic. At 6 kW, every hour at full load is 6 kWh:

[
  {
    "label": "1 h/day at full load",
    "kwh_per_month": 180,
    "cost_usd_month": 27
  },
  {
    "label": "4 h/day at full load",
    "kwh_per_month": 720,
    "cost_usd_month": 108
  },
  {
    "label": "8 h/day at full load",
    "kwh_per_month": 1440,
    "cost_usd_month": 216
  },
  {
    "label": "24 h/day at full load",
    "kwh_per_month": "4,320",
    "cost_usd_month": 648
  }
]

A box that works one hour a day costs about 27 USD a month at 0.15 USD per kWh. One that runs flat out around the clock uses 4,320 kWh and costs about 648 USD. The vendor's own figure is "roughly $1/hour" at full load, which implies a somewhat higher tariff than the chart assumes, so use your own rate. All of that energy leaves the machine as heat, roughly 20,000 BTU (British thermal units) per hour at peak, which the room's air conditioning has to remove.

On the rented path, power and cooling are inside the rent, and the provider's datacenter carries the circuit. The trade is that you cannot see the meter: a GPU plan costs the same whether it works one hour a day or 24.

Model choice

The appliance ships with models chosen with you at configuration, from "the leading open-weight families", and the page says new weights are a download. The vendor's pages say the models are "installed and optimized by Zanus engineers" and "updated by Zanus engineers". Which families, how a swap is done inside Zanus OS, and whether a model outside the vendor's list can be loaded are not documented publicly, so ask before you sign.

The rented path runs anything with published weights and enough memory to hold them, once your inference server supports it. A new open-weight release is an ollama pull once it reaches the Ollama library, or a Hugging Face repository name passed to vLLM once vLLM supports its architecture, either natively or through its Transformers modeling backend. For the big families that often happens on release day, but it is not guaranteed, so check before you plan around a model that shipped this week. If you want a specific quantization or a fine-tune of your own, you import the GGUF file into Ollama yourself. The catch runs the other way too: you also own the evaluation. Nobody sized the model to your documents or your tokens per day, so the first month is spent finding out which model is good enough at which speed, and which quantization your memory can afford.

The private AI answering service: a module against a project

A lot of the traffic to "private AI server" is really looking for a phone receptionist, so treat that case on its own.

On the Zanus side, the phone agent is Front Office AI. Its plan list, as read on 8 October 2026, said it "Answers on the first ring, 24/7, 365", that "the caller speaks freely in any of 40 languages", and that "you choose the voice and the persona per function", with phone numbers and an IVR (interactive voice response) menu you set up. It is sold only as a hosted plan, from $329 a month as of 8 October 2026, and the vendor says the Front Office "runs in a private Cloudflare environment dedicated to your company" and "needs no server". No Front Office plan has an on-premises option: even the top plan, AI PRIVATE, is an isolated hosted environment, and the vendor points anyone who wants AI in their own building to its on-premises AI servers, "a separate product". Which speech models it uses and what its reply latency is are not published.

On the rented path, a voice agent is a separate project from the chat stack above, and a harder one. It needs four extra pieces: a telephony entry point (a SIP trunk, where SIP is the session initiation protocol, or a telephony API that hands you the audio), speech-to-text (STT), the LLM, and text-to-speech (TTS), all chained so that a caller hears a reply within about a second of finishing a sentence. Every link adds delay, so the models have to be small and the GPU has to be close. The STT and TTS halves, with the engines that run locally and how fast each one is, are in self-hosted speech-to-text and text-to-speech on a VPS. Expect the phone agent to take longer than the whole chat stack above, and expect the first version to interrupt callers. If the receptionist is the only thing you want, a hosted voice product, Zanus's own Front Office plans included, is the shorter road, and the chat server is a distraction.

The decision rule

Buy the box when all four are true: a contract or a regulator says the data stays in the building, nobody on staff will run Linux, you have or will fit a 50 A circuit, and the modules on the page match the work you actually do. The quote is the price of not having an engineer. Get the model list and the swap procedure in writing before you sign.

Rent and build when one person can own the server, the data may live at a hosting provider you have vetted, you want to choose the model yourself, and your usage is steady enough that a monthly GPU beats the token bill at the break-even above. You get any open-weight model your inference server supports, usually soon after it ships, and a bill you can change next month. You also get every integration as homework.

Use an API when usage is bursty or small, the data is not sensitive, nobody wants to run anything, and you need it working this week. Below the break-even volume it is cheaper, and it is always faster to start. Add a self-hosted layer later if the token bill or the data policy pushes you there.

FAQ

What does Zanus AI actually sell?

As of October 2026 zanusai.com describes three layers. Front Office AI handles phone, web chat, quotes and bookings, as hosted plans. Back Office AI is the company AI operating system, with "15+ modules" and, the vendor says, no developers needed. Private On-Premises AI, now listed under the Airtight AI name as a separate product, is the same software on Zanus hardware running "Zanus OS" inside your building, sold as fully owned and air-gap capable. The hardware is priced by RFQ. Its server page asks for a 50 A circuit and gives a 6 kW maximum draw. The company is headquartered in Pompano Beach, Florida.

How much does a Zanus AI private server cost?

There is no public price for the hardware. The server page says "Price by RFQ", sized on GPU memory and RAM, and on your tokens per day. The hosted Front Office plans ran from $329 to $2,495 a month, or $3,290 to $24,950 a year, as of 8 October 2026, but they are hosted subscriptions with no on-premises option, so they do not price the box. To compare, price the rented path with the same variables and work out the break-even against API tokens.

Can I build a private AI server on a VPS without a GPU?

Yes, for a small number of users and small models. A CPU-only VPS with 16 GB to 32 GB of RAM runs 7B and 8B models through Ollama at a few tokens per second, which is enough to test a document assistant. It is not enough for a team using it at once or for a voice agent, where reply time matters. Measure tokens per second on your plan before anyone depends on it.

Is a self-hosted LLM on a VPS really private?

It can be private from the model vendor and from the public internet, but only once you configure it that way: the firewall blocks port 11434, the chat interface is reachable only through a private network or a TLS reverse proxy with sign-ups closed and permissions set, and Open WebUI's Community Sharing is turned off so no one can upload a chat to the Open WebUI Community site. TLS encrypts the connection; it does not keep strangers away from the login page. The hosting provider is the exception: its staff can reach the disk, and its host runs the model in memory. If a contract says the data must stay in your building, a VPS does not meet it. Your own hardware, in your office or in a rented rack, does.

Does the do-it-yourself path include a phone receptionist?

Not out of the box. A voice agent is a separate project: a telephony entry point, speech-to-text, the LLM, and text-to-speech, chained tightly enough that a caller hears a reply in about a second. It is the hardest piece of the rented path and the one where a hosted voice product, Zanus's Front Office plans included, saves the most time.