Whatomate: a self-hosted WhatsApp Business Platform with voice calling and multi-tenancy

What it is, and what it wraps

Whatomate is a modern, open-source WhatsApp Business Platform, shipped as a single binary app, and the project description is simply an open-source WhatsApp integration.

The starting point matters. This is not a WhatsApp client, it is a business platform built on Meta's WhatsApp Business API. The feature list says it directly: WhatsApp Cloud API Integration, connect with Meta's WhatsApp Business API for messaging. Everything else in the product is a layer on top of that: real-time chat over WebSocket, template management for messages approved by Meta, bulk campaigns with retry support for failed messages, a chatbot engine, and analytics.

Two of those features are unusual enough to call out.

Voice calling and IVR is the first: incoming and outgoing WhatsApp calls with IVR menus, DTMF routing, call transfers to agent teams, hold music and call recording, with its own documentation page under features/calling. A DTMF keypad and call recording inside a chat platform is a telephony feature set, and the Go dependencies confirm it, with pion/rtp and pion/webrtc for the media path.

The second is multi-tenancy with granular roles. Support for multiple organizations with isolated data and configurations, and customizable roles with fine-grained permissions, where you create custom roles, assign specific permissions per resource, users, contacts, templates and so on, and control access at the action level of read, create, update and delete. Super admins can manage multiple organizations. That is a SaaS control plane on top of a business API, and it is the part that separates this from a webhook receiver.

The project is AGPL-3.0 licensed, the homepage is whatomate.io, the last push was on 2026-10-14, and the recent releases are v0.1.1-beta-0.17 from 2026-09-01, v0.1.1-beta-0.16.1 from 2026-06-17 and v0.1.1-beta-0.16 from 2026-06-13. The beta tags are on a 0.1.1 version, which tells you how early this is.

Three ways to run it, and the compose file that does the work

The Docker path is the documented one, and it downloads three files before you run anything:

# Download compose file, sample config, and env file
curl -LO https://raw.githubusercontent.com/shridarpatil/whatomate/main/docker/docker-compose.yml
curl -LO https://raw.githubusercontent.com/shridarpatil/whatomate/main/config.example.toml
curl -L https://raw.githubusercontent.com/shridarpatil/whatomate/main/docker/.env.example -o .env

# Copy and edit config
cp config.example.toml config.toml
# Edit .env to set PostgreSQL credentials and timezone

# Run services
docker compose up -d

So the compose file, a sample TOML config and an env template all come from the repository, and the instruction is to edit the .env to set the PostgreSQL credentials and the timezone. The image is published on Docker Hub as shridh0r/whatomate:latest.

The binary path skips Docker entirely:

# Copy and edit config
cp config.example.toml config.toml

# Run with migrations
./whatomate server -migrate

And the source path is a clone, a make target and the same server command:

git clone https://github.com/shridarpatil/whatomate.git
cd whatomate

# Production build (single binary with embedded frontend)
make build-prod
./whatomate server -migrate

In all three cases you end up at http://localhost:8080 and log in with [email protected] and the password admin. Those are the default credentials, and the README prints them in every install path, so changing them is the first thing to do.

The -migrate flag is worth understanding. It runs the database migrations on startup, and the project uses GORM with the PostgreSQL driver, so the schema is created from the Go models. That is convenient and it is also a reason the binary needs a reachable database before it will start.

The CLI separates the API process from the workers

The command set is small, and the design decision is in the flags:

./whatomate server              # API + 1 worker (default)
./whatomate server -workers=0   # API only
./whatomate worker -workers=4   # Workers only (for scaling)
./whatomate version             # Show version

The server process serves the API and runs one worker by default. Setting -workers=0 gives you an API process with no workers, and the worker command runs workers only, with a count you choose. So the two roles can be run in one process, or split across processes and scaled independently.

That split is what makes the compose and production deployments work, and it maps onto what the application actually does. The API serves the dashboard and the WebSocket connection for real-time chat. The workers do the background work, and the background work in a WhatsApp platform is the part that grows: sending campaign messages with retry for failures, and handling the inbound webhooks from Meta.

