Security
This article describes how Bahriya protects your applications and data.
Authentication
Bahriya uses a dedicated identity provider for authentication. When you sign in to the console, you authenticate through a secure login flow that supports:
- Email and password.
- Social login providers (where configured).
- Multi-factor authentication (where configured).
For programmatic access (CLI, CI/CD, scripts), you use Personal Access Tokens (PATs). Tokens are generated in the console and can be set to expire after a number of days or never.
Encryption
Secrets
Secrets (environment variables containing sensitive values like database passwords and API keys) are encrypted with AES-256 before being stored. They remain encrypted at rest in the database and in the deployment pipeline. Decryption only happens at the moment the secret is injected into your container at runtime. See Secret Encryption for a detailed breakdown of the encryption lifecycle.
TLS
All traffic to your containers is encrypted with TLS. Bahriya automatically provisions and renews certificates for:
- Default hostnames (
<handle>.<region>.x.on.bahriya.app).
- Vanity hostnames.
- Custom domains (once DNS is configured).
You do not need to manage certificates yourself.
Data in transit
All communication between the Bahriya API, deployment pipeline, and your container infrastructure is encrypted in transit.
Network isolation
Each project runs in its own isolated network space. Containers in one project cannot communicate with containers in another project, even within the same organisation. This prevents accidental or malicious cross-project access.
Within a project, containers can communicate with each other and with Memcached instances over the internal network.
Access control
Bahriya uses role-based access control (RBAC) at the organisation level. Every member has a role — Owner, Admin, Member, or Viewer — that determines what they can do. See Organisations for details on roles and permissions.
IP-based access control
You can restrict access to individual containers using IP allow lists (only specified IPs can connect) or IP deny lists (specified IPs are blocked). See Rate Limiting and IP Rules for details.
Rate limiting
Per-container rate limiting protects your application from abuse by limiting how many requests a single client IP can make per minute or per hour.
HTTP basic authentication
You can require username/password authentication on the ingress of an HTTP container — useful for staging environments, internal tools, and dashboards without their own auth. Up to 10 credentials are supported per container; passwords are AES-256 encrypted at rest and never retrievable after save. See Basic Authentication for details.
Infrastructure
Bahriya runs on dedicated infrastructure across multiple global regions. The platform is designed so that:
- Your containers run on isolated compute resources.
- Container images are pulled from your registry over encrypted connections.
- Deployment pipelines are isolated per project.
- No shared state exists between different customers' workloads.
Responsible disclosure
If you discover a security issue, please contact security@bahriya.cloud. We take all reports seriously and will respond promptly.
