Security

Security is built into how Brimble runs. This page describes the measures that protect the platform, your workloads, and your data, and the parts of security that are your responsibility.

Shared Responsibility

Brimble secures the platform: the infrastructure, network, orchestration, managed services, and the systems we use to operate them. You are responsible for what you build and configure on it, including your application code and dependencies, environment variables and secrets you add, who has access to your team, database credentials, and whether you enable features such as two-factor authentication, database TLS, backups, and IP allowlists.

Infrastructure

• Brimble runs on dedicated and cloud servers from established hosting providers in secure data centres with physical access controls, redundant power, and environmental safeguards. The providers we rely on are listed on the Sub-processors page.
• Servers communicate with each other over a private, encrypted WireGuard network. Management services are not exposed to the public internet.
• The systems that schedule workloads, discover services, and store secrets (HashiCorp Nomad, Consul, and Vault) require mutual TLS and access tokens for every request.
• Operating system security updates are installed automatically, and platform components are upgraded on a regular schedule.

Network and Edge

• All traffic to Brimble-hosted applications passes through our edge, which terminates TLS using automatically issued and renewed certificates and redirects HTTP to HTTPS.
• Cloudflare protects Brimble's own domains and *.brimble.app addresses against distributed denial-of-service (DDoS) attacks. Custom domains get the same protection when they are proxied through Cloudflare.
• Request rate limiting at the edge protects applications and the platform from abusive traffic.
• Internal platform headers are stripped from incoming requests so clients cannot spoof how a request is routed.

Workload Isolation

• Every application, database, and build runs in its own container with its own resource limits.
• Each customer's workloads run in their own scheduler namespace, on a tenant network kept separate from Brimble's own platform services.
• Workloads that run untrusted code, such as sandboxes, use gVisor, which adds a separate kernel boundary between the workload and the host.
• Builds run in dedicated build environments, separate from running applications.

Service-to-Service Traffic

Traffic between your services on Brimble's private network goes through a service mesh that encrypts it with mutual TLS, so a database connection from your application to your managed database is encrypted even when your application does not use TLS itself.

Secrets and Credentials

• Environment variables, database passwords, and connection strings are stored in HashiCorp Vault, not in Brimble's application database. Vault encrypts everything it stores with AES-256.
• Other credentials Brimble keeps on your behalf, such as server access keys and storage credentials, are encrypted with AES before they are stored, using a key held in Vault.
• Secret values are encrypted in the responses the dashboard receives, and are only revealed when you choose to view them.
• Each managed database gets its own generated credentials, and workloads receive only the secrets for their own project.
• Workbench and dashboard access to databases uses separate, restricted credentials, not your main database user.

Managed Databases

• Databases can be reached privately from your applications over the encrypted service mesh, without being exposed publicly.
• Public access, when enabled, is served over TLS, and you can restrict it to specific IP addresses with an allowlist.
• Supported databases are backed up automatically, with schedules and retention based on your plan. Backups are stored in separate object storage, not on the database's own server, and Brimble's backup storage encrypts them at rest. Backups you send to your own external bucket follow that bucket's settings.

Account Security

• Two-factor authentication with authenticator apps, and passkeys, are available for every account. Sensitive actions can require a fresh two-factor check.
• You can review active sessions and sign out of all sessions at once.
• Teams use role-based permissions, so members only get the access their role needs.
• Account and project activity is recorded in an activity log you can review.
• API keys can be created and revoked from your account settings.

Payments

Card payments are processed by PCI DSS–compliant payment providers. Brimble does not store full card numbers.

Monitoring and Logging

Brimble collects infrastructure metrics, platform logs, and access logs, and alerts its team when workloads, databases, or platform components stop working as expected. Access to production systems is limited to authorised Brimble personnel who need it for their role.

Incident Response

When we detect or are told about a possible security incident, we investigate, contain affected systems, fix the cause, and review what happened to prevent it recurring. If a security incident affects your data, we notify you without undue delay, as described in our Data Processing Agreement.

Data Deletion

When you delete a project, database, or account, the related data is removed from live systems and expires from backups on their retention schedule. Details are in our Data Processing Agreement.

Responsible Disclosure

If you believe you have found a security vulnerability in Brimble, email security@brimble.app with a description, the steps to reproduce it, and its potential impact.

Please give us reasonable time to fix the issue before disclosing it, and do not access or modify other customers' data, degrade the service, or use social engineering or physical attacks. We will acknowledge your report, keep you updated on our progress, and will not take legal action against good-faith research that follows these guidelines.

Contact

Security reports: security@brimble.app. Other questions: legal@brimble.app.