Network
Security
Security and reliability designed into operations
Bahriya is built with strong operational controls, controlled access patterns, and practical reliability practices for customer workloads. Security is not a feature you enable — it is how the platform works.
Defence in depth
Five layers of platform security
From network edge to supply chain — every layer is designed with security as a default, not an opt-in.
Network
DDoS protection and edge security
Every container deployed on Bahriya is protected at the network edge from the moment it goes live. No configuration, no add-ons — protection is built into the platform.
Automatic DDoS mitigation applied at the edge for all workloads
IP whitelisting and blacklisting per container
Per-container rate limiting to control traffic bursts
TLS certificates issued and renewed automatically via Let's Encrypt
GeoDNS routing with health checks — unhealthy regions are removed from rotation
Access control
Authentication and authorisation boundaries
Bahriya enforces strict separation between user and admin access models. Each operates in its own Keycloak realm with independent token validation — no shared session state, no privilege escalation paths.
Separate Keycloak realms for end-user and admin APIs
Role-based access control: owner, admin, member, viewer
Project-level role overrides for fine-grained permissions
Personal access tokens for API and CLI authentication
Admin APIs enforce stricter rate limits and WAF protections
Secrets management
Encrypted secrets and private registries
Secrets are encrypted at rest with AES-256 and injected into containers at deploy time. Private container registries are scoped to projects — no image leaking between teams.
AES-256 encryption at rest for all secret values
Secrets scoped to projects — never shared across organisational boundaries
Private registry credentials stored as encrypted secrets
Secret values are write-only in the API — once set, they cannot be read back
Secrets injected into containers at deploy time — no secrets in images or environment dumps
Observability
Activity traceability and audit
Every infrastructure-affecting action is recorded in the activity log. Deployments, configuration changes, role assignments, secret rotations — all timestamped and attributed to a user.
Full activity log across containers, secrets, registries, projects, and users
Every entry attributed to the acting user with timestamps
Activity visible in the console, queryable via the API
Role-based visibility — support teams see logs without accessing secret values
Designed for compliance workflows and incident investigation
Supply chain
Vendor supply chain ethics
Every vendor in the Bahriya infrastructure stack is vetted. We do not use Israeli vendors or companies that support Israeli operations — across DNS, CDN, storage, tooling, and payment processing. This is a platform-wide commitment, not an afterthought.
Every vendor audited against a published ethical supply chain policy
Applies to all layers: DNS, CDN, compute, storage, CI/CD, and payments
UAE-based company, globally operated — accountable to customers, not investors
Vendor policy published and maintained as the platform grows
Infrastructure spend reaches none of the companies on the exclusion list
Secure by default
Every deploy is protected from the start
Secrets are encrypted before they leave your terminal. TLS, DDoS protection, and health checks are applied automatically on every deployment — no YAML to write, no boxes to tick.
reis deploy
$ reis secrets create --project payments --name stripe-key
Secret encrypted (AES-256) and stored.
Scoped to project: payments
$ reis containers deploy --project payments --secret stripe-key
Injecting secrets into container...
TLS certificate issued (Let's Encrypt).
DDoS protection active.
Rate limiting enabled (default policy).
Health checks configured.
Deployed to helsinki-1 with all protections active.
Review your trust requirements with our team
We can walk through controls, current posture, and planned enhancements for your compliance roadmap.