Routr

Open-source SIP infrastructure, honestly reviewed. What you actually get when you self-host it.

TL;DR

• What it is: Open-source (MIT) SIP proxy, location server, and registrar — the programmable telephony infrastructure layer that Twilio built its empire on top of, but self-hosted and extensible [README].
• Who it’s for: Telephony engineers, communication service providers, VoIP integrators, and technically capable founders building voice or SIP-based products. This is not a point-and-click tool [README][website].
• Cost savings: Twilio’s SIP trunking and programmable voice charges per minute and per number. Routr self-hosted runs on a $10–20/mo VPS with no per-minute fees once your SIP trunks are connected. The savings depend entirely on your call volume.
• Key strength: Genuinely cloud-native architecture — Kubernetes-ready, Docker-first, gRPC API, NodeSDK, programmable routing. The only open-source SIP server purpose-built for cloud infrastructure rather than retrofitted to it [README][website].
• Key weakness: This is infrastructure-level software. There is no web UI for call management, no built-in billing, no drag-and-drop anything. A non-technical founder cannot deploy this without engineering help [README].

---

What is Routr

Routr is a SIP (Session Initiation Protocol) proxy, location server, and registrar built by Fonoster — a company positioning itself as the “open source alternative to Twilio” [website]. The core software handles the signaling layer of VoIP: routing calls between endpoints, registering SIP devices, authenticating users, and load-balancing traffic across media servers like Asterisk and FreeSWITCH [README].

If those words mean nothing to you, a quick translation: SIP is the protocol that handles phone call setup and teardown. When you call someone over the internet, a SIP server decides where that call goes, who answers, and what happens when the line drops. Twilio abstracts all of this behind a REST API you call from your app. Routr is the layer that Twilio (and every carrier running its own infrastructure) runs underneath — exposed and configurable, not hidden behind a monthly bill.

The project sits at 1,670 GitHub stars and is licensed MIT [merged profile]. It’s built by Fonoster, which runs a commercial layer (a managed platform) on top of the open-source core. The parent company markets Routr as foundational infrastructure and sells deployment consulting via a Cal.com booking link on the homepage [website].

What makes Routr different from classical SIP servers like Kamailio or OpenSIPS is the architecture: it was designed from the start for containerized cloud environments. Kubernetes-native with Helm charts, Docker Compose for local development, gRPC API for server management, and a NodeSDK so JavaScript developers can control it programmatically [README]. Veteran SIP engineers will recognize this as a meaningful shift — Kamailio is tremendously powerful but was designed for bare-metal deployments, and adapting it to cloud-native ops requires significant custom work.

---

Why people choose it

Independent third-party reviews of Routr are scarce — this tool serves a narrow professional audience, not a mass market that generates blog posts and Trustpilot reviews. The available social proof comes from testimonials on the project’s own pages.

Three quotes appear consistently across the README and website, and they’re worth reading carefully because they reveal exactly who Routr is for:

Phil Jones, VP of Web Architecture at VQ Communications: “Routr’s architecture and design is fantastic. A breath of fresh air. Being Docker and Kubernetes ready is a huge win over a more traditional SIP server setup.” [README][website]

Jessie Wadman, Cloud Architect at Camanio AB: “I came across Routr, which seems to be the one and only cloud-first Kubernetes-ready SIP server on the planet!” [README][website]

A Reddit user in r/linux: “Awesome and one of the best open-source software in 2023.” [README]

Notice who’s talking: a VP of Web Architecture at a communications company, a cloud architect, a Linux enthusiast. Not a founder who wants to send SMS. Not a marketer trying to automate email sequences. These are infrastructure engineers solving a specific problem — deploying SIP at cloud scale without being locked into legacy server paradigms or Twilio’s pricing.

The positioning Fonoster makes explicit on their homepage — “Building the open source alternative to Twilio” — tells you who the real competition is [website]. Twilio charges per minute, per number, per message, and takes a cut of every call. At scale, that bill becomes painful. A communication startup running thousands of calls per day faces a meaningful decision: keep paying Twilio forever, or build on open infrastructure and own the stack.

---

Features

From the README, Routr’s confirmed feature set:

Core SIP functions:

• SIP Proxy, Registrar, and Location Service [README]
• Transport: TCP, UDP, TLS, WebSocket (WS/WSS) [README]
• In-memory and Redis-backed Location Service [README]
• Session Affinity [README]
• No single point of failure — built for HA deployments [README]

Routing and load balancing:

• Programmable routing via NodeSDK and gRPC API [README]
• Load balancing against media servers (Asterisk, FreeSWITCH) [README]
• Four configurable routing strategies: Intra-Domain, Domain Ingress, Domain Egress, Peer Egress [README]
• Multi-Tenant / Multi-Domain with Domain-level ACL [README]

Data and configuration:

• JSON and YAML files as data sources [README]
• PostgreSQL as a data source [README]
• Redis for distributed state [README]

Developer tooling:

• gRPC API for server management [README]
• NodeSDK [README]
• Command-Line Tool (CTL) for remote server control [README]
• RTPEngine Middleware for media handling [README]
• Helm Chart for Kubernetes deployments [README]
• JWT authentication for web phone endpoints [README]
• RESTful API (mentioned on website) [website]

