Security & Trust

Security is
architecture, not a badge.

Relpin enforces isolation, identity, and least privilege at the platform level — fail-closed by default. We are in open beta and hold no certifications yet. What we have today is the architecture below.

Relpin Security Posture
Fail-closed
01 Tenant isolation

DB-per-org Postgres; per-app isolated Workers

02 Verified identity

Spoofable headers stripped; identity injected server-side

03 Least privilege

Runtime and DDL roles separated; scoped grants

04 Append-only audit

Row-level history enforced at DB-privilege level

Open beta · No certifications yet · Architecture-level guarantees
Tenant Isolation

Every org runs in its
own blast radius.

Isolation is structural, not a filter on a shared table. Each organization gets a dedicated Postgres database, per-workspace and per-environment schemas, and its own isolated runtime — separated by least-privilege roles at every layer.

01
DB-per-org Postgres

Each organization gets a dedicated Postgres database. There is no shared multi-tenant table to leak across.

02
Per-app isolated runtime

Apps deploy as isolated per-tenant Cloudflare Workers on Workers for Platforms — one app cannot reach another.

03
Least-privilege roles

Runtime roles and DDL roles are separated. Tenant code never runs with schema-altering privileges.

Each org runs on a dedicated Postgres database, not a shared table
Schemas are scoped per workspace and per environment
Apps deploy as isolated per-tenant Workers behind a fail-closed dispatch router
The dispatch router strips client-supplied identity headers and injects verified identity
DB-per-org · Per-workspace+env schemas · Isolated Workers · Fail-closed dispatch
Two Trust Domains

Operators cannot sign
into your apps.

Product surfaces and the operator console run on separate authentication domains. Operator access is recomputed against an allowlist on every request, so revocation takes effect immediately — and operator credentials can never authenticate into a customer app.

Product domain

Customer apps and Studio surfaces. Verified org members only.

Operator domain

Operator console. Allowlist recomputed per request; revocation is immediate.

01
Separate auth domains

The product and the operator console are distinct trust boundaries with distinct credentials.

02
Per-request allowlist

Operator authorization is recomputed on every request. Revoking access is immediate, not eventual.

03
No cross-domain login

Operator credentials cannot authenticate into customer apps — the two domains never trust each other.

Product surfaces and the operator console use separate authentication domains
Operator access is recomputed against an allowlist per request
Revoking operator access takes effect immediately
Operator credentials can never authenticate into a customer app
Separate auth domains · Per-request allowlist · Immediate revocation
Secrets & Credentials

Credentials stay
platform-side.

User code references secrets; it never receives their values. Database credentials and provider secrets stay server-side and never reach the browser, user code, or logs. Container preview gets credentials through an isolating sidecar, and every access is audited.

01
Server-side references only

Apps hold secret references, not secret values. The plaintext never leaves the platform boundary.

02
Never in browser, code, or logs

Credentials are not exposed to the browser, injected into user code, or written to logs.

03
Sidecar-isolated preview

Container-backed live preview receives credentials through a credential-isolating sidecar proxy.

Apps reference secrets server-side; values never reach the browser or user code
Credentials are never written to logs
Live preview gets credentials through an isolating sidecar, not the user runtime
Secret access is audited
i Relpin stores server-side secret references. A managed vault and auto-rotation are not part of the product today.
Server-side references · No browser exposure · Sidecar isolation · Access audited
Access Control

Every scoped request
is checked server-side.

Permission keys are evaluated on the server before an action runs — the browser never holds the decision. Custom roles use pattern grants, per-app runtime policies decide who can reach each app, and managed accounts are bound to claimed email domains.

01
Permission keys, server-side

Every scoped request resolves a permission key on the platform before the action executes.

02
Custom roles, pattern grants

Org-defined roles grant access by global, exact-key, or prefix-wildcard patterns.

03
Per-app access policies

Runtime access scopes to role, named users, workspace, or editors-only — enforced at the edge.

Permission keys are checked server-side on every scoped request
Custom roles grant access with global, exact-key, and prefix-wildcard patterns
Per-app runtime policies scope access to role, named users, workspace, or editors-only
Managed accounts are provisioned through claimed email domains
Server-side keys · Pattern grants · Per-app policies · Claimed domains
Audit & Operations

Append-only history,
enforced by the database.

Every user table captures field-level before/after diffs with the acting identity on insert, update, and delete. The audit table is append-only — enforced by database privileges, not application convention. Operational guardrails fail closed by default.

01
DB-enforced append-only

Tenant roles get SELECT and INSERT on the audit table only. History cannot be edited or deleted.

02
Row-level field diffs

Triggers capture before/after values and the actor on every insert, update, and delete.

03
Fail-closed guardrails

Statement and lock timeouts, pagination caps, per-org concurrency limits, and fail-closed quotas are defaults.

The audit table is append-only, enforced at the DB-privilege level
Row-level history records field diffs and the acting identity
Every tenant transaction carries statement and lock timeouts and pagination caps
Promotion requires approvals: TEST needs 1, PROD needs 2, with separation of duties
Append-only audit · Row-level diffs · Fail-closed guardrails · Promotion approvals
Compliance, Plainly

What we have, and
what we do not.

Honesty is part of the posture. We will not claim certifications we do not hold or controls we have not built.

Available today
DB-per-org Postgres isolation with least-privilege roles
Verified identity injection and fail-closed dispatch
Server-side secret references with sidecar-isolated preview
Append-only, DB-enforced audit with row-level field diffs
Server-side RBAC with custom roles and per-app policies
Gated DEV→TEST→PROD promotion with separation-of-duties approvals
Planned
+ SOC 2, ISO 27001, and HIPAA certifications
+ Compliance reporting
+ Realtime audit streaming and SIEM integration
+ Managed secrets vault and auto-rotation

Relpin holds no SOC 2, ISO 27001, or HIPAA certifications today. Compliance reporting is planned. What exists today is the architecture above.

Available now · Planned · No certifications claimed
Security & Trust

Architecture you can
inspect before you trust.

Relpin gives engineering and platform teams isolation, verified identity, and least privilege as platform defaults — not as a checklist bolted on later.

Tenant isolation · Verified identity · Least privilege · Append-only audit

Open-beta product. Architecture-level guarantees. No certifications claimed.