Channels, presence and live logs
WebSocket channels scoped to a project, for broadcasting events, tracking presence and streaming container logs.
- Project-isolated channels
- Short-lived signed tickets
- Direct WebSocket, no dashboard hop
Broadcast in a project boundary
A channel belongs to exactly one project. A channel with the same name in another project is a different channel, not a collision.
Tickets, not long-lived keys
The dashboard issues a short-lived, single-use ticket. Clients connect straight to the realtime endpoint with it; no API key ever reaches the browser.
Presence when you want it
Broadcast reaches connected subscribers. Presence adds participant state on top, for cursors, typing indicators and who-is-here lists.
Live logs are a reserved namespace
logs:app:<name> and logs:function:<name> are granted by the ticket, subscribe-only, so no client can forge a log line into someone else's stream.
One follower per container
The first subscriber starts the log follower, the last one stops it. Ten people watching the same application is one stream, not ten.
Not an event archive
Realtime delivers to who is connected now. Store anything that matters in PostgreSQL and resynchronize after a reconnect.
Why the WebSocket does not go through the dashboard
Serverless functions cannot hold a persistent connection, so the dashboard only mints the ticket. The socket itself goes directly to the realtime host, which proxies exactly one path and answers 404 to everything else.
veltic realtime channels create PROJECT_ID orders "Order status"
veltic realtime listen PROJECT_ID orders
veltic realtime publish PROJECT_ID orders created '{"id":1}'Build the whole backend in one project
One plan, one dashboard, one command line interface. PostgreSQL, applications, functions, storage and realtime.