Deploy and Host WAHA on Railway

WAHA (WhatsApp HTTP API) turns a WhatsApp account into a REST API and a webhook stream: send and receive messages, files, reactions and presence, manage multiple sessions, and drive it all from n8n, Make, or your own backend. It ships a dashboard and a Swagger UI, and no Meta Business approval is involved — you pair the number by scanning a QR code.

This deployment runs the NOWEB engine, which speaks to WhatsApp over a websocket instead of driving a headless Chromium, and keeps both the session store and the received media on a Railway volume.

About Hosting WAHA

Hosting WAHA means running one container that holds a live WhatsApp connection, storing its authentication state so the QR code does not have to be scanned again, and storing the media files it downloads from incoming messages. Three details decide whether a WAHA host behaves on a platform that redeploys containers routinely:

Which engine runs. The default WEBJS engine launches a real Chromium per session. Measured on one host with a single unpaired session (--memory 2g --cpus 2): 535 MiB resident with WEBJS against 342 MiB on the browserless NOWEB image. Railway bills memory by the hour, so this is the deploy's standing cost.
Where the files go. WAHA keeps sessions under WAHA_LOCAL_STORE_BASE_DIR and downloaded media under WHATSAPP_FILES_FOLDER. They are two different settings and both default to a path inside the image, so a volume mounted for one of them does not cover the other. Here both live under the /local volume.
What URL the webhooks carry. Every incoming file event contains a media.url built from WAHA_BASE_URL. If that points at an internal address, the automation on the other end cannot fetch the picture your customer just sent. This deployment derives it from the Railway public domain at boot.

The API key, the dashboard password and the Swagger password are generated per deployment, so the API, the dashboard and the docs are all closed to strangers from the first request — only /ping answers without credentials, because that is the healthcheck.

Common Use Cases

Sending order confirmations, delivery updates and appointment reminders to customers on WhatsApp.
Running a support or sales inbox through n8n, Make or a custom bot, with webhooks for every incoming message.
Bridging WhatsApp into an internal system — CRM, helpdesk, or an AI agent that answers on your business number.

Dependencies for WAHA Hosting

A WhatsApp account on a phone that can scan the pairing QR code.
A Railway volume for the session store and media (the template attaches one at /local).

Deployment Dependencies

WAHA documentation: https://waha.devlike.pro/
WAHA source and images: https://github.com/devlikeapro/waha
Railway wrapper image used here: https://github.com/bon5co/waha-railway

Why Deploy WAHA 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 WAHA 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.

After deploying

Open the deployment's WAHA_DASHBOARD_PASSWORD variable (user admin) and log into https:///dashboard.
Start the default session and scan the QR code with WhatsApp → Linked devices.
Call the API with the X-Api-Key header set to the generated WAHA_API_KEY, e.g. POST /api/sendText with {"session":"default","chatId":"@c.us","text":"hello"}.
Swagger UI is at / behind the same admin user with WHATSAPP_SWAGGER_PASSWORD.

The image is pinned to WAHA 2026.7.2. WAHA's session store migrates forward on new releases and a redeploy is routine on Railway, so the version does not move under a running WhatsApp login.