How Smile Cast works
Honest architecture notes: what runs where, what each plan enforces, and where the limits of a shared-hosting deployment really are.
The short version
Video and audio travel directly between participants using WebRTC. This application handles accounts, meetings, permissions, chat, presence and the developer API — and it relays the small negotiation messages browsers need to find each other.
Each browser connects straight to every other browser in the room (a mesh). This needs no extra server process, which is why it works on ordinary shared hosting. It is efficient for small rooms and we cap it at 8 participants; beyond that a media server is the right answer.
What it is made of
Four products, under one account, and each one is a working part of the application rather than a roadmap entry:
- Meetings. The video room itself — waiting room and host controls, chat, screen sharing, polls, Q&A, live captions, attendance export and recording.
- SmileDrive. The workspace's own cloud storage — folders, versions, starred items, password-protected share links and trash — drawing on the same storage quota the server enforces when a recording is uploaded.
- Appointments. A public booking page (one per working pattern) that creates the meeting when a slot is claimed, with buffers, minimum notice and daily caps on the server side.
- Verification API. Identity and business checks (KYC and KYB) and the REST API that brokers them to a licensed provider, metered against the Developer plan and delivered by signed webhook. A sandbox key runs the same code path on test data.
The rest of this page is how those parts actually run: which pieces are this application, which genuinely need a separate service, and where a limit is real.
What this application does
- Signalling. Offer/answer and ICE candidates are stored as short-lived rows and picked up by the participants they are addressed to. Rows expire within 120 seconds and are pruned on every poll.
- Presence. Participants send a heartbeat; anyone who stops sending is marked as left automatically, so the roster stays true without a background worker.
- Authorization. Every room action is re-checked on the server: guests present a signed join token scoped to one meeting, hosts are re-verified from the session on every request.
- Enforcement. Participant caps and meeting length come from the plans table and are applied on the server as the meeting runs.
What needs a separate service
Two things genuinely cannot run on shared hosting, so they are separate, optional services rather than pretend features:
- Media server (RTC Gateway). Needed for rooms larger than a mesh, or when you want simulcast. It is not needed to record.
- Cloud recording worker. Keeping the file on the server — so the whole workspace can reach it — means muxing audio and video in a process that can hold the streams. Until you connect one, cloud recordings stay queued and the interface tells you so. Host-side local recording needs no service: the host's browser does the work and the file goes to their own computer.
Networks and firewalls
WebRTC needs a route between participants. Most home and office networks work with a public STUN server alone. This installation has no TURN relay configured. On restrictive networks — some corporate and campus networks — a call may fail to connect, and the room will tell you that instead of pretending everyone left. Adding a TURN server (for example coturn) in the configuration fixes it.
Email and background jobs
cPanel gives every account a working mail path, so transactional email uses
mail() by default, with an SMTP driver available. There is no queue worker:
webhook retries and queued email are flushed opportunistically during normal page views,
and an optional cron entry is documented if you want them drained on a schedule.