Fonoster: A programmable voice and SMS platform built on Asterisk

Programmable voice through the API and voice verbs

Fonoster replaces Twilio's webhook callbacks with an SDK-first model. Every action in Fonoster is available through APIs and a TypeScript SDK. Voice applications are HTTP servers you run; when a call arrives, Fonoster POSTs a request to your endpoint with call metadata, and your code responds with a verb sequence.

The README documents twelve verbs: Answer (pick up), Hangup (end the call), Play (stream audio from a URL), Say (text-to-speech), Gather (collect DTMF or speech input), Dial (forward to a PSTN number or SIP extension), Record (save audio), and others. Each verb is a method on the VoiceResponse object. A voice application that handles Answering Machine Detection on outbound calls looks like this:

new VoiceServer().listen(async (req: VoiceRequest, voice: VoiceResponse) => {
  if (req.amd?.status === "MACHINE") {
    return voice.hangup();
  }
});

Once a voice application is deployed and registered in Fonoster, you originate calls through the SDK by providing the from, to, and appRef.

const SDK = require("@fonoster/sdk");
const client = new SDK.Client({ accessKeyId });
await client.loginWithApiKey(apiKey, apiSecret);
const calls = new SDK.Calls(client);
await calls.createCall({ from: "+18287854037", to: "+17853178070", appRef });

The API model inverts Twilio's: instead of Twilio calling your application, you host the application and Fonoster calls it. This trades the simplicity of webhooks for full control over where your code runs.

Multitenancy and self-hosted infrastructure

Fonoster is built to run on your own servers. The deployment is Docker-based: the compose.yaml file defines twelve services including the apiserver, dashboard, Asterisk media servers, Routr SIP proxy, PostgreSQL, and monitoring infrastructure with InfluxDB. Every service is containerized and configurable through environment variables.

The architecture assumes you will run this in your own cloud account or datacenter. There is no managed Fonoster service; the README's getting-started section links to self-hosting docs and points to Docker Compose as the deployment method.

Multitenancy is a first-class feature. The apiserver service handles workspace management, invitation links, OAuth2 via GitHub, and role-based access control. Each workspace has its own API keys and access to a slice of the shared Asterisk media servers. You manage users and permissions through the dashboard web UI.

Installing and running Fonoster on Docker

Fonoster publishes Docker images for each component. The compose.yaml file defines the full stack. To deploy, you set environment variables for your Asterisk SIP proxy secret, database password, owner account credentials, and infrastructure IP addresses (for cloud deployments, this is the server's public IP or internal addresses).

The README lists required configuration for cloud deployments: - ROUTR_EXTERNAL_ADDRS (the public IP of your server) - ROUTR_RTPENGINE_HOST (the internal or external IP for RTP media) - ASTERISK_SIPPROXY_HOST (the IP Asterisk uses for SIP)

It also specifies that you must set strong passwords for APISERVER_ASTERISK_ARI_SECRET, APISERVER_OWNER_PASSWORD, and POSTGRES_PASSWORD in production.

The project uses Lerna monorepo structure with workspaces in the mods/ directory. If you need to build from source, the package.json scripts include npm run build to compile all workspaces and npm run db:migrate to set up Prisma schemas for the API server and identity service.

Early stability and media server dependencies

Fonoster is not a drop-in replacement for Twilio. The project's last release was v0.22.14 on 2026-09-11, and the last push was on 2026-09-18. The version numbering (0.22.x) signals that the public API is still evolving.

Fonoster depends entirely on Asterisk for media handling and call control. If Asterisk fails, your call capability is gone. Asterisk's amd.conf (answering machine detection settings) and other configuration files must be tuned manually. The README includes an aiCoustics SDK license field (AIC_SDK_LICENSE) for audio filtering; without it, the audio-filtering feature does not apply, but calls continue unfiltered. When AMD is enabled, the caller hears silence for up to the total_analysis_time configured in amd.conf before the voice app starts; this behavior is essential to understand when designing outbound call applications.

The project uses Prisma for database schema management, which means schema migrations are part of your deployment process. The database is not optional; it holds workspace, API key, call history, and routing configuration. You will need to manage two separate Postgres databases: one for the API server and one for the identity service. Deployment also requires setting strong passwords for APISERVER_ASTERISK_ARI_SECRET, APISERVER_OWNER_PASSWORD, and POSTGRES_PASSWORD in production environments to secure the system.

Where Fonoster is different from Twilio

Twilio is a managed service. You pay per minute and per SMS, scale to whatever volume you need, and Twilio manages the infrastructure. You send webhooks from your application, and Twilio calls back when events happen.

Fonoster flips both of these constraints. You host and operate it. You pay for compute, storage, and bandwidth instead of per-minute billing. And your application hosts a voice server that Fonoster calls into, not the other way around.

This difference favors Fonoster for high-volume call centers that need fine control over call routing and media processing, or for organizations with regulatory requirements to keep telephony data on-premises. It favors Twilio for teams that want to avoid the operations overhead and would rather pay per call than operate Asterisk.

NodeJS SDK and multitenancy design

The SDK and voice libraries are published as npm packages: @fonoster/sdk for the client, @fonoster/voice for building voice servers, and @fonoster/voice for the response builders. This keeps the TypeScript ecosystem tight.

The workspace and API key model in Fonoster maps to AWS-like IAM. Each workspace can have multiple users with different role-based permissions. API keys are workspace-scoped. The dashboard, built on the same API surface, is a working example of how to build administrative tools on top of Fonoster.

The OAuth2 integration with GitHub allows users to sign in with their GitHub account instead of managing separate credentials. Two-factor authentication can be required workspace-wide through the APISERVER_IDENTITY_TWO_FACTOR_AUTHENTICATION_REQUIRED flag.

Who should choose Fonoster over Twilio

Fonoster is built for organizations that need a Twilio-like API but cannot or will not use a managed service. If you have the infrastructure operations capacity to run Asterisk, PostgreSQL, and a Docker stack, and you have call volume high enough that per-minute billing becomes expensive, Fonoster makes economic sense. If you need 99.99% uptime guarantees and carrier-grade support, Twilio's overhead is cheaper than building that yourself on Fonoster. Before adopting, verify that your team can manage Asterisk configuration, database migrations, and multi-container deployments in your production environment.

Editorial conclusion

Adopt Fonoster if you need full control over your telephony stack, have the infrastructure to run Asterisk, and want to avoid Twilio's per-minute pricing. Skip it if you need managed, carrier-grade reliability without maintaining database schema migrations and Linux containers. Verify that the Asterisk media server configuration matches your call volume and that you have capacity for Postgres and Docker orchestration before deploying beyond staging.

Frequently asked questions

Official sources

1. fonoster/fonoster on GitHub
2. License: MIT
3. Project website
4. README
5. Releases