Developers

Architecture & tech stack

How the core API, client SPA and realtime services fit together, and what they're built with.

Tyto is two independently deployable parts — a fat API server and a thin static web client — plus self-hosted services for search, presence, realtime and voice, all shipped in one compose stack.

Tech stack

Core — API server

PHP 8.5Symfony 7.4 LTSAPI Platform 4JSON-LD RESTMariaDB 11.8Doctrine ORMMercurerealtime SSEMeilisearchmessage searchValkeypresence · cache · limitsLiveKitvoice & videoJWT+ refresh tokens, PATsFrankenPHPprod runtime · auto-HTTPS · Souin HTTP cache

Client — web app

React 19TypeScriptVite 7TanStack Routerfile-basedTanStack Queryserver stateTailwind CSS v4Tiptapmessage editorCaddystatic serving · runtime config

How a request flows

Browser — SPA / native client

HTTPS API · SSE realtime · WebSocket voice signalWebRTC media goes direct — UDP, not through the web tier

core — FrankenPHP
Symfony API · embedded Mercure hub · Souin cache · Caddy TLS

internal compose network

MariaDB
dataMeilisearch
searchValkey
presence · cacheLiveKit
voice media

Async work (notifications, digests, webhooks, retention purges) runs in separate worker and scheduler containers off the same image, consuming a database-backed message queue.

Everything is live: messages, reactions, edits, presence and structure changes stream to open clients over the SSE connection — the interface never polls and never needs a refresh. Behind a reverse proxy, that’s why response buffering must be off.

The client is built to fail gracefully: dropped realtime connections auto-reconnect and resubscribe, a failed send rolls back optimistically shown messages (rate-limited sends restore your text to the composer), and a client/server version mismatch after an upgrade shows a reload screen instead of subtle breakage.

Data model in one breath

Structure

Community → Sections → Channels (text · voice, public · private) with per-channel roles, favorites and read state.

Messaging

Messages grouped into pages for fast history; one-level threads, reactions, pins, edit history and soft-delete. Conversations (DMs) reuse the same pipeline.

Around it

Notifications (in-app, desktop, Web Push, email digest), moderation actions, reports & appeals, user groups, custom emojis, webhooks, API keys.