Evolution API hosting means running the unofficial open-source WhatsApp server yourself — Docker, Postgres, Redis, TLS — or paying a provider to run that same stack. Hosting buys uptime, upgrades and a public webhook URL. It does not buy anti-ban pacing or a history schema.
What does "Evolution API hosting" actually mean?
Evolution API hosting means one of two arrangements. You run the unofficial open-source WhatsApp server on your own VPS, or a provider runs that same server for you. A third thing people file under the term, Cloud API mode, is not hosting at all: it points the server at Meta's official channel.
Self-hosted on your own VPS. You rent a Linux box, run the image with Compose, connect Postgres and Redis, and terminate TLS in front so webhooks are reachable from the internet. You own uptime, updates, backups and the invoice.
Managed hosting. A third party runs the same open-source server and bills monthly per instance. There is no approval to obtain, because there is no first party to grant one. The trade is real: you give up the box and the egress IP, and you buy back your evenings.
Cloud API mode is a fork, not a third shape. Evolution API's documentation describes a Cloud API integration alongside its default Baileys mode (doc.evolution-api.com). That path sends through Meta's channel, which brings business verification, template approval and per-message billing. According to Meta's Cloud API pricing documentation, template messages are billed per message, while replies inside an open customer-service window stay free (developers.facebook.com/docs/whatsapp/pricing). The official route is not expensive at low volume. It is metered, which is a different property.
Evolution API is open source and unofficial, built on Baileys, the community WhatsApp Web library. Hosting it resembles hosting a linked phone more than hosting an API key. If you want the plain definition before the hosting decision, that is a separate post.
Is Evolution API official, and is there a hosted version?
No. Evolution API is a community project. No first-party hosted tier is offered by the project itself. Managed hosts are third parties running the same open-source stack, and Cloud API mode routes through Meta's official channel with its approval gates and metered billing attached.
Meta's Cloud API documentation sets out that gate plainly: opt-in from the recipient, and an approved template to open a conversation (developers.facebook.com/docs/whatsapp). Those two requirements, rather than a DNS record, are what official means in practice. They are also why this query exists at all. WhatsApp states on its own site that more than two billion people use the service (whatsapp.com), and that reach is what makes the approval path worth weighing instead of dismissing.
The Cloud API comparison prices the official route properly. For a managed host, two questions decide the deal before you migrate eighteen months of history: who holds the database, and what does an export look like.
What do you have to run to host Evolution API yourself?
You install Docker Compose, PostgreSQL, Redis, a TLS-terminating reverse proxy and the manager UI. According to its documentation, Compose is the supported deployment path, with Postgres as the store and Redis for cache and pub-sub. Optional brokers handle event fan-out. The running cost of that stack is whatever your provider charges today — pull the number from the provider's pricing page on the day you publish.
- Docker and Compose. The documented path. Running from source with Node works and moves dependency management onto you.
- PostgreSQL. Instances, chats, messages, contacts. Evolution API's documentation also lists MySQL as an alternative provider.
- Redis. Cache and pub-sub. On a small box it is the first component to exhaust memory, and when it does, the containers waiting on it restart with it.
- A reverse proxy with TLS. Nginx, Caddy or Traefik. Outbound webhooks need a stable public HTTPS endpoint or nothing downstream hears you.
- The manager UI. Instance creation, QR pairing, webhook configuration. Configuration, not daily operation.
- Optional brokers. SQS and RabbitMQ appear in documented production setups. Optional until you need fan-out across many consumers.
- Baileys. The community library the protocol layer depends on. Not affiliated with WhatsApp or Meta.
A minimal Compose sketch, not a complete install:
services:
api: { image: <evolution-api image>:<pinned-tag>, depends_on: [pg, redis] }
pg: { image: postgres:16, volumes: ["pgdata:/var/lib/postgresql/data"] }
redis: { image: redis:7, volumes: ["redisdata:/data"] }
volumes: { pgdata: {}, redisdata: {} }
Take the image name and tag from the current docs, and pin the tag. Env vars, ports and the proxy sit outside this sketch. An unattended latest pull is how a schema migration arrives at 2am without a snapshot behind it.
How much RAM and what VPS does Evolution API need?
There is no published formula, so treat any figure as a starting point to test rather than a specification. Practitioner guidance: 4 GB for a small deployment, 8 GB once you pass a handful of connected accounts. Memory tracks connected instances and retained history, not message volume alone.
A 2 vCPU / 4 GB plan fits a pilot: a few instances, modest history, one operator. An 8 GB class machine fits an agency running a dozen numbers, or anyone keeping long message history in Postgres rather than pruning it. Everything below that is a bet on never growing. Compare current list prices at the provider before you commit — Hetzner and DigitalOcean both publish theirs, and both change.
The dimensions that move the ceiling:
- Per-instance memory grows with connected accounts and retained history. Ten idle instances and ten busy instances are different machines.
- Postgres grows with your retention policy, a decision nobody makes on day one and everybody renegotiates on day 400.
- Webhook egress scales with inbound traffic. A busy number produces a lot of outbound HTTP, which costs sockets and CPU, not just bandwidth.
- Redis fails first on small boxes. The classic failure story: cache exhausted, containers restarted, sessions needing a re-pair.
Size for your busiest hour plus one restart. Warming new numbers is not optional, and no volume is safe immediately.
What does Evolution API hosting actually cost?
Self-hosting costs five lines: VPS, managed database if you want one, object storage for media, snapshots, and the hours of whoever owns it. The first four are tens of dollars a month at ordinary list prices. The fifth is larger and appears on no pricing page.
The lines, so you can price them yourself:
- VPS. A small droplet for a pilot; more memory as instances and history grow. Pull the current figure from your provider's pricing page and note the date you read it.
- Managed Postgres. Optional, and worth it if you would rather not own point-in-time recovery.
- Object storage. Media is where a WhatsApp store grows fastest.
- Snapshots. A small percentage of the disk bill, and the line everyone deletes until the first bad migration.
- Your hours. Install, upgrades, migrations, incident response, retention decisions. Unbilled, real, and the dominant term.
A flat licence states its own ceiling: SocialMate Pro is $99 a year or $10 a month, no per-message fee, starting at a safe 500 messages a day per account and scaling to 5,000 after 72 hours of warming. At that ceiling the marginal cost per message is zero. The licence page carries the numbers. For the general case, flat rate versus metered pricing works the arithmetic both ways.
None of this says self-hosting loses. With monitoring in place and evenings to spare, a small VPS plus sweat is genuinely cheap. It is only cheap if you count the sweat at zero.
What does hosting not solve?
Hosting gives you a running process and a reachable webhook URL. It does not give you ban-risk management, anti-ban behaviour, a history schema, a rehearsed upgrade path, or immunity from terms-of-service exposure. The distance between those five and a working deploy is the distance between having a WhatsApp API and having a WhatsApp system.
Ban risk is not a hosting problem. A VPS egresses from a datacenter range. A phone number's ordinary life happens on residential and mobile networks. Hosting changes where the process runs, not the reputation of the traffic leaving it. Bans are possible on every route in this article, SocialMate included; tooling can reduce risk and cannot remove it.
Anti-ban behaviour is yours to write. Evolution API is a transport and control surface. It sends, receives and reports. Pacing, warmup, duplicate suppression, per-number rate limits and risk scoring are not documented features of the image. "Self-hosted, therefore safer" is a category error: self-hosting changes who owns the server, not who owns the behaviour.
History and memory are your schema. Webhooks deliver events. What you retain, how you index it, and whether an agent can reconstruct a thread three weeks later is an application you build. Retention, full-text search, media caching and role-mapped transcripts are all downstream of decisions nobody makes in week one.
Updates are a standing obligation. Pin tags, snapshot the database, read release notes as change management. Whether instances survive a major upgrade is answered by a rehearsal on a copy, not by optimism.
Terms-of-service exposure does not move with the server. WhatsApp's Business Messaging Policy governs automated messaging on the platform (whatsapp.com/legal). Unofficial libraries are not authorised by WhatsApp, and the exposure is identical on a cheap VPS and an expensive one. If a number is already restricted, what self-hosting can and cannot change is worth reading before you redeploy.
How do you connect Evolution API to n8n or an AI agent?
Evolution API speaks REST and outbound webhooks, so n8n reaches it through HTTP Request and Webhook nodes. The conversation memory an LLM needs, meaning a role-mapped, token-windowed transcript, is a schema you build and maintain. Nothing in its documented deployment path is an MCP server either. A protocol is a surface, not a feature.
Three things make or break any agent route: a stable public URL for inbound triggers, a store that maps contact as user and you as assistant, and a transcript windowed to the model's context budget. Get those right and the model choice barely matters. Skip them and every workflow starts cold.
SocialMate ships that layer as product surface. A native n8n community node, n8n-nodes-socialmate, MIT licensed, version 2.7.0, open source at github.com/micbwilliam/n8n-nodes-socialmate, whose Get AI Context operation returns a whole thread in one call and whose every operation is exposed as an n8n AI-Agent tool. A native MCP server exposing 44 WhatsApp tools, so Claude Desktop, Claude Code, Cursor or Cline can act on WhatsApp directly. Two limits stated in the same breath: MCP is request/response with no inbound push, so an MCP-only client does not auto-reply on its own; and none of this is AI generation on our side, since AI replies, summaries and triage remain coming soon. Start at the n8n hub and the MCP guide, which names the number-one setup failure: the local API server is off by default.
VPS or your own machine: which is safer for the number?
Neither is safer by definition. A VPS buys uptime and a datacenter IP. Your own machine buys a residential IP and a computer that sleeps. Where the process runs is one input to risk, not the whole of it, and nobody can promise the second option is safe.
A residential connection removes a risk factor. It looks like normal use because it is normal use: the same network WhatsApp already associates with that number. That is a structural advantage, not immunity. On a VPS, Pro per-account proxy routing can restore residential or mobile egress through your own SOCKS5 or HTTP proxy. A proxy changes the network path only. It never bypasses rate limits or warming, and never lets you send faster.
The decision usually reduces to one question. If replies must land within minutes at 3am, take the VPS. If the number is commercially critical and volume is moderate, keep it at home and accept the downtime. Teams running both put the safety-critical number on the desktop and the always-on, lower-stakes number on the server. Desktop versus VPS covers that split in detail.
For the factual head-to-heads, read SocialMate vs Evolution API and SocialMate vs self-hosted APIs.
What ships if you want the API without building the rest?
SocialMate ships the parts this page treats as work you own: the anti-ban pipeline, local history, a flat licence and native agent surfaces. It is a different product from Evolution API, and the honest question is which half of the job you want to keep.
- Two deploys, same app. A desktop app for Windows, macOS and Linux that connects from your own residential IP, ideally the same home network as the phone that owns the number. Or SocialMate 2.0 headless on Linux via Docker image or systemd installer, managed from the browser console at
/admin. Docker is the option here, not the obligation. Persist the data volume, or the machine id rotates and the install drops to Free. - Flat licence, no meter. Free is $0 forever, no card, 200 messages a day on one account. Pro is $99 a year or $10 a month, no per-message fee. One licence includes one device; extra seats are $4/month each on monthly billing, about $40/year each on annual. Pro starts at a safe 500 a day per account and reaches 5,000 a day through High-Volume Mode after 72 hours of warming. Volume at that ceiling is worth reading before you plan around it.
- Anti-ban as engineering, not a checkbox. Randomised delays and jitter, pacing profiles (Safe/Balanced/Fast), per-number rate limits, session warming, a real typing indicator and read receipts before replying, an adaptive throttle that slows as risk climbs, a duplicate-content guard, live 8-factor risk scoring with cold-outreach detection, and risk-based auto-resume for cooled accounts.
- The agent surface, built rather than described. A native n8n node with scope-aware credential, action node and trigger node, every operation usable as an AI-Agent tool. A native MCP server with 44 tools. A local HTTP API with x-api-key auth that runs on Free for read endpoints, plain text send, quoted replies, reactions, mark-as-read and the typing indicator; Pro adds media, polls, locations, contact cards, group ops, the smart queue, scheduled messages, a stable named tunnel and unlimited webhooks.
SocialMate is independent and not affiliated with, endorsed by or partnered with WhatsApp or Meta. Automation can put a number at risk on any route, and this one is no exception. Read the self-hosting guide and the licence before you decide.
| Route | Meta approval | Pricing model | Ban / account risk | Anti-ban engine included | Egress network | History and search | AI-agent surface |
|---|---|---|---|---|---|---|---|
| Evolution API, self-hosted on your VPS | None. Unofficial Baileys protocol. | VPS invoice at your provider's current price, plus your unbilled hours. No per-message fee. | Restriction possible. No anti-ban tooling documented in the deployment path. | No documented anti-ban. You build pacing, warming, limits and scoring. | Datacenter IP. | Your schema. Full-text search is an application you write. | Your code: n8n HTTP and Webhook nodes, or your own MCP layer. |
| Managed Evolution API | None. Unofficial protocol. | Monthly per instance, priced by the provider. | Same protocol, same exposure. You do not control the egress IP. | No documented anti-ban. | Provider's IP. | Held by the provider. Ask for an export path before you buy. | Your code, hosted elsewhere. |
| SocialMate desktop (Windows / macOS / Linux) | None. No WhatsApp Business or Meta approval. | Flat licence: Free $0, no card; Pro $99/yr ($8.25/mo equivalent) or $10/mo. One device included; seats $4/mo. No per-message fee. | Restriction possible. Anti-ban engine plus a residential IP removes a risk factor. Not ban-proof. | Yes. Pacing, warming, duplicate guard, 8-factor risk scoring, auto-resume. | Your own residential IP. | Free: live only. Pro: full local cache, replay on reconnect, full-text search. | Native n8n node with Get AI Context; native MCP server, 44 tools. |
| SocialMate on a VPS (Docker or systemd) | None. | Same flat licence. No per-message fee. | Restriction possible. Datacenter IP unless Pro per-account proxy routes egress through your residential or mobile proxy. | Yes. Same pipeline, same limits. | Datacenter IP. Pro per-account proxy over SOCKS5 or HTTP. | Free: live only. Pro: same local cache and full-text search. | Same native n8n node and 44-tool MCP server. |
Deploy Evolution API on a VPS: the checklist after the tutorial
- Provision the box and the DNS record Take a Linux VPS sized for your busiest hour plus one restart, not your average day. A 2 vCPU / 4 GB plan is a reasonable starting point for a pilot. Point a subdomain at it, because webhooks need a stable public HTTPS host, not just the manager UI.
- Write the Compose file Services for the API image, PostgreSQL and Redis, with named volumes for the database and Redis data. Pin image tags rather than tracking latest, so an unattended pull cannot migrate your schema overnight.
- Put TLS in front Nginx, Caddy or Traefik terminating TLS and forwarding to the API port. Set the public base URL in the configuration so outbound payloads carry the right host, otherwise webhook targets silently receive requests for localhost.
- Snapshot before the first instance Take a database snapshot and schedule the next one. An empty database takes seconds to back up and a repairable one takes a restore you have already rehearsed.
- Pair an instance Create the instance in the manager UI over HTTPS, scan the QR from the phone that owns the number, and confirm the session shows as a linked device before you send anything.
- Prove webhook delivery Point a webhook at an echo endpoint outside your network and send a test message. If the echo never arrives, the fault is almost always the proxy or the public URL, not the application.
- Write the retention policy in week one Decide how long messages live in Postgres before the table decides for you. That is the decision nobody makes on day one and everybody renegotiates on day 400.
Frequently asked questions
Is Evolution API made by WhatsApp or Meta?
No. It is a community project built on Baileys, the open-source WhatsApp Web library, which is not authorised or supported by WhatsApp. There is no first-party support channel either: if an instance breaks, the repository's issue tracker is your escalation path. That absence of a vendor is the single fact that shapes every hosting decision on this page.
Do I need Redis, or can I skip it?
Redis is the pub-sub layer, so it matters most when more than one process needs the same events, such as a worker consuming message events separately from the API. Skip it on a single-container pilot and you will notice the moment you add a second consumer. It is also the first service to exhaust memory on a small box, so if you keep it, keep headroom.
How do I move an existing Evolution API install to a new server?
Dump Postgres, copy the Postgres and Redis volumes, and restore both on the new host before starting the API container. Sessions live in that credential store, so a restore that preserves it usually keeps instances paired; a restore that loses it means re-pairing every number by QR, which is exactly the kind of unpriced downtime this article keeps pointing at.
Can hosting Evolution API get my number banned?
It can. Restriction usually arrives as a session disconnect, a QR re-pair loop, or a number that can no longer complete a handshake, and because the protocol is unofficial there is no business relationship to appeal through. WhatsApp's Business Messaging Policy governs automated messaging on the platform (whatsapp.com/legal). Consent-first sending on a warmed number lowers risk. Nothing removes it.
Can I run Evolution API without Docker?
Yes. Install Node, clone the repository, build and run it against your own Postgres and Redis. What changes is upgrade management: no immutable image to roll back to, and no pinned tag to keep you on a schema you tested. If containers are the objection, choosing a product whose supported install avoids them is cheaper than maintaining a bespoke one.
Is self-hosted Evolution API cheaper than the Cloud API at 5,000 messages a month?
Run both sides. Meta's Cloud API charges per template message delivered, according to its published pricing documentation (developers.facebook.com/docs/whatsapp/pricing), so the bill rises with volume and stays near zero for replies inside an open service window. Self-hosting charges no per-message fee but adds a VPS bill and your hours. At low volume the official route usually wins. At high volume the flat side wins, provided you price the hours at something above zero.
How do I know whether my instance is being rate-limited or throttled?
Log the HTTP status and the failure mode rather than the send count. A 429 with a payload the queue can carry is recoverable; a disconnect with no error is a session problem, not a pacing problem. The two get treated identically by most in-house retry loops, which is how a reconnect storm turns a soft throttle into a lost number.
What is the actual difference between hosting Evolution API and a self-hosted app with anti-ban built in?
Scope of the build. Hosting hands you a transport and leaves pacing, warming, history, retries and the agent surface to you. A product like SocialMate ships those as behaviour: an anti-ban pipeline, Pro local history with full-text search, a native n8n node, a 44-tool MCP server, a flat licence. It is still unofficial, still unaffiliated with Meta, and bans remain possible on both routes.


