Cloudflare incident
If Cloudflare degrades, our static surfaces fail open to direct-from-origin via emergency DNS. Origin is rate-limited at the host layer regardless.
Secure architecture
The surface, seen from above.
A safe-to-discuss view of how Aevrix services fit together: the layers, the trust boundaries, the failure modes we've designed around. The deeper internals live under signed NDA on request.
Layer 1 — Edge
Public traffic stops at the perimeter.
- Cloudflare sits in front of every Aevrix-owned hostname. Static assets are served from Cloudflare Pages; dynamic traffic is reverse-proxied through Cloudflare WAF + DDoS to our origin.
- HSTS preload, HSTS max-age two years, plus HTTP/3 where the client supports it.
- WAF rules are tuned per surface — anonymous read endpoints get tighter rate-limits than authenticated write endpoints.
- Pages-only surfaces (this site, aevrix.dev, aevrix.group) have no origin server — there is no application to attack behind them.
Layer 2 — Application
Stateless, replaceable, observable.
- Application servers are container-based, stateless where possible, and deployed in pairs across availability zones at our hosting provider.
- Service-to-service traffic stays on a private mesh (Tailscale / WireGuard). No internal service is reachable from the public internet.
- Configuration is pulled from HashiCorp Vault at boot. No secrets in container images, no secrets in CI logs.
- Health checks are external (UptimeRobot) and internal (Grafana Alloy). Rollouts are gated on health-check passing in the canary pair before fleet-wide.
Layer 3 — Data
Encrypted at rest, encrypted end-to-end where it matters.
- Production data lives in volume-encrypted (LUKS) PostgreSQL instances. Logical backups are taken nightly with pg_dumpall plus volume snapshots; physical backups via Restic to Backblaze B2.
- End-to-end encrypted surfaces (Axion messaging) never let our infrastructure see plaintext: keys are derived client-side under MLS / Signal protocol, and Aevrix only stores ciphertext and metadata.
- Backups are encrypted client-side; the cloud backup target only sees opaque blobs.
- Retention windows are documented in /privacy/ per data class.
Layer 4 — Identity
Phishing-resistant by default.
- Corporate identity: SSO with hardware FIDO2 second factor. SMS-based 2FA is disabled across the organisation.
- Customer identity: depends on surface — see the specific product's privacy and security pages.
- Recovery chains for admin accounts are separated from primary inboxes; compromising one mailbox does not let an attacker pivot.
Failure modes
What we've designed around.
Single host loss
Stateless application tier scales horizontally; data tier replicates across availability zones with PITR.
Region loss
Cold restore tested quarterly from Backblaze B2 encrypted snapshots. Documented RTO four hours, RPO one hour for data surfaces.
Supply-chain compromise
Container base images pinned by digest; release artefacts cosigned; cargo-deny / OSV-Scanner gate CI; weekly dependency audit on a separate schedule.
Insider misuse
Production access is per-role, time-bounded, four-eyes for destructive operations on shared data. All shell access auditd-logged.
Account compromise of a founder
Founder accounts use FIDO2 and have no standing production permissions. Break-glass is paper, hardware-backed, and never single-person.
What's not here
Reasonable opacity.
We deliberately do not publish: exact IP ranges of origin hosts, version pins of every dependency, internal service hostnames, monitoring rule sets, or the precise sequence of incident-response runbooks. Specifics are available under signed NDA to active enterprise customers and to security researchers in the middle of an active triage.
Need to go deeper?
Architecture walkthrough under signed NDA. Open to enterprise customers and to programme researchers mid-triage.