Self-Hosted AI Support Bot vs Hosted Chatbot SaaS: A Cost & Control Comparison

We run a small AI support bot on our own VPS. It answers product and pricing questions, streams replies into a browser widget, and uses a keyless model endpoint on the default path. People regularly ask whether they should do the same or just pay for a hosted chatbot. The honest answer is that the two are not the same product, and the subscription price is the least interesting difference.

This comparison deliberately contains no vendor price table and no benchmark numbers. Price lists expire, and a percentage without a controlled experiment is decoration. Instead, here are seven structural differences that decide what you actually pay — in money, in time, and in the number of things that can break at 2 a.m.

The short version

1. Who actually sends the invoice

A hosted subscription collapses several costs into one predictable line: the model calls, the widget, hosting, storage, and a margin. That predictability has real value if you need to forecast a budget or get a purchase order approved.

Self-hosted splits the bill. You pay for a server you may already have, and separately for whatever model endpoint you point at. The useful consequence is that the model is a swappable component, not a package. On our deployment the default path uses a keyless OpenAI-compatible endpoint; a paid provider key is an optional environment variable that changes answer quality, not the architecture. If one provider becomes unreachable from our region — which happened — we change a variable rather than renegotiating a plan.

The less useful consequence is that nobody aggregates the bill for you. If you add a paid key without caps, there is no plan tier to stop you. That is the single most common way a "cheaper" self-hosted bot becomes an expensive one.

2. What marginal cost looks like on each side

Hosted plans meter conversations, seats, or messages. The unit is legible. You can look at last month and know why the number changed.

Self-hosted meters tokens at the upstream, and the shape of that curve is entirely up to your code. What we shipped, after getting it wrong:

• Two independent daily caps, checked before the upstream call. A per-client allowance and a global ceiling. One global cap lets a single visitor drain the day's budget before lunch.
• Pre-check only on the routes that spend money. Ordinary page loads never touch quota state, so the visitor sees no difference.
• Graceful degradation instead of a hard error. When a cap is hit, fall back to a cheaper or keyless endpoint and let the knowledge base carry the answer. A modal on page load adds friction and recovers no revenue.
• Rate, turn, and input-character limits. All plain environment variables, no database. A standard-library counter with a timestamp is enough for a small site.

None of those exist unless you write them. A hosted product has them because the vendor's margin depends on them. That is the clearest argument for paying: you are buying someone else's guardrails.

3. Where your data sits

Our entire knowledge base is one UTF-8 text file. The system prompt, product facts, pricing language, and the "ask a human" fallback all live there. It is readable in any editor, diffable in git, and portable to another host by copying a file.

Hosted products give you an editor, revision history, team permissions, and often analytics on which questions were asked. For a support team of more than one person, that is genuinely better than a text file. The tradeoff is that your content and your conversation logs are in someone else's system, under their retention policy, and leaving means an export exercise.

One operational gotcha on the self-hosted side: if the KB is loaded into a module-level constant at process start, editing the file and reloading the browser changes nothing. Either restart the service after an edit or add a cheap mtime check. We chose the restart and documented it, because a single read is simpler than a cache invalidation strategy.

4. What happens when you hit the limit

On a hosted plan, hitting a limit is a commercial event: upgrade, buy an add-on, or wait for the window to reset. The behavior is defined by the vendor and is usually predictable.

On your own box, hitting a limit is a code path you own. Two decisions matter:

1. Order of operations. If you increment the trial counter before reading it, the first request of the day can be misclassified as over-limit. Write that as an explicit off-by-one test, not as a comment.
2. Degrade rather than lock. Switching to a slower-but-working model plus an honest upgrade line converts some visitors. A hard wall at request five converts nobody.

This is the part people underestimate. You are not just choosing where the code runs; you are choosing who designs the failure mode.

5. Getting paid is a separate system

A hosted product typically connects subscription, invoicing, tax handling, and entitlement in one flow. That is a real feature and a legitimate reason to pay.

On our site, payment is a static QR code. It collects money, but there is no callback, so a person activates access against the order reference by hand. Fully automatic activation needs a payment provider API, which normally means a business account and extra compliance work. For a low-volume side project, manual activation is fine. At volume, it becomes the bottleneck — and at that point the hosted option or a proper merchant-of-record integration is the cheaper answer.

We describe this openly because it is the most common oversell in "self-host and charge money" guides. Collecting payment and granting access are two different problems.

6. The operational surface

A minimal self-hosted deployment is smaller than most people expect:

one Python standard-library HTTP server on a loopback port
one systemd unit
one Caddy site block (with SSE buffering disabled)
one .env file, mode 600, excluded from deploy archives
one text file for the system prompt / knowledge base

No database, no queue, no container. The work is not in the number of components; it is in knowing their sharp edges. A reverse proxy that buffers responses turns your carefully sliced SSE events into one lump. A systemd Environment= line overrides the same key from EnvironmentFile=, so a signing key and a verification key can quietly come from different places and every HMAC check fails without a crash. Some keyless endpoints accept stream:true and return HTTP 200 while emitting no content deltas at all; requesting the full text with stream:false and slicing it server-side is the reliable workaround.

Each of those is a documented, fixed problem. Collect them and you have a maintenance manual. Skip them and you have a weekend.

7. When self-hosting is the wrong answer

Be honest about these four cases:

• You need automatic entitlement. Payment callback, plan upgrades, and revocation are a product, not a config flag.
• More than one person edits the answers. A text file with no review flow becomes a liability.
• Downtime has a real cost. If a broken widget during a campaign loses more than a year of subscription fees, buy the SLA.
• Nobody will own the box. A self-hosted service with no owner is a hosted service that nobody maintains.

The inverse also holds. If traffic is low, the questions are stable, you already run a server, and you want control over model choice and spend ceilings, self-hosting has a near-zero marginal cost and no vendor lock-in. That is the situation our own bot is in.

A decision tree that fits on a napkin

1. Do you need automatic payment activation, team roles, or an SLA? → Hosted.
2. Do you already have a VPS and terminal access, and is one person responsible? → Keep reading.
3. Are you willing to write and test spend caps before connecting any paid key? → Self-host. Otherwise → Hosted, because an uncapped key is worse than any subscription.