Home / Architecture

Technical architecture

Axion is built on the Matrix protocol with a hardened, multi-tenant deployment. This is the safe-to-discuss view; deeper specifics (configs, secrets, runbooks) are available under signed NDA to active enterprise customers and to programme researchers in active triage.

Service surface

Hostname	Component	Purpose
`axionchat.chat`	Matrix Synapse + Auth + Landing	Primary homeserver, account auth, public marketing.
`app.axionchat.chat`	Element web	Browser-based Matrix client (self-hosted, no third-party CDN).
`livekit.axionchat.chat`	LiveKit SFU + Egress	End-to-end encrypted SFU for voice/video calls with recording opt-in.
`media.axionchat.chat`	Matrix media repo	Direct-from-origin media uploads > 100 MB.
`sygnal.axionchat.chat`	Sygnal	Matrix → FCM / APNs push gateway.
`push.axionchat.chat`	ntfy	Push channel for non-mobile clients.
`s3.axionchat.chat`	MinIO	S3-compatible object store for media and backups.
v3 onion address	Tor hidden service	Reach the apex through Tor; advertised via the `Onion-Location` header.

Trust boundaries

Client ↔ Client (E2EE): Megolm/Olm group ratchet. Server holds ciphertext only. Keys live on devices; the cross-signing recovery secret is server-blind.
Client ↔ Server (TLS): Server sees signalling, presence, room membership, encrypted blob sizes. Sees no plaintext for E2EE rooms.
Server ↔ Federation (TLS + signed events): Matrix federation; remote homeservers verify event signatures cryptographically.
Server ↔ Push gateway (HTTPS): Sygnal sees per-event metadata necessary to wake the device, no message body.
Server ↔ SFU (E2EE for calls): LiveKit SFU forwards encrypted media without decoding.

Infrastructure

Hosting: dedicated server with Contabo (Germany, EU). Volumes are LUKS-encrypted.
Edge: Cloudflare in front of the apex and most subdomains. media.axionchat.chat is direct-to-origin to support large uploads.
Databases: PostgreSQL 17 for Synapse and auth; Redis with AOF for ephemeral state; Vault for secrets.
Backups: nightly Restic to Backblaze B2; client-side encryption, keys held by Aevrix.
Monitoring: auditd + AIDE + Grafana Alloy + Prometheus + cadvisor + blackbox; UptimeRobot for external probes.
Network: nftables default-deny inbound, fail2ban + CrowdSec consensus blocklist at edge and host. SSH key-only on a non-22 port with port-knock + Tailscale mesh for admin paths.

Failure modes designed for

Edge incident: static surfaces fail open via direct-to-origin DNS; origin is rate-limited regardless.
Single host loss: stateless components recover via image rebuild; data tier replicates with PITR.
Region loss: cold-restore tested quarterly from Restic. RTO 4 hours, RPO 1 hour for data surfaces.
Supply-chain compromise: pinned-by-digest base images; cargo-deny / OSV-Scanner / Dependabot gates; weekly audit cycle.
Insider misuse: per-role time-bounded access; four-eyes for destructive operations; auditd shell logging.
Founder account compromise: FIDO2 only; no standing production permissions; break-glass paper / hardware-backed; never single-person.

What we intentionally don't publish

Exact origin IPs, version pins, internal hostnames, monitoring rule sets, and the precise sequence of incident-response runbooks. Available under NDA to active enterprise customers and to programme researchers mid-triage.

Architecture walkthrough requests: trust@aevrix.group