August 10, 2026
System Overview
One running system, fanning out to the social web
How a request moves through the platform — from a visitor or admin, through Phoenix and the domain contexts, into a per-tenant Postgres schema, and out to the fediverse, Bluesky, and member feeds.
Core · Phoenix Background · Oban / ETS Data · Postgres External · over Finch
Enters as
Visitors
Public tenant sites
Admins & resellers
The editor & settings
Inbound social
Mastodon / Bluesky reach the actor
by host
BEAM · one deploy (Phoenix)
Web layer
Tenant · Auth plugs
Host → schema; sessions & roles
Public render
Controllers + Liquid, server-side
Admin
LiveView — no SPA
Federation endpoints
WebFinger · actor · inbox/outbox · atproto-did
Templating
Liquid / Liquex
Library templates + blocks · installed & synced per tenant · sandboxed
Domain contexts
CMS
Pages · blocks · media
Accounts
Users · tenants · neighbourhoods
Fediverse
ActivityPub
Atproto
Bluesky client
Feeds
Planet aggregator
AI · Storage · Secrets
Vision/SEO · media · encryption
Background
Oban queues
federation · atproto · feeds · ai — signed, retried
Cron · PollWorker
Warms feeds every 10 min
ETS cache
Merged feed, off the render path
Ecto · prefix per tenant
Data
Postgres · Triplex
Schema-per-tenant isolation
Global schema
tenants · users · neighbourhoods · oban_jobs
Per-tenant schemas ×N
pages · blocks · site_settings · feed_sources · followers
Finch (HTTP)
External
Fediverse
ActivityPub · signed
Bluesky
AT Protocol · XRPC
Member feeds
RSS / Atom
Anthropic
AI
S3
Media storage
Read path
A host resolves to a tenant schema; the CMS builds the page and Liquid renders it server-side — fast, cacheable, SEO-clean.
Write path
Editing runs over a LiveView socket with state held on the server — one lightweight BEAM process per session.
Fan-out
Publishing enqueues Oban jobs that deliver to every follower inbox and cross-post to Bluesky — in parallel, each retrying on its own.