Best hosting for a WhatsApp chatbot deployment
Affiliate disclosure: Some sign-up links on this page are affiliate links. If you buy through them, we earn a commission at no extra cost to you. Recommendations are based on workloads we’ve actually deployed.
A WhatsApp Business API bot doesn’t need a fancy host — but it does need the right kind of one. The hosts that fail in production aren’t the “cheap” ones; they’re the ones that don’t play well with persistent connections, queue workers, and webhook bursts.
What a WhatsApp bot actually does to your server
From the host’s perspective, your bot has three loads:
- Inbound webhooks from Meta. Spiky. A campaign send can fire 5–50k webhooks in a minute. Your endpoint needs to ack within seconds or Meta retries.
- Outbound API calls. CRM sync, OpenAI/Anthropic for intent, your DB. Per-message latency adds up.
- Background workers. Cron, retries, scheduled nudges. These need to keep running without HTTP traffic.
Every “why is the bot slow / dropping messages” ticket we’ve handled traces back to one of those three.
What to look for in a host
- Persistent processes. Your Node.js or Python app needs to stay running. Shared hosting that “supports Node” usually means CGI-style, which dies between requests. Avoid.
- Background workers. A way to run a queue consumer or scheduler outside the HTTP path. Either dedicated worker dynos (Render/Railway/Heroku-style) or a VPS where you manage it yourself.
- Predictable webhook latency. p95 ack time under 500ms during normal load. Slow ack causes Meta retries, retries cause duplicates, duplicates cause angry customers.
- A nearby region. Webhooks come from Meta’s edge; pick a region close to your users and to your DB.
- Easy rollback. When you ship a bad release at 11pm, the difference between a 30-second rollback and a 30-minute one matters.
What to skip
- Pure shared hosting. Fine for a marketing site. Wrong tool for a webhook receiver.
- Serverless-only setups (for the bot core). Cold starts hurt webhook latency. Serverless is fine for fan-out, scheduled jobs, or sidecars; less fine for the main webhook endpoint at low-to-medium traffic.
- Hosts with no SSH or no log streaming. When a customer says “the bot ignored me at 3:14pm,” you need logs immediately, not via a support ticket.
Our picks by stage
Just launching, <5k messages/day
A small VPS is enough. Hostinger’s KVM 2 plan (2 vCPU, 8 GB RAM, ~$7–9/mo) handles this comfortably. Run your Node app behind PM2 or systemd, Postgres on the same box, Redis for sessions. Ship it.
Growing, 5–50k messages/day
Move Postgres to a managed service (Neon, Supabase, or RDS). Keep the bot on KVM 4 (4 vCPU, 16 GB RAM) or step up to a managed PaaS like Render or Railway if you want zero ops. Add a separate worker process for retries and scheduled sends.
Scaling, 50k+ messages/day, multi-region users
You’re past “cheap host” territory. AWS / GCP with a load balancer, autoscaling group, managed Postgres, Redis, and a real queue (SQS or RabbitMQ). Consider regional bot instances if you serve users across continents.
What we deploy ourselves
For client work, we typically split into two camps:
- Cost-conscious clients — Hostinger KVM VPS + managed Postgres + Cloudflare in front. ~$15–30/mo all-in for a real production bot.
- Compliance or scale-conscious clients — AWS Mumbai, ECS Fargate or EC2, RDS, ElastiCache. Higher floor cost, but every part of the stack maps to an AWS-native service when audit time comes.
Both work. The choice is about what your team can operate, not what’s “best.”
The boring stuff that actually matters
- Idempotency. Meta retries webhooks. Your handler must dedupe by message ID.
- Ack first, work later. Return 200 to Meta in <200ms; push the actual work to a queue.
- One restart shouldn’t lose state. Sessions in Redis, not in process memory.
- Health checks that mean something. “Process is up” isn’t enough — check DB, Redis, and Meta API reachability.
Building one and not sure how to size the host? Tell us about your traffic — we’ll come back with a stack and a number.