Ottili Cloud

Cloud security model

How tenant isolation, Ottili identity, encryption and audit protect Ottili Cloud resources — with live, early-access and planned controls clearly separated.

Overview

Ottili Cloud security is built on the same foundations as the rest of Ottili ONE: company-scoped tenant isolation, a single Ottili identity, transport encryption and audited access. There is no separate cloud password or standalone cloud credential to leak — you sign in with the same company context as Ottili Coder and Ottili ONE.

This page describes the security model behind Ottili Cloud resources and clearly separates what is live today, what runs under Early Access, and what is planned as the cloud categories (compute, storage, networking) mature. It does not claim certifications or controls that Ottili has not yet earned or shipped.

Shared platform foundation

Ottili Cloud runs on the Ottili-owned control plane and inherits the platform-wide security controls that protect all Ottili ONE services:

Tenant isolation*: every cloud resource belongs to a company. Resources in one company cannot read or affect another company's resources — enforced by the company-scoped company_id boundary.
One identity*: authentication is handled by Ottili Auth, shared across Ottili Cloud, Ottili Coder and Ottili ONE. Access tokens are signed JWTs (HS256) and verified on every authenticated request; refresh tokens rotate on a time-based policy and reuse is detected and rejected.
Password protection*: user passwords are hashed with Argon2id; Ottili ONE never stores plaintext passwords.
Transport encryption*: service-to-service traffic verifies TLS/SSL certificates, and the public edge is served over TLS by the platform gateway.

Access control

Who can create, view or delete cloud resources follows the Ottili ONE platform role model, scoped to the cloud project:

Actions are governed by platform roles and entitlements, not by separate cloud credentials.
Programmatic access goes through the Unified API and the cloud APIs, authenticated with the same Ottili identity — there are no long-lived cloud access keys independent of the platform.
Meaningful actions on cloud resources are recorded in the platform audit log so activity is reviewable.

Encryption

Encryption in Ottili Cloud builds on the platform foundation:

In transit*: traffic to and within the platform is encrypted with TLS. The shared HTTP client verifies TLS certificates for service-to-service calls.
At rest (platform)*: backups can be encrypted at rest with AES-256-GCM when backup encryption is enabled and a passphrase is configured. This is an opt-in capability, not a universal guarantee — when not configured, backups are written unencrypted.
At rest (cloud data)*: encryption at rest for cloud volumes, block storage and databases is delivered as the storage and compute categories mature. It is planned today and is not yet orderable as a standalone control.

Cloud-specific controls

Additional cloud hardening is delivered together with the categories it depends on:

Network firewalls / security groups*: part of the cloud networking category, which is in Early Access / planned — not yet a self-service control.
Key management / customer-managed keys*: planned; not yet available.
Private networking / VPC-style isolation*: planned as networking matures.

These controls are documented here only once they are real, and are never presented as available before they ship.

Compliance and certifications

Ottili does not claim certifications it has not earned:

GDPR*: Ottili ONE is built for GDPR — data-subject rights, lawful bases, retention limits and sub-processor transparency are implemented and referenced throughout the privacy surface. (Referenced, not a held certificate.)
SOC 2 Type II*: on the compliance roadmap; no attestation completed yet.
ISO/IEC 27001*: alignment planned; Ottili is not yet certified.
ISO/IEC 27017*: not currently pursued; not claimed.

Availability

The isolation and identity model applies to Ottili Cloud today because it is shared platform infrastructure. Feature-level security controls tied to not-yet-live categories are marked planned, not presented as shipped. We do not publish internal service paths, secrets or private API routes in public docs.

Your [account](/docs/cloud-accounts) is the access boundary.
Programmatic access goes through the [cloud APIs](/docs/cloud-apis).
Understand how [networking](/docs/cloud-networking) isolates resources.
Attach [storage](/docs/cloud-storage) as it becomes available.
Place workloads with [compute](/docs/cloud-compute).
See how [budgets](/docs/budget-caps) cap spend.
Terminate traffic with [domains and TLS](/docs/domains-and-tls).

Was this article helpful?