Self-hosted Chat Server
Private vs Public Cloud for Chat and AI: Cost, Control, and Compliance
In 2020, the private-vs-public cloud question for a chat product was mostly about ops burden. Public cloud won by default – you got managed databases, auto-scaling WebSocket servers, and a monthly bill that grew predictably with users.
The era of large language models changed it. In 2026, a moderately active chat operates a vector store for RAG, invokes an LLM API at each AI-assisted interaction, retains message embeddings, and produces egress traffic billed by the gigabyte to a public cloud provider. AWS egress from EC2 to the internet starts at $0.09/GB after a 100 GB free tier. A chat product with 500K MAU and active media sharing can hit 5-50 TB of monthly egress – that’s $450-$4,400/month in network fees before any compute or storage. Layer in LLM API costs and a self-hosted chat server on dedicated cloud starts looking more attractive than it did three years ago.
This article walks through the four cloud deployment models – public cloud, private cloud, hybrid, and multi-cloud – applied specifically to chat and AI workloads, with real cost math you can model against your own numbers and a decision framework based on MAU, LLM spend, and compliance posture.
In this article
- The 4 cloud deployment models for chat + AI
- Public cloud: when it wins
- Private cloud: when it wins
- When private cloud is the wrong pick
- Hybrid cloud: the 2026 default for regulated teams
- Multi-cloud: usually a bad idea
- Decision framework Ethora: same API across all deployment models
The 4 Cloud Deployment Models for Chat + AI
The first deployment models that come to mind are usually private and public clouds, but there are two more approaches. Let’s consider all four.
Public cloud
Multi-tenant infrastructure on AWS, Azure, GCP, or OCI. You run your chat server as a container on ECS, EKS, or equivalent, and call LLM APIs (OpenAI, Anthropic, Azure OpenAI) over HTTPS. No hardware to manage, full elasticity, and you’re invoiced for what you use. The costs are individually small but compound at scale – compute, storage, egress, API tokens, and managed service fees each add a line to the bill.
Private cloud
Single-tenant infrastructure, one of the three models: own hardware in a colocated data center; dedicated tenancy in a public cloud (AWS Dedicated Hosts, Azure Dedicated Hosts); or a sovereign cloud in Europe with dedicated tenancy (OVHcloud dedicated, Scaleway, IONOS). You have a self-hosted chat service, and if appropriate, self-hosted LLM inference on your own GPU hardware. It provides you with maximum control over data residency, but also entails higher operational burden.
Hybrid cloud
User-facing services – WebSocket gateway, CDN, auth – on public cloud for elasticity. Sensitive data, message storage, RAG corpus, and LLM inference on private cloud or on-premises. The fastest-growing deployment pattern in healthcare and financial services in 2025-2026, because it captures the elasticity benefit where it matters (traffic-facing layers) without putting regulated data on shared infrastructure.
Multi-cloud
The same workload spread across AWS, Azure, and GCP simultaneously, ostensibly for vendor risk reduction. The theory is sound; the economics are usually not – egress fees between clouds are real, and a busy chat stack routed across three providers spends 25-40% more on network than on compute. There are legitimate use cases covered below, but using “reduce vendor lock-in” as the primary motivation is an expensive way to obtain insurance you might not need.
Public Cloud for Chat + AI: When It Wins
Public cloud is the right default for most teams that aren’t yet at the scale or compliance threshold where the economics flip. The question is knowing where those thresholds are, because they’re lower than most teams expect once LLM costs come into play.
Realistic public cloud costs at 100K MAU
These are built from current published pricing as of mid-2026, directional for a chat app with moderate AI usage – roughly 10 AI-assisted interactions per active user per month:
| Component | Monthly cost (100K MAU) | Basis |
| Chat SDK managed service | $500-3,000 | Some SDKs published starter tiers |
| LLM API (GPT-4o-mini) – ~10M tokens/day | ~$1,400 | $0.15/1M input tokens; 10M tokens/day × 30 days |
| Vector store (Pinecone/Weaviate managed) | $200-1,000 | Vendor published tiers – directional |
| Compute + database (AWS/Azure) | $500-2,000 | Directional based on typical 3-node cluster sizing |
| Egress – media + API responses | $50-500 | $0.09/GB first 10 TB – low at this MAU |
| Total | $2,700-8,000/month |
At 100K MAU, that’s a manageable number – below the point where private cloud’s fixed costs (ops labor, dedicated hardware) undercut it. What changes the math is LLM spend growing faster than MAU, egress growing with media volume, and compliance requirements arriving from a new enterprise customer.
Where public cloud breaks down for chat + AI
Three specific thresholds are worth modeling before you sign a long-term commitment with a managed chat service or an LLM provider:
LLM token spend exceeds roughly $5-10K/month. At that point, the compute cost of running Llama 3.3 70B on dedicated GPU hardware begins to approach parity with API costs, without the per-token markup. A 4× A100 80GB node runs $1.49-2.06/GPU/hour from RunPod or Lambda Labs – A100 80GB rates from specialist providers in mid-2026 run $1.49/hr at RunPod to $1.99/hr at Lambda Labs. A 4-GPU node at $6/hour runs ~$4,300/month and serves 100–500 concurrent conversations at strong quality. The breakeven against cloud LLM API calls is around 20-30M tokens/month depending on your mix of input and output.
Egress fees exceed $5K/month. AWS charges $0.09/GB for the first 10 TB of internet egress, dropping to $0.085/GB for the next 40 TB. A chat product with 1M MAU and any meaningful media sharing can hit 50-100 TB/month – that’s $4,400-$8,500/month in egress alone before compute or storage. At that scale, running the chat server in a private cloud or colocated data center with flat-rate bandwidth becomes the cheaper option.
Compliance requires customer-managed keys (CMK), data residency, or air-gapping. Public cloud multi-tenant services are typically disqualified for any customer contract requiring on-premises deployment, and HIPAA situations where a vendor BAA covers the API but not the underlying infrastructure. “AWS Frankfurt” doesn’t satisfy procurement at many European public sector buyers.
Public cloud TOS and PHI
Most public LLM API terms of service require a separate Data Processing Agreement (DPA) or Business Associate Agreement (BAA) before any protected health information can touch the model. OpenAI Enterprise and Anthropic both offer this. The standard developer API does not cover PHI. Check the DPA before deploying any HIPAA use case on a public LLM API.
Private Cloud for Chat + AI: When It Wins
The term “private cloud” covers meaningfully different things, and the distinction matters for cost planning. On-prem colocated hardware you own is very different from dedicated tenancy on AWS Outposts, which is different again from a European sovereign cloud like OVHcloud or Scaleway dedicated. All three deliver single-tenant isolation; the ops burden and the upfront capital profile are quite different.
The self-hosted chat server case
A self-hosted chat server means running the chat backend – message routing, WebSocket management, presence, push delivery, storage – on infrastructure you control. Options span a range: open-source platforms for team-chat use cases; commercial chat SDKs with a self-hosted tier for embedded product chat. Deployment is typically Docker Compose for small teams, Kubernetes for production scale.
The compliance case for a self-hosted chat server is cleaner than the cost case at lower scales. A HIPAA-compliant chat API deployment that needs to satisfy a BAA, keep message content inside a specific data center, and survive a third-party audit can point to the specific servers the data lives on – something a managed multi-tenant service can’t provide with the same specificity. For HIPAA chat and fintech deployments, that specificity is often exactly what compliance and legal teams need.
The self-host LLM case
Running a private LLM on your own GPU infrastructure – what people mean when they say on-premises LLM or private LLM for enterprise – has gotten materially more accessible in 2026. Llama 3.3 70B is available on Hugging Face under a permissive license. A 4× A100 80GB node using vLLM for production inference serves 100-500 concurrent conversations, handles 4-bit quantized Llama 3.3 70B cleanly, and at $1.49-2.06/GPU/hour from RunPod or Lambda Labs costs roughly $4,300-6,000/month all-in. That’s the breakeven comparison to make against your actual LLM API bill.
The operational requirement is real. Running a self-hosted AI chatbot on GPU infrastructure means someone on your team is responsible for model updates, vLLM version management, monitoring, and on-call when inference latency spikes at 2 am. That cost is not in the GPU hourly rate – it’s 0.2-0.5 FTE of platform engineering time, which at mid-market engineering compensation is $3,000-8,000/month in loaded cost. Factor that into the breakeven calculation.
Realistic private cloud costs at 100K MAU with moderate AI
| Component | Monthly cost | Basis |
| Self-hosted chat server (3-node k8s, EU sovereign cloud) | $800-2,000 | Directional – OVHcloud/Scaleway dedicated instances |
| Self-host LLM (4× A100 80GB, RunPod/Lambda) | $4,300-6,000 | $1.49–2.06/GPU/hr × 4 GPUs × 720 hrs |
| Self-hosted vector store (pgvector on PostgreSQL) | $300-800 | Directional – included in k8s cluster or separate node |
| Internal bandwidth (no egress tax) | $100-400 | Flat-rate bandwidth typical on dedicated EU cloud |
| Ops allocation (0.3 FTE platform engineer) | $3,000-5,000 | Directional – loaded compensation estimate |
| Total | $8,500-14,200/month |
At 100K MAU, private cloud runs more expensive than public cloud – the ops labor cost dominates at low scale. At 500K MAU with heavier LLM usage (50M+ tokens/month), the comparison flips: the public cloud LLM API bill alone starts exceeding the private cloud total.
These are cases when private cloud is the clear right pick:
- LLM API spend is approaching $10K/month and growing with usage
- HIPAA-compliant messaging API requirements where a BAA covers the API but not the shared infrastructure underneath
- EU AI Act high-risk AI classification (insurance underwriting, credit scoring, healthcare triage) requiring human oversight and specific documentation obligations under Article 13-14
- Customer contracts that explicitly require on-premises or sovereign cloud deployment
- Traffic above 500K MAU with predictable load – private cloud pays for capacity but stops paying egress taxes
- European public sector procurement where “EU sovereign cloud” is a stated requirement
But sometimes, private cloud may not work for you.
When private cloud is the wrong choice
The private cloud enthusiasm in compliance-heavy industries occasionally overshoots. There are situations where the overhead of a self-hosted chat server and self-hosted LLM costs more than it saves, even for regulated deployments.
Teams with fewer than 5 engineers and no dedicated DevOps. The ops burden of running a self-hosted chat server alongside a private LLM deployment will consume engineering bandwidth that would be better spent on the product. Every hour your CTO spends debugging vLLM OOM errors on a Saturday is an hour not spent on whatever actually differentiates your product.
Highly spiky traffic without a high floor. Public cloud auto-scaling handles 10× diurnal traffic spikes without paying for the peak capacity 24 hours a day. Private cloud infrastructure is sized for peak – if your chat product spikes during events and sits mostly idle otherwise, you’re paying for peak capacity every hour of every month.
Pre-product-market-fit. If you’re still iterating on the product and don’t know where the usage patterns will settle, the inflexibility of private cloud infrastructure is a liability. Move to private cloud after you know your traffic shape and have compliance requirements that genuinely require it.
When your model quality requirement is frontier-class. No open-weights model as of mid-2026 matches GPT-4o or Claude Opus 4.7 on complex reasoning and nuanced instruction following. If your use case requires that quality ceiling – legal document analysis, medical reasoning, complex code generation – you’re using a cloud API regardless of where everything else lives.
Hybrid Cloud: The 2026 Default for Regulated Teams
Hybrid cloud for chat and AI isn’t a compromise position – it’s the architecture that most regulated teams are settling on because the workload splits naturally. User-facing layers (WebSocket gateway, CDN, auth, push notifications) benefit from public cloud elasticity and global edge. Sensitive data (message content, PII, RAG corpus, LLM inference for regulated queries) benefits from private cloud control and data residency certainty. Running both simultaneously captures both benefits.
Reference architecture
User-facing WebSocket and REST gateway on public cloud with auto-scaling. Message content encrypted end-to-end in transit and stored in a private cloud database with customer-managed keys. RAG vector store in the private cloud, co-located with the data it indexes.
LLM inference split by query sensitivity: a self-hosted AI chatbot on private cloud GPU for regulated queries (those touching PHI or financial data), a cloud LLM API with a signed DPA for lower-sensitivity interactions where model quality justifies the API cost. Auth and identity on a public cloud IDP (Auth0, Okta) with sensitive attributes proxied through the private layer rather than stored in the IDP.
The cost profile
Hybrid is typically 15-30% more expensive than pure public cloud at low scale – the integration layer between public and private legs adds both engineering and infrastructure cost. It’s 20-40% cheaper than pure public at large scale, because the high-volume components (LLM inference, message storage) move off the per-unit public cloud pricing and onto flat-rate private infrastructure. The rough breakeven sits around 50K MAU with significant LLM usage – around 20M tokens/month – for a typical regulated SaaS product.
The operational risk
The boundary between public and private legs is where things break. A network round-trip from the public gateway to the private RAG store adds latency to every AI-assisted response. If the private link degrades, does the chat fail gracefully or collapse entirely? Design the failure modes explicitly: if the private LLM is unreachable, should the system fall back to the cloud API, refuse AI-assisted responses, or fail the whole interaction? Each choice has different implications for compliance, user experience, and cost. Test it before launch, not after an incident.
Multi-Cloud for Chat + AI: Usually a Bad Idea
Multi-cloud – the same workload spread across AWS, Azure, and GCP simultaneously – is sold as vendor lock-in insurance. The egress fee reality is that it often costs more than the risk it hedges against.
The number to know: AWS charges $0.09/GB for internet egress; Azure charges $0.087/GB; GCP charges $0.12/GB. Traffic between clouds goes out of one provider’s network and into another’s, triggering the full egress rate on every cross-cloud call. A chat message that originates in AWS, triggers a RAG lookup in Azure, and gets an LLM response from GCP pays three egress charges. At meaningful chat volume, this compounds into a significant network cost that has nothing to do with the actual computation being done.
When multi-cloud does make sense for a chat stack: geographic reach where one provider dominates a specific region (AWS US East + Alibaba Cloud APAC, for example, where Alibaba covers latency requirements in China and Southeast Asia that AWS can’t match). Strict data-residency geo-fencing where EU message data must stay on EU infrastructure and US message data on US infrastructure, using two different providers rather than one. Those are legitimate. “We don’t want to be locked into one vendor” isn’t – the lock-in risk is mitigated much more cheaply by using portable standards (Kubernetes, PostgreSQL, S3-compatible object storage) and having a documented migration plan, rather than paying double the network costs to run everywhere simultaneously.
Pick Your Deployment Model
| Under 10K MAU, MVP or pre-product-market fit | Public cloud managed chat + cloud LLM API |
| 10K–100K MAU, standard SaaS, no hard compliance | Public cloud. Watch LLM spend monthly; model the breakeven at current growth rate |
| 100K–500K MAU, LLM spend growing toward $10K/month | Self-host LLM on dedicated GPU; keep chat on public cloud. Hybrid pattern |
| 500K+ MAU, predictable load, high LLM volume | Private cloud for chat + self-hosted LLM. Unit economics dominate |
| Any size + HIPAA or EU AI Act high-risk AI | Private or hybrid. LLM + sensitive data on private; user-facing layer on public with DPA |
| Any size + customer contracts require on-prem | Private cloud with self-hosted chat server + self-hosted LLM |
| European public sector or national security | EU sovereign cloud (OVHcloud, Scaleway, IONOS) with dedicated tenancy |
| Egress fees exceeding $5K/mont | Model the full private cloud cost – you may already be past breakeven |
The default rule
Start on public cloud until you hit either a compliance floor or a $10K+/month LLM/egress ceiling. One of those will arrive before the other depending on your vertical and growth rate. When it does, the hybrid or private migration is much easier if you’ve avoided vendor-specific managed services and used portable open standards throughout.
Ethora: Same API Across All Deployment Models
The deployment model question matters less when the software doesn’t change as you cross it. Most chat SDKs lock you into their managed cloud service – the self-hosted option, where it exists, requires a different API surface, different documentation, and sometimes a different team at the vendor to talk to. Migrating from managed to self-hosted when your compliance situation changes is then a partial rewrite rather than a config change.
Ethora’s chat SDK with self-hosted LLM AI agent uses the same API surface whether you’re on Ethora’s managed cloud or running a self-hosted chat server on your own Kubernetes cluster. Start on managed cloud for the MVP, move to a self-hosted chat server on AWS when you need dedicated tenancy, and move to on-premises when a customer contract requires it – without changing the application code. The LLM endpoint is a config value: OpenAI or Anthropic for early-stage, self-hosted Llama 3.3 70B when the token costs justify it.
For compliance cases, Ethora supports end-to-end encryption, audit logging, and everything to stay compliant with regulations, whether you operate in healthcare, finance, or other highly regulated industries.
If you’d like to learn more about how Ethora can help your case, drop us a line. Our experts will guide you through the whole process of building a 100% HIPAA-, FINRA-, or GDPR-compliant chat.
More Articles
AI SDK
Oct 19, 2026
I built a 3D world from a book on Ethora in a weekend
A weekend project: public domain books turned into walkable 3D worlds where every room is an Ethora chat and every character an AI agent. The build log, the costs, the 19 things Ethora should do better, and what the team said.
AI SDK
Oct 19, 2026
Best AI Chatbots for Websites in 2026: 10 Options Compared
We compared 10 AI chatbots for websites on free plans, pricing, training on your own content, model choice, human handoff and self-hosting. October 2026.
Try Out Ethora in Action
Experience Ethora's messaging with a dedicated demo from our CEO or start building your App right now!