ServerOpen source

Open source

The worker layer is open source. The application layer is not. Same model as Sentry or Supabase — SDKs and runtime open, hosted product closed.

Extraction in progress

pipecat-cloud-server currently lives inside our private monorepo. We’re auditing it for embedded business logic before mirroring to a public repo. Track progress at github.com/ear3-ai — a public repo will appear there when we ship self-host.

What we open source

RepoWhat it isLicenseStatus
@ear3/voice-interviewerBrowser SDK — <Ear3VoiceInterview> branded widget, <Ear3Interview> native RTVI, VoiceClient, hooks, pluginsMITLive
@ear3/serverServer SDK — webhook verification, session retrievalMITLive
voice-flow-format-normalizeJSON schema + Pipecat compiler for the interview formatMITLive
Templates (ear3-templates/*)nextjs-onboarding-starter and other reference implementationsMITLive
pipecat-cloud-serverThe Python voice worker — Pipecat pipeline, flow adapter, RTVI setupApache 2.0Preview — extraction in progress
ear3-tts-cacheTwo-tier TTS cache (RAM + persistent) that kills LLM→TTS latency on repeated phrasesApache 2.0Planned — extract from worker once worker is public

What we don’t open source

Deliberate — this is where the product lives:

  • Dashboard (app.ear3.ai) — interview builder, insights UI, billing, team management, org settings
  • Insights engine — LLM analysis of transcripts, automatic category taxonomy, pattern detection, judge scoring
  • Session mint + auth layer — pk_ / sk_ verification, workspace scoping, subscription guards
  • Business API routes — /api/v2/*, webhook fan-out, retry scheduling, delivery audit
  • Prisma schema + migrations — the DB structure

The rule of thumb: if it processes audio or connects a client to our worker, it’s open. If it turns audio into insight or bills you for it, it’s ours.

Why Apache 2.0 for the worker

Not MIT. Apache 2.0 gives an explicit patent grant that MIT lacks — important for infrastructure code where you and downstream users need protection from patent trolls asserting claims on speech-recognition or transport patents. It’s also the standard in the ecosystem: Pipecat is Apache 2.0, Daily SDKs are Apache 2.0, Kubernetes is Apache 2.0.

We use MIT for the thin SDK wrappers (@ear3/voice-interviewer, @ear3/server) — they have no patentable surface, and MIT reads shorter.

We deliberately don’t use source-available licenses (BUSL, Elastic, SSPL). They’re not real OSS, the Pipecat contributor community won’t touch them, and they’d defeat the whole point of opening the worker layer.

How the release / sync works

We picked the simplest workable mechanic: manual mirror per release.

  1. We tag a release inside our private monorepo (e.g. pipecat-worker-v1.3.0)
  2. A subtree extraction script pulls pipecat-cloud-server/ — cleanly, without any of the private history — into the public github.com/ear3-ai/pipecat-cloud-server repo
  3. GitHub Actions on the public repo builds a multi-arch Docker image (linux/amd64, linux/arm64) and pushes to ghcr.io/ear3-ai/pipecat-cloud-server:v1.3.0
  4. latest tag moves to the newest stable release; pipecat-1.x tag aliases to the newest image compatible with that Pipecat major
  5. Self-hosters docker pull the tag they want

Sync cost is ~15 minutes per release. We expected to release on the pipecat-ai cadence — roughly monthly. If demand justifies it, we’ll move to auto-sync on every main commit, but that adds scrubbing complexity (stripping private author emails, private commit refs) that isn’t worth solving until it hurts.

What you get in the public repo

Everything needed to run the worker end-to-end against an Ear3 workspace:

  • bot.py — the main Pipecat pipeline (STT → LLM → TTS wiring)
  • flow_adapter.py — bridges our interview flow format to Pipecat Flows
  • bot_config.py / bot_schemas.py — env-driven config
  • local_server.py — FastAPI for local dev without Pipecat Cloud
  • Dockerfile — the image we ship
  • tts_cache_simple/ — the caching layer described in TTS cache
  • pyproject.toml / uv.lock — reproducible Python deps

What we scrub before mirror: hardcoded workspace ID mappings, any S3 bucket names tied to our internal accounts, and legacy code paths we’ve kept around for backwards compat but that lean on our specific Postgres schema.

How to contribute (once the repo is live)

  • pipecat-cloud-server — issues + PRs welcome. good-first-issue label for entry-level tasks. Bigger changes: open a discussion first so we can align on direction
  • @ear3/voice-interviewer / @ear3/server — most PRs get reviewed same-day
  • ear3-tts-cache — once extracted, we’ll be actively evaluating alternative cache backends (Redis vs Postgres vs local-only) and better hash strategies (sentence vs phrase-level chunking)
  • Templates — if you build a template for a framework we don’t cover (SvelteKit, Remix, Astro), we’ll happily merge it and link it from Templates

Release cadence

  • SDKs (@ear3/voice-interviewer, @ear3/server) — patch releases as we go, minor releases roughly monthly. Follows semver
  • pipecat-cloud-server — tagged with the underlying pipecat-ai version (v1.3.0, v1.4.0, …), released within a week of upstream once the mirror is live
  • ear3-tts-cache — versioned independently after extraction; ~monthly minor releases

Discussion + support

  • GitHub Discussions — for design questions, feature proposals, “how do I…” threads. Async, thoughtful
  • Discord — for real-time debugging, quick questions. Ephemeral — don’t rely on it for durable knowledge; write it up as an issue if it’s important
  • Issues — for bugs and concrete feature requests with a repro

Related

  • Server Overview — three substrates for running the voice pipeline
  • Self-host — deploy pipecat-cloud-server on your k8s
  • TTS cache — the caching layer that lives in the worker image
Self-hostTTS cache
Built by Ear3 — voice interviews for any app.
⌘/