How CelinQ actually secures a deployment

Deployment topology

CelinQ Server runs entirely on infrastructure your organisation controls — on-premises or in your own cloud account. There is no CelinQ-operated service in the path of ordinary collaboration: the server your architects' local clients synchronise with is the one you deployed, and nothing about core sync or Fusion merging depends on an external CelinQ service being reachable.

Authentication

Two mechanisms, active side by side, for different purposes. Personal access tokens — PBKDF2-SHA256 hashed, shown once at issue, never stored or logged in plaintext — are meant for API access and service automation. Microsoft Entra ID SSO (standard OIDC, Authorization Code + PKCE) is available for human sign-in, with Entra roles or groups mapping, promote-only and licence-capped, onto CelinQ's own Viewer / Editor / Administrator / Owner roles. A non-Entra generic OIDC provider — Keycloak, Okta — is not yet implemented.

Transport encryption

All traffic between CelinQ Connect (the local companion service) and the CelinQ Server runs over TLS. Certificate pinning is available and opt-in on the client side — a SHA-256 fingerprint match configured on the client, an extra check against a specific certificate rather than trusting the certificate chain alone. It is client-side pinning only; there is no server-side pinning of client certificates in the current implementation.

Secrets storage

API keys and other server-side secrets — an AI provider's API key, for example — are never stored in plaintext. On Windows, the server uses DPAPI at machine scope. On other platforms, it uses AES-GCM with a 32-byte key injected via the CELINQ_SECRET_KEY environment variable. If neither mechanism is available, CelinQ refuses to persist the secret in plaintext rather than falling back to an insecure default.

Backup

SQLite deployments have a real, tested online backup path — triggered through the Control Plane or the admin API, verified in CelinQ's own test suite. PostgreSQL deployments do not yet have an automated online backup built in; the server returns an explicit error with guidance to use pg_dump or your database's own WAL archiving instead, rather than silently doing nothing.

Authorization

Workspace roles — Viewer, Editor, Administrator, Owner — are enforced server-side on every call, not just checked once at login. A revoked or downgraded role takes effect on the next request, not the next sign-in.

API surface

gRPC for sync traffic; a versioned REST API (/api/v1) for the Control Plane and admin operations. CelinQ has no built-in API gateway, rate limiting, or WAF — the documented guidance is to deploy it behind your own reverse proxy or API gateway when it is exposed beyond a trusted network.

Read next