Skip to content
ConsystenceConsystence Docs

Cloud (Azure)

The cloud-hosted Consystence service is a managed, multi-tenant platform on Microsoft Azure. Customers do not operate any of this infrastructure — Consystence platform operators run it — but a security or architecture reviewer usually wants its shape. This page describes that shape at the level a customer needs: how tenants are isolated, how a tenant is reached, and where its data lives. For the on-prem alternative see On-prem / site server.

The managed cloud, as a cell

Section titled “The managed cloud, as a cell”

The cloud runtime is organised into cells. A cell is a self-contained unit — its own Orleans cluster, its own PostgreSQL 16 database, and its own historian — bound to the tenant organisations it hosts. The platform scales by adding cells rather than growing a single cluster, and a tenant organisation never spans more than one cell.

A cloud cell runs as a multi-silo Orleans cluster on managed Kubernetes: several server replicas form one clustered runtime with shared grain state, so the cell keeps serving through the loss of an individual replica. The cell host is internal plumbing and is never surfaced to customers — a tenant is only ever reached at its own subdomain.

Reaching a tenant

Section titled “Reaching a tenant”

Each tenant organisation is reached at its own subdomain, {slug}.consystence.com. Cloudflare fronts the public domains: it routes each tenant subdomain to the owning cell’s ingress and terminates TLS at the edge. The cell maps the request subdomain to an organisation and resolves the tenant from that trusted host mapping together with the authenticated identity. A site is a path under the org subdomain (/sites/{code}), never its own domain — see the org & site model and Authentication.

Data and residency

Section titled “Data and residency”

PostgreSQL 16 is the cell’s system of record: relational application data (auth, org, membership, audit, command-audit) plus Orleans grain state and reminders. The historian is kept in its own database so the platform’s only unbounded-growth store can scale independently. A cell is region-pinned, so a tenant’s data stays in its declared region — the basis of the platform’s data-residency commitment for regulated customers. Higher commercial tiers carry a stronger durability posture (zone-redundant high availability and geo-redundant backup).

Secrets

Section titled “Secrets”

A cell holds its own credentials, never as plaintext in the deployment. Database connection strings, the API-key pepper, and telemetry credentials are bootstrap secrets, supplied as platform secrets (Kubernetes Secrets); the cell’s other credentials — identity-provider client secrets, notification-service keys, and AI-provider keys — live in an encrypted, per-cell configuration store. Sync keys and API keys are never stored retrievably: the cell keeps only peppered hashes.

Section titled “Related”