What’s missing (explicitly listed as not yet implemented in the README):

• STIR/SHAKEN support (call authentication protocol, increasingly required by carriers) [README]
• Web Application (no browser-based admin UI) [README]
• Region-based routing [README]

The missing web UI is the most practically significant gap. You manage Routr through the CLI, gRPC API, or NodeSDK. If your team expects a browser dashboard to view registered endpoints, manage domains, and inspect call routing, that isn’t here yet [README].

---

Pricing: SaaS vs self-hosted math

Routr itself is MIT-licensed software with no usage fees [merged profile]. Fonoster runs a commercial managed platform on top of it, but pricing for that platform is not published — the website directs commercial inquiries to a sales call booking [website].

Self-hosted cost:

• Software: $0
• Infrastructure: A VPS with 2–4GB RAM and reasonable CPU — $10–20/mo on Hetzner or DigitalOcean
• Your time or a contractor to deploy and maintain it

What you’re replacing: Twilio’s pricing model charges per minute for calls (roughly $0.0085–$0.013/min for inbound, $0.014/min for outbound in the US), per phone number (~$1/mo), and additional fees for features like recording and transcription. A small communication app making 10,000 minutes of calls per month runs $140–$200/mo in Twilio fees before you add numbers and features. At 100,000 minutes/month, you’re looking at $1,400–$2,000/mo.

Self-hosted Routr eliminates the per-minute Twilio tax. You still pay for SIP trunking (carriers like Telnyx or Twilio’s SIP trunking product — ironic but cheaper than their full platform), but at wholesale rates.

The savings math is real, but only at volume. If you’re making a few hundred calls per month, the infrastructure and maintenance cost of self-hosting exceeds what Twilio charges. The break-even point depends on your call volume and how much your engineering time costs.

Data on Fonoster’s managed platform pricing is not available from the sources provided.

---

Deployment reality check

This is where the honest assessment diverges most sharply from what the homepage implies.

The website says “Deploy Routr in seconds” and highlights Docker, Kubernetes, and Gitpod options [website]. The README’s deployment section is genuine — Docker Compose works, Helm charts exist, and a Gitpod environment lets you explore without a local setup. A developer who has deployed containerized services before can get Routr running in an afternoon.

But “running” and “production-ready” are different things.

What you actually need to operate Routr in production:

• A Linux server or Kubernetes cluster (at minimum 2GB RAM; more if running multiple services)
• Docker/Compose or a Kubernetes environment
• PostgreSQL for persistent data storage
• Redis for distributed location service
• A SIP trunk from a carrier (Telnyx, Bandwidth, VoIP.ms, or similar)
• A media server (Asterisk or FreeSWITCH) for handling actual audio — Routr handles signaling only, not media processing
• TLS certificates for WSS/TLS transport
• Working knowledge of SIP as a protocol

That last item is the real gating factor. SIP is a protocol with sharp edges: NAT traversal is a recurring headache, codec negotiation fails in non-obvious ways, and debugging a bad REGISTER response requires reading raw SIP messages. You can deploy Routr in an afternoon if you know SIP. If you don’t know SIP, you will need to learn it, or hire someone who does.

The README explicitly links to an official handbook (sold via Gumroad) and points to documentation at routr.io/docs [README][website]. The existence of a paid handbook for a free tool is a signal about complexity — it’s not a point-and-click product.

Where things can go sideways:

• Media processing requires a separate Asterisk or FreeSWITCH instance — Routr handles SIP signaling, not audio
• STIR/SHAKEN is not yet supported, which matters if you’re running outbound calling at scale (US carriers increasingly require it) [README]
• No web UI means debugging requires CLI fluency
• Small GitHub star count (1,670) relative to Kamailio or FreeSWITCH means a smaller community knowledge base for troubleshooting

---

Pros and Cons

Pros

• Genuinely cloud-native architecture. Kubernetes-ready from the ground up, not bolted on. Helm charts, Docker Compose, gRPC API — this fits into modern DevOps workflows without adaptation [README][website]. The VP testimonial about it being “a breath of fresh air” over traditional SIP servers reflects a real difference [README].
• MIT license, no commercial restrictions. You can embed Routr in your own product, resell services built on it, or deploy at any scale without a licensing conversation [merged profile].
• NodeSDK for programmable routing. JavaScript developers can write custom routing logic without learning Kamailio’s scripting language or OpenSIPS’s DSL. This is a genuine advantage for teams already in the Node/TypeScript ecosystem [README].
• No single point of failure. Built for horizontal scaling, with Redis-backed distributed location service [README].
• Multi-tenant with ACL. Supports multiple domains and tenants in one deployment, which matters for CSPs serving multiple customers [README].
• Active development by a real company. Fonoster is a going concern with commercial incentives to maintain the project [website][README].

Cons

