Trust & Infrastructure
Security you can explain in procurement. Infrastructure you can name in a runbook.
Enterprise clients require you to document every data path, every subprocessor, and every control. KernelWork is built so your security and ops teams can answer those questions — no black boxes, no vendor-only configuration, no components you cannot name.
Security controls
What is in place today.
TLS on the edge, JWT access and refresh token rotation for the app, authenticated Socket.io connections, rate limits on auth and API endpoints, hashed API keys for integrators, and origin allowlists for video embeds. The full control list is in docs/SECURITY.md in the repository.
Message bodies and attachments are protected in transit and governed by your database and object-store policies. Operators choose regions, retention, and backup strategy — the product does not substitute for your SOC processes or pen-test program.
- TLS termination at the edge — all client traffic encrypted in transit.
- JWT access + refresh rotation — short-lived tokens, server-side revocation.
- Authenticated Socket.io connections — no anonymous realtime access.
- Rate limits on auth and public endpoints — brute force and enumeration mitigations.
- Hashed API keys for integrators — secrets never stored in plaintext.
- Origin allowlists for video embeds — no cross-origin token reuse.
Encryption
Transport encryption today. E2EE on the roadmap.
End-to-end encryption of message content is not shipped today. The architecture is designed so bodies can move toward ciphertext-only storage without rewriting the product. We do not claim otherwise in sales collateral — buyers should assume the server can enforce search, moderation, and legal hold consistent with typical enterprise messaging.
Encryption at rest for object storage (attachments and recordings) is governed by your object store configuration — S3-compatible stores support server-side encryption with keys you control.
Architecture
Three planes your security team can name in every DPA.
Every component is identifiable, auditable, and documentable. Your clients see outcomes — your security and ops teams see a credible architecture they can put into network runbooks and data processing addenda.
Control plane
PostgreSQL + Redis
Accounts, workspaces, conversations, tokens, and presence. Runs on hosts you operate or that we isolate under contract.
Storage plane
S3-compatible object store
Attachments and recordings. Under your encryption keys, in your chosen region. MinIO for self-hosted; any S3-compatible provider for cloud.
Media plane
LiveKit SFU + TURN
WebRTC audio and video paths. Fully documentable for enterprise network policies. Coturn as TURN relay fallback.
Three-plane architecture
Clients
Browser · Desktop · Mobile
Web app
Desktop shell
Mobile
Control plane
API + auth + logic
Express API
Node.js
PostgreSQL
Primary DB
Redis
Pub/sub · cache
Storage plane
Media plane
S3-compatible
Files · recordings · assets
LiveKit SFU
WebRTC · SFU topology
TURN / STUN
NAT traversal
All planes run inside your tenant boundary. No data crosses to shared infrastructure. Self-hosted deployments bring their own PostgreSQL, Redis, S3, and LiveKit.
Deployment baseline
What runs in the stack.
The baseline is docker compose up for local parity; Nginx (or your edge) and TLS in production. Environment variables — not magic hosted knobs — define Postgres, Redis, object storage, and media endpoints. Ports and roles match the root README.
| Service | Ports | Purpose |
|---|---|---|
| PostgreSQL | 5432 | App database and tenant data |
| Redis | 6379 | Presence, caching; LiveKit coordination |
| MinIO | 9000 (S3), 9001 (console) | Attachments and recordings |
| LiveKit | 7880–7881, UDP 50000–50200 | WebRTC SFU and built-in TURN |
| Coturn | 3479 TCP/UDP, UDP relay range | STUN/TURN relay fallback |
| Backend API | 3000 | Express API and Socket.io gateway |
| Web app | per your reverse proxy | React SPA + static assets |
- Service
- PostgreSQL
- Ports
- 5432
- Purpose
- App database and tenant data
- Service
- Redis
- Ports
- 6379
- Purpose
- Presence, caching; LiveKit coordination
- Service
- MinIO
- Ports
- 9000 (S3), 9001 (console)
- Purpose
- Attachments and recordings
- Service
- LiveKit
- Ports
- 7880–7881, UDP 50000–50200
- Purpose
- WebRTC SFU and built-in TURN
- Service
- Coturn
- Ports
- 3479 TCP/UDP, UDP relay range
- Purpose
- STUN/TURN relay fallback
- Service
- Backend API
- Ports
- 3000
- Purpose
- Express API and Socket.io gateway
- Service
- Web app
- Ports
- per your reverse proxy
- Purpose
- React SPA + static assets
Consultancy starter checklist
- DNS and TLS certificates for the hostname clients will see.
- Firewall rules for LiveKit TCP/UDP ranges and Coturn relay ports.
- Tenant creation, admin accounts, and module configuration for the first engagement.
- Subprocessor list (Postgres host, object store, SFU, optional push) for your template DPA.
Horizontal scaling
Horizontal scale for the realtime layer requires a Socket.io Redis adapter so events fan out across processes. Enable that path before putting multiple API replicas behind a load balancer — otherwise clients on different nodes will miss each other's events. See docs/HOSTING_STRATEGY_REPORT.md in the monorepo for capacity discussion.
Compliance
GDPR-aware framing and subprocessor questions.
Self-hosting and clear data residency support common GDPR themes: you are typically the controller for workplace data; subprocessors are the stack you deploy — PostgreSQL host, object store, SFU, and optional push providers such as FCM when mobile notifications are enabled. Map each to your ROPA and DPA templates.
For cloud or dedicated footprints operated by KernelWork, list the concrete hosts: API region, database region, object store bucket regions, LiveKit cells, and optional notification providers. For self-hosted licenses, your subprocessors list is exactly the infrastructure you operate — which is often the answer procurement wants when a client asks where recordings live.
We do not claim SOC 2 Type II or ISO certifications on this page unless attestation artifacts are published. Buyers should treat this page as engineering disclosure, not a certification matrix.
Product-level compliance posture is summarised in docs/OVERVIEW.md.