---
title: "Deploy Evolution API | (Just Updated) WhatsApp REST API, No Upstream Telemetry"
description: "Every route you call is reported upstream by default. Not on this one."
category: "Bots"
url: https://railway.com/deploy/evolution-api-or-just-updated-whatsapp-r
---

# Deploy Evolution API | (Just Updated) WhatsApp REST API, No Upstream Telemetry

Every route you call is reported upstream by default. Not on this one.

**[Deploy Evolution API | (Just Updated) WhatsApp REST API, No Upstream Telemetry on Railway](https://railway.com/template/evolution-api-or-just-updated-whatsapp-r)**

Machine-readable deploy manifest (JSON, validated by TemplateCI): https://railway.com/deploy/evolution-api-or-just-updated-whatsapp-r/manifest.json

- **Creator:** SuperSlowSloth
- **Category:** Bots

## Template content

### postgres

- **Image:** postgres:17.10-trixie

### redis

- **Image:** redis:8.8.1-trixie
- **Start command:** `/bin/sh -c 'rm -rf /data/lost+found && chown -R redis:redis /data && exec docker-entrypoint.sh redis-server --requirepass "$REDIS_PASSWORD" --appendonly yes --appendfsync everysec --dir /data'`

### evolution-api

- **Image:** ghcr.io/bon5co/evolution-api-railway:v2.3.7
- **Health check:** /
- **Public domain:** Yes

## Documentation

# Deploy and Host Evolution API on Railway

Evolution API is the open-source WhatsApp REST gateway. Connect a number by scanning a QR code, then send and receive messages, media, and groups over plain HTTP — no Meta Business API approval, no per-conversation fees. This template deploys Evolution API with PostgreSQL 17 and Redis 8, each on its own persistent volume, **with the upstream telemetry call turned off**.

That last part is the reason this template exists. Deploy it and it asks you for nothing.

## About Hosting Evolution API

Evolution ships an Express middleware that fires on every request. For each call except `GET /`, it POSTs the route path, the API version, and a timestamp to `https://log.evolution-api.com/telemetry` — fire-and-forget, with failures swallowed. It is not message content, but it is a running record of which endpoints your gateway serves and when, sent off your infrastructure to a third party. The switch is `TELEMETRY_ENABLED`, and it defaults to on: the config reads it as "on unless explicitly set to something other than `true`", and the upstream image bakes `TELEMETRY_ENABLED=true` into its own `/evolution/.env`, which dotenv loads before anything else. So leaving the variable unset does not turn it off — it turns it on. No competing listing in this category sets it. The image this template deploys bakes it off.

The rest is the platform work Evolution needs on Railway and nobody in the category does. The API service has a **healthcheck**, so a boot that dies still fails the deploy instead of being reported as a successful one. The image is **pinned to a fixed upstream version**, which matters on an app that runs Prisma migrations forward on boot — a floating tag makes every redeploy an unrequested upgrade. Instance auth files live on a volume at `/evolution/instances`, so you scan each QR code once rather than after every deploy. Redis runs with append-only persistence on its own volume instead of as a disposable cache. PostgreSQL mounts its volume at `/var/lib/postgresql` and keeps `PGDATA` at the default subdirectory, which is what stops the ext4 `lost+found` from landing inside the data directory and blocking initialization.

Everything the platform needs is baked into the image (`ghcr.io/bon5co/evolution-api-railway`) rather than shipped as template variables you have to fill in, so the deploy form is empty. The API key is generated for you at 48 characters and the database and cache URIs wire themselves to the private services.

## Why Deploy Evolution API on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying Evolution API on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.

- **No telemetry call** — the route path of every API call is not reported to `log.evolution-api.com`, which is what stock Evolution does by default and what every other listing leaves on.
- **A healthcheck that can fail** — a broken boot fails the deploy instead of reporting SUCCESS with nothing serving.
- **Pinned, not floating** — a fixed upstream version, so a redeploy gives you the build you tested, not the next one.
- **Nothing to fill in** — the deploy form is empty; the API key and both connection URIs generate themselves.
- **Scan each QR code once** — instance auth lives on a volume, so redeploys don't disconnect your numbers.
- **Durable session cache** — Redis with append-only persistence on a volume, not a cache that empties on restart.
- **Private by default** — Postgres and Redis get no public domains; only the API is reachable, behind a 48-character key.

## Common Use Cases

- **Customer support automation** — bridge WhatsApp into your helpdesk, CRM, or n8n workflows, with the transcript retained.
- **Notifications and alerts** — deliver order updates, appointment reminders, or system alerts over WhatsApp at flat infrastructure cost.
- **AI chat agents** — put an LLM behind a real WhatsApp number and give it the conversation history to read.

## Dependencies for Evolution API Hosting

- A PostgreSQL 17 service with a volume mounted at `/var/lib/postgresql` (included in this template).
- A Redis 8 service with a volume mounted at `/data` (included in this template).
- A WhatsApp account to pair by QR code on first connection.

### Deployment Dependencies

- [Evolution API](https://github.com/EvolutionAPI/evolution-api) — upstream project (Apache-2.0)
- [Evolution API documentation](https://doc.evolution-api.com) — endpoint and integration reference
- [bon5co/evolution-api-railway](https://github.com/bon5co/evolution-api-railway) — the Railway-tuned wrapper image this template deploys, and what is baked into it
- [evoapicloud/evolution-api](https://hub.docker.com/r/evoapicloud/evolution-api) — the upstream image it is built from

### Implementation Details

Three services on Railway's private network:

| Service | Image | Volume | Public |
| --- | --- | --- | --- |
| `evolution-api` | `ghcr.io/bon5co/evolution-api-railway:v2.3.7` | `/evolution/instances` | yes |
| `postgres` | `postgres:17.10-trixie` | `/var/lib/postgresql` | no |
| `redis` | `redis:8.8.1-trixie` | `/data` | no |

The wrapper image also maps Railway's injected `PORT` onto `SERVER_PORT`, which is the variable Evolution actually reads for its listen port, and clears the ext4 `lost+found` from the instances volume so it doesn't appear as a phantom instance in the Manager UI.

Create an instance and get a QR code to scan:

```bash
curl -X POST https:///instance/create \
  -H "apikey: $AUTHENTICATION_API_KEY" -H "Content-Type: application/json" \
  -d '{"instanceName": "main", "integration": "WHATSAPP-BAILEYS", "qrcode": true}'
```

Scan the returned QR code from WhatsApp on your phone, then send a message:

```bash
curl -X POST https:///message/sendText/main \
  -H "apikey: $AUTHENTICATION_API_KEY" -H "Content-Type: application/json" \
  -d '{"number": "5511999999999", "text": "Hello from Railway"}'
```

List connected instances with `GET /instance/fetchInstances`. Requests without a valid `apikey` header are rejected. The Manager UI is served at `/manager`.


## Similar templates

- [Telegram JavaScript Bot](https://railway.com/deploy/5lRkWa) — A template for Telegram bot in JavaScript using grammY
- [Cobalt Tools [Updated Sep ’26]](https://railway.com/deploy/cobalt) — Cobalt Tools [Sep ’26] (Media Downloader, Converter & Automation) Self Host
- [Telegram Gateway](https://railway.com/deploy/railway-telegram-gateway) — Multi-bot Telegram webhook gateway with WebSocket event streaming

Open this page in a browser: https://railway.com/deploy/evolution-api-or-just-updated-whatsapp-r