A single-worker default is a sensible default for a first run, and -workers=0 is what you would use when you want the API to respond promptly without competing with outbound message sending for the same database connection pool.

The rest of the CLI is version, which is worth having in a service that gets deployed as a single binary and reports its own version and build time.

The build, the stack, and what the dependencies reveal

The backend is written in Go using Fastglue, the Zerodha framework, and the frontend is Vue.js 3 with shadcn-vue. The build is a Makefile with a Makefile target set that covers build, build-prod, run, test, clean, the docker targets, migrate, and the frontend targets.

The production build target is where the single binary comes from. build-prod depends on frontend-build and embed-frontend, and the embed step copies frontend/dist into internal/frontend/dist so the compiled assets are inside the Go binary. The build then runs with CGO_ENABLED=0, which produces a static binary, and the linker flags strip symbols with -s -w and set main.Version and main.BuildTime from git describe and the current UTC time. The version falls back to the string dev when there is no tag, which is a sensible default for a local build.

The Go dependencies describe the architecture more clearly than the README does.

The HTTP stack is fasthttp, with fasthttp/websocket for the real-time chat, and the framework is fastglue with logf for logging. Configuration is koanf, with the TOML parser and both the env and file providers, which is how config.toml and the .env file end up feeding the same configuration. Persistence is GORM with the Postgres driver, and Redis is there via go-redis, which is the usual home for job queues and WebSocket fan-out.

Then there are the parts specific to the feature set. pion/rtp and pion/webrtc/v4 are the media stack for the calling feature. goja is a JavaScript interpreter, and paired with expr-lang/expr, it is how the chatbot engine evaluates its own logic, since a chatbot with conversation flows and branching needs to run expressions and, in some designs, scripts. golang-jwt/jwt/v5 and golang.org/x/oauth2 handle tokens, the AWS SDK v2 with S3 handles file storage, and uuid and crypto round out the utility set.

The module targets Go 1.26.0.

What to weigh before running this in production

The first limitation is the dependency on Meta. You need a WhatsApp Business API account, a phone number, and approved message templates before any of this is useful, and template approval is a process with Meta rather than something the software can automate. The platform's own template management feature assumes the templates already exist on Meta's side.

The second limitation is the beta line. The releases are v0.1.1-beta-0.17 and the version is 0.1.1, so the product is pre-1.0 and shipping beta tags. The last release was in September 2026 while the repository was pushed to in October, so the branch is moving faster than the tags.

The third limitation is the default credentials. Every install path in the README ends with the same [email protected] and admin login, and the dashboard is exposed on port 8080. Changing that and putting it behind TLS is not optional.

The fourth is the AGPL-3.0 licence. For a self-hosted service on your own infrastructure this is mostly a non-issue, but if you plan to modify it and offer the result as a service, the copyleft obligations of AGPL are broader than MIT or Apache and you should read the LICENSE file before you build on it.

The fifth is operational. The application needs PostgreSQL, and depending on your configuration Redis, and the Go process running migrations on startup, and the WhatsApp media path in a calling feature that needs a public address to receive webhooks and calls. That is more moving parts than a chat dashboard, and the compose file exists because the alternative is worse.

The project asks contributors to read CONTRIBUTING.md first, and there is a crowdin.yml at the top level, which means the interface is translated through Crowdin rather than by hand.

Editorial conclusion

Whatomate fits a team that already has Meta WhatsApp Business API access and wants to run the platform itself rather than rent it, and that needs voice calling or a chatbot layer on top of the API. It is a poor fit if you do not have a Business API account, since the whole application is a client of that API, and it is a poor fit for a production deployment that needs the service to be genuinely finished, because the release line is still on beta tags. Before adopting, read the configuration documentation, set the PostgreSQL credentials and timezone in the .env file as the compose instructions require, and change the default [email protected] credentials before you expose the instance to anything.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. shridarpatil/whatomate on GitHub