Security at Koolbase

Koolbase runs on a small, tightly controlled infrastructure footprint:

• Compute and database run on a dedicated virtual private server (Ubuntu 24.04 LTS), under supervised processes with automatic restart. The primary datastore is PostgreSQL.
• Object storage and CDN are provided by a major edge and object-storage provider, using bucket-scoped, least-privilege storage. Our subprocessors are listed below.
• Edge protection — all inbound traffic passes through a global edge network with full (strict) TLS to the origin, HSTS enforced, and a host firewall restricting origin access.

Data residency. Primary compute and database are hosted in the European Union (Paris, France); object storage and CDN use a global edge network. We can confirm the specific region and discuss data-residency requirements for Enterprise customers on request.

In transit. All communication between the SDKs, API, dashboard, and our servers is encrypted with TLS 1.2 or higher. HTTPS is enforced with HSTS, and the connection from the edge to our origin uses full (strict) TLS with verified origin certificates.

At rest. Sensitive data — including secrets and API keys — is encrypted at rest using AES-256. Object storage is encrypted at rest by the storage provider, and database backups are additionally encrypted with GPG before they leave the host.

• Passwords are hashed with bcrypt. Plaintext passwords are never stored or logged.
• Sessions use short-lived JWT access tokens with refresh-token rotation, limiting the window of any leaked token.
• API keys are scoped (read/write) and organization-bound. Cross-organization access is denied without revealing whether a resource exists, so keys cannot probe other tenants' data.
• Tenant isolation is enforced per project and per organization on every request — one project cannot read or write another's data.

Administrative access. Koolbase is operated by a small, controlled team. Access to production systems and customer data is restricted to authorized personnel and used only to operate, support, and secure the service — not for routine access to customer content.

Application secrets and credentials — database URLs, storage tokens, signing keys, third-party API keys — are managed in a centralized secrets store and injected at runtime. Credentials are never committed to source control and are not exposed in application code.

• PostgreSQL is backed up on an automated schedule.
• Backups are GPG-encrypted before leaving the host and stored off-site, separate from primary compute.
• Backup jobs are monitored — if a scheduled backup does not complete, we are alerted.
• Backups are restore-tested to verify they can actually be recovered, not just written.

The result is off-site, encrypted, monitored, and verified backups as the foundation of our recovery process.

• Continuous uptime monitoring runs against our public endpoints.
• A public status page is available at status.koolbase.com, showing current status and incident history.
• Application errors are captured for rapid diagnosis.

Enterprise customers can receive a contractual Service Level Agreement (SLA) with a defined uptime target and service-credit remedies — contact sales.

• All traffic is fronted by a global edge network with full (strict) TLS and HSTS.
• The origin host runs a firewall restricting access to expected sources.
• Object-storage tokens are bucket-scoped and least-privilege.
• Dependencies are reviewed and kept current as part of ongoing maintenance.

We use a small set of trusted subprocessors to operate Koolbase. Those that may process customer data are listed below. The full list, with legal entities and locations, is at koolbase.com/subprocessors.

• Our Privacy Policy, Terms of Service, and Cookie Policy are published at koolbase.com.
• We handle personal data in line with GDPR principles.
• A Data Processing Agreement (DPA) is available — [email protected].
• Customers can request export or deletion of their data.

If we become aware of a security incident affecting customer data, we will:

1. Investigate and contain the incident.
2. Assess the scope and what data was affected.
3. Notify affected customers without undue delay, with the information they need to meet their own obligations.
4. Remediate and apply corrective measures to prevent recurrence.

Specific notification timelines can be committed to contractually for Enterprise customers.

We welcome responsible disclosure. If you believe you've found a security issue, email [email protected] with enough detail to reproduce it. Please give us a reasonable opportunity to remediate before public disclosure. We won't pursue legal action against good-faith research conducted under these terms.

We'd rather state our posture plainly than imply certifications we don't hold:

• SOC 2 Type II — on our roadmap. We're building toward the controls and will pursue formal audit as demand justifies it. In the meantime, this page and a completed security questionnaire are available to support your review.
• GDPR — we align our data handling with GDPR and offer a DPA.
• Self-hosting — teams with strict requirements can run Koolbase on their own infrastructure, keeping data entirely within their control.
• Dedicated infrastructure — a dedicated database and isolated infrastructure are available on our Enterprise plan for single-tenant deployment.