Skip to content

PlayTelly

PlayTelly is a multi-tenant streaming infrastructure platform. It is composed of ## several repositories that work together — each one has a distinct role, and the full system runs by cloning them side-by-side and starting them through a single entry point.

Repositories

Repository Role
Quickstart Makefile + all Docker Compose files. The single entry point for running the platform.
CoreAPI Central backend API. Handles channels, media, provisioning, spatial, identity, and more.
AuthAPI Authentication service layer. Bridges Zitadel with PlayTelly-specific auth logic.
PlayoutAdmin Primary admin web app for operators and content managers.
TellyBoard Secondary admin app.
documentation This documentation site.

Quickstart is the orchestrator — it holds every Compose file and knows how to wire all services together. The repositories themselves only contain a Dockerfile; they do not manage their own infrastructure.

How the services talk to each other

graph LR
    subgraph AdminApps["Admin Apps"]
        PlayoutAdmin
        TellyBoard
    end
    AdminApps --> CoreAPI
    AdminApps --> AuthAPI
    CoreAPI --> Postgres
    CoreAPI --> SeaweedFS
    CoreAPI --> Redis
    CoreAPI --> Zitadel
    AuthAPI --> Zitadel

Admin apps talk to CoreAPI and AuthAPI only. They do not touch infrastructure microservices (Postgres, Redis, SeaweedFS) directly — those are internal to the backend layer.

Quickstart brings up all of this: CoreAPI, AuthAPI, admin apps, and infrastructure microservices together.

CoreAPI Domains

CoreAPI is organized by domain packages. Each domain is independently developed and owns its own models, handlers, routes, and config.

Domain Responsibility
distribution Streamer and cache node registry
playback Channel and origin management
media Media uploads, processing, storage
spatial Locations, venues, zones, endpoints
provisioning Device management
tenant Organizations and workspaces
catalogue Playlists and media channels
advertising Campaign scheduling
identity User and role management

See the Development Guide for how domains are structured and how to add one.

Development Workflow

All feature work branches off staging and merges back to staging when complete.

staging
  └── feature/your-feature   ← branch from here, merge back when done

Production releases are cut from staging → main by the team lead.

After merging, update the docs if your change affects anything other developers need to know about — a new endpoint, a new domain, changed environment variables, or updated setup steps. Edit the relevant .md files directly in the documentation repository and push to main.

Where to Go Next