Security architecture
A high-level view of how NEXORA is built and hosted today. It describes what is actually in place, including the gaps, and omits details that would help an attacker.
Request path and components
Browser / API client → TLS reverse proxy → application container → Postgres · Redis · Clerk · Stripe
Edge
A Caddy reverse proxy terminates TLS (Let's Encrypt certificates, HTTP redirected to HTTPS) and routes each hostname to its app.
Applications
Website, Account, Console, API, Docs, Status, Developers, Sentinel, CSPM and Gateway run as separate containers, each built from the same monorepo and shared Core packages.
Identity
Sign-in, sessions and organisations are handled by Clerk. NEXORA stores no passwords. Machine access uses per-organisation API keys, stored only as hashes.
Data
PostgreSQL holds subscriptions, API key hashes and audit events. Redis holds rate-limit counters only, never customer data.
Payments
Stripe-hosted checkout. Card data never reaches NEXORA; billing webhooks are accepted only after signature verification.
Observability
Sentry for application errors, Prometheus and Grafana for host, Postgres and Redis metrics, with alerting on database/cache outages, memory and disk.
Controls
- Tenant isolation
- Every organisation-scoped query filters by organisation inside the query itself, and an automated cross-organisation check verifies one organisation's events, keys and subscriptions never appear in another's.
- API authentication
- API keys are generated once, shown once and stored as one-way hashes. Revoking a key takes effect immediately. Requests are rate limited per key using shared Redis counters, so limits hold across replicas.
- Secrets
- Production secrets live in environment files on the server, outside the repository. Secret scanning and push protection are enabled on the code repository.
- Code and dependency scanning
- CodeQL analysis and Dependabot run on the repository; every change builds and type-checks in CI before it can merge.
- Audit trail
- API key changes, product usage and admin product-access changes are recorded with actor, organisation, outcome and timestamp, and shown to the organisation in Console.
- Backups
- Database backed up nightly (kept 14 days) and the whole server weekly (kept 27 days), within the same Oracle Cloud region.
Not yet in place
- No independent penetration test or third-party security audit yet.
- No SOC 2, ISO 27001 or other formal certification.
- Single-region, single-server hosting: no automatic failover, and backups are not replicated to a second region.
- No public-facing SLA while products are in beta.
See the Security Statement for the vulnerability-reporting policy, or the live status page.