Tech stack comparison — Golang/Pion vs Elixir/Membrane vs Cloudflare/RTK

[madawei2699]

Overview

free4chat has gone through three complete rewrites, each on a different branch. This issue documents the tradeoffs of each stack for future reference — especially the SFU control question that determines whether features like a server-side AI voice participant are possible.

---

The Three Stacks

Branch: golang — Pion WebRTC + Go

SFU: Self-hosted (custom Go server using Pion)

Dimension	Assessment
WebRTC library	Pion — pure Go, full ICE/DTLS/SRTP, widely used
SFU control	✅ Full — you own the media routing
Server-side audio injection	✅ Trivial — Pion can publish audio tracks from any Go process
Luna voice bot	✅ Directly implementable
Ops burden	❌ Server required (VPS/container), coturn for TURN, deployment pipeline
Infrastructure cost	~–20/month minimum
Why abandoned	Self-hosted infra too heavy for a personal project

---

Branch: elixir — Membrane RTC Engine + Phoenix

SFU: Self-hosted (membrane_rtc_engine)

Dimension	Assessment
WebRTC library	Membrane + ex_webrtc — pure Elixir, full ICE/DTLS/SRTP
SFU control	✅ Full — custom Endpoint = custom room participant
Server-side audio injection	✅ Membrane.WebRTC.Sink publishes audio server-side; working OpenAI Realtime demo exists
Luna voice bot	✅ Directly implementable via custom RTC Engine Endpoint
Ops burden	❌ Same as Go — server, TURN, deployment
Infrastructure cost	~–20/month minimum
Why abandoned	Same reason as Go — too much infra to maintain

---

Branch: cloudflare (current) — Cloudflare RealtimeKit (Dyte)

SFU: Managed by Dyte/Cloudflare

Dimension	Assessment
WebRTC library	@cloudflare/realtimekit — browser SDK, built on Dyte
SFU control	❌ None — Dyte manages the SFU, no server-side participant API
Server-side audio injection	❌ Not possible today — Add Participant API only mints browser-side tokens
Luna voice bot	⏳ Blocked — see #56
Ops burden	✅ Zero — fully serverless, Cloudflare Workers + DO
Infrastructure cost	✅ Free tier covers typical small-scale usage
Why chosen	Zero ops for a personal project

---

The Core Tradeoff

	Go/Pion	Elixir/Membrane	Cloudflare/RTK
SFU ownership	Self	Self	Dyte/CF
Server-side audio	✅	✅	❌ (today)
Ops burden	High	High	Zero
Luna voice bot	Now	Now	Waiting
Scaling	Manual	Manual	Automatic
TURN server	Required	Required	Included
Cost at low scale	~–20/mo	~–20/mo	~/bin/zsh
Cost at high scale	Cheap	Cheap	RTK pricing applies

The fundamental tension: owning the SFU enables full customization (voice bots, custom media processing, anything) but requires running servers. Delegating to RTK eliminates ops but hands over SFU control.

---

What RTK Can and Cannot Do

Can do today:

• Multi-party voice/video rooms
• Screen sharing
• File/image transfer via data channels
• Chat messages
• Participant management
• Bot participants via text chat (current Luna implementation)

Cannot do today (blocked by Dyte's closed SFU):

• Server-side audio track injection
• Bot as real audio participant
• Custom media processing pipelines
• Access to raw audio streams server-side

Might be unblocked by CF:

• Private agents.realtime.cloudflare.com pipeline (PR feat: realtime agents cloudflare/agents#785 — closed, not merged)
• CF exposing RTK's underlying SFU App ID
• CF Containers gaining UDP support (for headless Chrome bot)

---

When to reconsider switching stacks

The current CF stack is the right choice as long as:

1. The product stays at personal/small-scale (zero ops matters)
2. Luna voice bot remains a nice-to-have, not a core differentiator

If either condition changes — i.e., Luna voice becomes a must-have, or the product needs deep media customization — the Go/Pion or Elixir/Membrane branches are both capable of delivering it, at the cost of re-introducing server management.

Related

• Luna — always-on AI voice participant #56 — Luna voice participant (the main feature blocked by RTK's closed SFU)
• Core value direction — tools for people already gathered #51 — Core product value direction