streamcoreai/streamcore-server

Follow-up to #57 / #63. The internal pprof listener landed and is safe by default — debug.bind = "" means no listener, no runtime profile changes, and the public mux never sees /debug/pprof/. Everything below only matters once an operator actually opts in, which is why it was worth merging first and tightening after. Items are independent. Grab one, grab several, no need to claim the whole list. 1. A failing debug listener must not kill the server main.go, in the goroutine started by startDebugServer: if err := srv.Serve(listener); err != nil && err != http.ErrServerClosed { log.Fatalf("debug server error: %v", err) } log.Fatalf is os.Exit(1): no sm.CloseAll(), no graceful HTTP shutdown, every live WebRTC call drops on the spot. An accept error on an optional profiling listener should never take production media down with it. This mirrors the pattern used for the main HTTP server, where the process genuinely cannot do its job without a listener — here it can. Make it log.Printf

Problem The streamcoreai/examples repo proves the SDKs work. It does not prove the positioning. What is there today is one shape repeated per language: connect to a server, talk to an LLM agent, see a transcript. typescript, python, golang, golang-tui, rust, rust-tui, esp32, esp32-desktop-car, bring-your-own-agent. Useful as SDK smoke tests, and every one of them says the same thing about what this project is. The claim being made is realtime media infrastructure — a WebRTC transport with a pluggable pipeline on top, where the LLM is one thing you can put in the middle rather than the point of the exercise. Nothing in the examples repo demonstrates that. A visitor reasonably concludes this is a voice-chatbot starter, because every example is a voice chatbot. Proposed change Six examples, each chosen because it is the smallest thing that makes a different claim. Each is independently useful, so these can land one at a time and this issue can be split. 1. Realtime translator. Caller sp

Problem Nobody can answer "how many concurrent calls does this handle per core", which is the first question anyone evaluating voice infrastructure asks and the last question this repo can answer. It is also blocking a real decision. server.max_sessions exists and defaults to 0 (unlimited): max_sessions = 0 # Global cap on live sessions; past it POST /whip returns 503 with Retry-After. 0 = unlimited. The config comment says to "set this to what one instance can actually serve", and the project provides no way to find that number out. A default of unlimited is the honest choice given that, but it means the first person to get traffic discovers the ceiling by falling off it. The cost model per session is not obvious enough to estimate on paper either: a DTLS/SRTP association, Opus decode and encode through a wazero WebAssembly module, a resampler, VAD on every 20 ms frame, a streaming STT websocket, a streaming LLM connection, a streaming TTS connection, plus the turn buffer and rollin

Problem .github/workflows/ci.yml runs gofmt -l, go build ./..., go vet ./... and go test -race ./.... That is a good gate for correctness and it catches nothing about dependencies. go.mod pulls in the WebRTC stack (pion/webrtc/v4, pion/ice/v4, pion/turn/v5, pion/rtp, pion/interceptor), a Postgres driver, a JWT library, a WebSocket library, and four provider SDKs. Every one of those parses input from the network, and two of them — the ICE/DTLS path and golang-jwt — parse input from unauthenticated strangers. Nothing tells the repo when one of them ships a CVE. The Docker image has the same hole and a wider one: the runtime stage is node:22-bookworm-slim, it installs tsx globally, creates a Python venv, and runs npm install across every plugin directory. That is three ecosystems of transitive dependencies in the published image, and nothing scans it. For a project asking people to run it as infrastructure, each of these is a one-file addition, and their absence is more conspicuous th

Problem There is no released artifact of this server. .github/workflows/deploy-ec2.yml pushes ghcr.io/streamcoreai/streamcore-server:${{ github.sha }} on every push to main and redeploys the EC2 host, which is a deployment pipeline, not a distribution channel. Three things are missing on top of it: No version in the binary. The Dockerfile builds with RUN CGO_ENABLED=0 GOOS=linux go build -o /server . and passes no -ldflags, so nothing in the process knows its own commit. #30 covers the /version endpoint; this issue covers the value it would report. No standalone binaries. Running without Docker means installing Go and building. For a single static CGO_ENABLED=0 binary that is a self-inflicted wound. No changelog and no tags. A user upgrading has no way to find out what changed, and "which version broke it" is not a question anyone can currently answer. Proposed change Tag-driven release workflow. Add .github/workflows/release.yml triggered on v* tags. It should do three things and no