Platform
Architecture
High-level application, security, job, storage, and same-origin request architecture.
Components
- Application interface: browser-facing Next.js application and browser-side encrypted-chat cryptography.
- Application API: authentication, authorization, community operations, uploads, and realtime communication.
- Background worker: queued email, reminder, registration-notice, automation-delivery, and encrypted-media deletion work.
- PostgreSQL: primary application, audit, lifecycle, and aggregate metadata store.
- Redis and BullMQ: background queue infrastructure.
- Caddy: public HTTP and HTTPS entry point and same-origin reverse proxy.
- Uploads: persistent objects including avatars, task attachments, and encrypted chat attachments.
The public entry point routes browser traffic to the application interface and API, which coordinate durable data, queues, uploaded objects, and background work.
Request flow
The browser talks to one public origin. Caddy sends page traffic to web:3000 and /api/v1 traffic to api:4000. The web server uses INTERNAL_API_URL for server-side setup checks inside the Compose network.
One public origin separates page, API, uploaded-file, and realtime traffic at the reverse proxy.
First-run setup flow
A clean install opens the setup path once. After the first community and owner exist, setup is locked and owners sign in through the normal login flow.
Initialization is available only to a fresh installation and closes after the first community and Owner are created.
Background job flow
The API enqueues work in Redis/BullMQ. The worker consumes queue jobs and performs background email and notification processing.
The application queues work, and the worker reloads durable state before delivery or encrypted-object deletion and then records the outcome.
Notification flow
Application services create audience-scoped notification records. The authenticated web shell reads the appropriate Admin or Member endpoint, maintains unread counts, and presents temporary Sonner toasts without changing read state. Optional email delivery is queued separately.
Persistent notification state, transient interface feedback, and optional email delivery remain distinct.
Automation flow
Published Task Board rules are evaluated using task state, community timezone, recipients, delivery availability, and deduplication state. Runs record live, dry-run, or test-notification outcomes; queued email delivery is handled by the worker.
Every run reevaluates current board, rule, task, event, recipient, channel, and deduplication state before it can execute.
Encrypted-chat boundary
The browser owns private keys and plaintext encryption/decryption. The API authorizes participants and devices, validates immutable public-key versions, and stores ciphertext plus safe metadata. PostgreSQL tracks lifecycle and aggregate media accounting while encrypted objects remain in uploads storage.
Participant browsers own plaintext and private keys; the service authorizes participants while transporting ciphertext and encrypted attachment objects.