Security & Privacy
Aria is built with privacy at its core. Understanding what data goes where helps you make informed decisions about your team's communication security.
Our Privacy Promise
Aria's central services never see your messages, files, or voice/video content. All communication content stays exclusively on your self-hosted server. We only handle user authentication and server discovery — the minimum needed to let users log in and find servers.
What Aria's Central Services See
What We Can See
- User email & username — For authentication only (email encrypted at rest)
- Server public metadata — Name, description, member count (what you choose to make public)
- Server health status — Online/offline, version, last heartbeat
- Server membership lists — Which users are members of which servers (for discovery)
What We Cannot See
- Message content — All messages stay on your server, never routed through us
- Files & attachments — Stored on your server or your S3 bucket
- Voice & video streams — WebRTC media goes directly between users and your server
- Channel structure & permissions — Your server organization is private to you
- Roles & member permissions — Access control stays on your server
How Data Flows
When a user sends a message, it goes directly from their client to your self-hosted server. Aria's central services are only involved during login and server discovery — never for actual communication.
Encryption Standards
| Data Type | At Rest | In Transit |
|---|---|---|
| User Passwords | Argon2id (64MB memory, 3 iterations) | N/A (never transmitted) |
| User Emails | AES-256-GCM | TLS 1.3 |
| API Keys | SHA-256 (hash only) | TLS 1.3 |
| Messages (E2EE) | MLS Protocol (client-side) | TLS 1.3 |
| Files & Attachments | AES-256 (S3 SSE) | TLS 1.3 |
| Voice & Video | Not stored | DTLS-SRTP |
Server Authentication
1. API Key Authentication
When you provision a server, you receive a unique API key. This key is used to authenticate your server with Aria's central services. The key is scoped to your specific server ID and owner account — it cannot be used to access other servers.
aria_sk_live_qK5x2Y8mN9pL3rT7wV1zA4bC6dE0fG2hJ4kM5nP82. Ed25519 Cryptographic Identity
Each server generates a unique Ed25519 keypair on first startup. The public key is registered with Aria's auth service, and the private key never leaves your server. Sensitive operations require cryptographic proof that your server possesses the private key.
3. Request Signing
All requests from your server to central services are signed with your Ed25519 private key. This prevents request tampering and replay attacks. Each signature includes a timestamp with a 5-minute validity window.
Security Features
Rate Limiting
IP-based, user-based, and server-based rate limiting to prevent abuse and DoS attacks.
Token Blacklisting
Logout from all devices instantly. Revoked tokens are propagated to all servers via pub/sub.
Key Rotation
Rotate API keys and Ed25519 keypairs without downtime. 24-hour grace period for seamless transitions.
Audit Logging
Comprehensive logging of authentication, authorization, and administrative actions for compliance.
Container Security
Our Docker images follow security best practices:
- Non-root execution — Containers run as unprivileged user (UID 1000)
- Dropped capabilities — All Linux capabilities dropped (CAP_DROP: ALL)
- No privilege escalation — no-new-privileges security option enabled
- Read-only filesystem — Root filesystem mounted read-only where possible
- Resource limits — CPU and memory constraints to prevent resource exhaustion
- Vulnerability scanning — Images scanned for CVEs before release