• No web UI. Everything through CLI, gRPC, or API. This is not a product you hand to a non-technical operator [README].
• STIR/SHAKEN not implemented. US carriers are mandating this for outbound calling. The README lists it as a missing feature — meaning outbound calling at scale in the US will require additional infrastructure or workarounds [README].
• Media processing not included. You need Asterisk or FreeSWITCH separately. Routr handles the signaling layer only; audio processing is someone else’s job [README].
• Small community. 1,670 GitHub stars is modest compared to Kamailio (2,000+) or FreeSWITCH (much larger ecosystem). Stack Overflow answers, community guides, and troubleshooting threads are thinner [merged profile].
• Managed platform pricing opaque. If you want Fonoster to host it for you, you have to book a sales call — there’s no self-serve pricing published [website].
• Region-based routing is a planned, not available, feature. If you need geo-routing for call quality optimization, it’s not here yet [README].

---

Who should use this / who shouldn’t

Use Routr if:

• You’re a VoIP engineer or communication platform builder who understands SIP and is running enough call volume that Twilio’s per-minute fees are becoming a real budget line.
• You need Kubernetes-native SIP infrastructure and don’t want to adapt Kamailio or OpenSIPS to cloud-native deployment patterns.
• You’re building a product on top of voice infrastructure (a UCaaS platform, a contact center tool, a communications API) and need programmable routing with a NodeSDK.
• Your team is comfortable with gRPC APIs, Docker, and infrastructure-as-code — and will maintain what they deploy.

Skip it if:

• You’re a non-technical founder who wants to add voice or SMS to your product. Use Twilio or Vonage APIs until you have an engineering team and call volume that justifies self-hosting.
• You need a PBX with voicemail, call queues, an IVR builder, and a web admin panel. Routr is a signaling layer — look at FusionPBX (FreeSWITCH frontend) or 3CX for a complete PBX.
• You don’t know what NAT traversal means in a SIP context and don’t plan to learn.
• Your call volume is under ~10,000 minutes/month. The infrastructure cost and maintenance overhead won’t justify the savings over Twilio at that scale.

Consider Routr as part of a larger stack if:

• You’re building on Fonoster’s full platform (which uses Routr at its core) — the managed option avoids the self-hosting complexity while keeping you on open-source infrastructure.

---

Alternatives worth considering

Kamailio — the incumbent open-source SIP proxy. Extremely powerful, deployed by major carriers worldwide, massive community. The learning curve is steeper than Routr and cloud-native deployment requires more manual work, but documentation depth and community are unmatched.

OpenSIPS — similar scope to Kamailio with a different architecture and scripting model. Also mature, also bare-metal-oriented in its defaults.

FreeSWITCH — more of a media server and full PBX than a SIP proxy. Handles audio processing, not just signaling. Often deployed alongside Routr or Kamailio rather than instead of them.

Asterisk — the classic open-source PBX. Broader feature set including voicemail, IVR, and call queues. More approachable for self-hosted office telephony. README explicitly mentions Asterisk as a media server that Routr load-balances against [README].

FusionPBX — a web UI for FreeSWITCH. If you want a complete PBX with a browser-based admin panel, this is closer to what you probably need.

Twilio — the SaaS incumbent. Easiest integration, most features, per-minute pricing that scales uncomfortably. Stay on Twilio until you have both the call volume and the engineering capability to justify self-hosting.

Fonoster Platform — Fonoster’s managed cloud product built on Routr. Gives you the open-source infrastructure without the self-hosting burden. Pricing requires a sales conversation [website].

---

Bottom line

Routr solves a real problem well: it’s the only open-source SIP server designed from the ground up for cloud-native infrastructure. If you’re a communication platform engineer who’s been adapting Kamailio to Kubernetes with custom scripts and duct tape, Routr’s architecture is genuinely refreshing. The MIT license, NodeSDK, gRPC API, and Helm charts are real advantages for teams already working in modern DevOps environments.

But the product’s own description tells you exactly who it’s for — “telephony carriers, communication service providers, and integrators” [README][website]. That’s not a non-technical founder looking to replace a SaaS bill. The missing web UI, the required understanding of SIP, the need for a separate media server, and the sparse third-party documentation make this a tool for infrastructure engineers, not end users.

If you’re building a communication product that processes enough call volume that Twilio’s per-minute fees are hurting, and you have the engineering talent to own your SIP infrastructure, Routr is worth serious evaluation — especially if your team lives in the Node ecosystem. If you’re a founder who just wants your app to make calls without a surprise invoice, keep paying Twilio until you have someone who can own this stack.

The self-hosted path is real, the license is clean, and the architecture is sound. The gap is operational complexity, not software quality.

---

Sources

1. Routr GitHub Repository and README — Primary technical documentation, feature list, testimonials, deployment options. https://github.com/fonoster/routr
2. Routr Official Website — Homepage, product description, capabilities, testimonials, community links. https://routr.io
3. facts.dev — BigBlueButton project details — Lists Routr as a related project in the communication/self-hosted category. https://www.facts.dev/p/bigbluebutton/

Primary sources:

• GitHub repository: https://github.com/fonoster/routr (1,670 stars, MIT license)
• Official website: https://routr.io
• Documentation: https://routr.io/docs
• Official handbook (paid): https://fonoster.gumroad.com/l/the-future-of-programmable-sip-servers