Governance & Access

Private by default.
Verified every time.

Relpin keeps deployed apps reachable only by verified members of your organization. Every request clears session, organization, app, and environment checks before the app runtime sees it.

Start building See How It Works
Relpin Auth Flow
Verifying
Access checks pre-dispatch
01
Session User is signed in to Relpin
02
Organization Membership verified
03
App permission Role grants access to this app
04
Environment Scope: DEV / TEST / PROD
Private by Default

No deployed app becomes a public URL by accident.

Relpin treats deployed app routes as governed entrypoints. Dispatch routing sits behind Relpin authorization, strips spoofable identity headers, and fails closed when user or organization context is missing.

01
No public-by-default

Deployed app routes require an authenticated Relpin session before traffic reaches the app.

02
Verified identity

Apps receive platform-verified user and org context — never browser-supplied headers.

03
Fail-closed dispatch

Missing or invalid authorization blocks the route instead of falling through to the app.

Private by Default
Without Relpin access
× No useful app response
× No trusted org context
× No browser-supplied identity accepted
× No public fallback path
With Relpin access
✓ Relpin account verified
✓ Organization membership confirmed
✓ Environment and app access scoped
✓ Request forwarded with verified context
Deployed apps require an authenticated Relpin session
Organization membership is checked before app traffic is served
Generated apps receive verified platform context, not browser-supplied identity
Missing or invalid authorization blocks the route instead of falling through
Authenticated session · Organization membership · Verified app context · Fail-closed dispatch
RBAC & Permission Keys

Capability-based access,
resolved server-side.

Roles map to convention-based permission keys, not ad-hoc checks scattered through app code. Relpin resolves capabilities on the server before an action runs, so the same access model governs every tool you ship.

01
Convention-based keys

Permissions follow a predictable resource.action shape, so access intent is readable instead of guessed.

02
Roles, not one-offs

Capabilities attach to roles. Granting and revoking happens in one place, not per app.

03
Server-side resolution

Access is evaluated on the platform before the action executes — the browser never holds the decision.

Role × Capability server-side
capability
Admin
Editor
Viewer
deploy
×
×
secrets
×
×
data.write
×
data.read
Permission keys follow a convention instead of bespoke per-app logic
Capabilities are granted through roles, not copied into each tool
Access decisions resolve server-side before an action runs
The same access model applies across every governed app
Convention-based keys · Role-scoped capabilities · Server-side decisions
Authorization Boundary

Access checks live before the app runtime.

Generated apps should not be responsible for proving who the user is. Relpin checks the route first, then forwards only verified identity and organization context into the app runtime.

01
Dispatch is the boundary

A Relpin-controlled route is the public entrypoint, not a standalone app surface.

02
Checked before code runs

Session, membership, environment, and app context are evaluated before generated code executes.

03
Scoped context only

The runtime receives verified identity and org context — not secrets or raw account tokens.

Request lifecycle
1 Request

User opens app route

The browser reaches a Relpin-controlled app route, not a standalone public app surface.

2 Verify

Relpin checks access

Session, organization membership, environment, and app route context are evaluated before dispatch.

3 Forward

Verified context only

The generated app receives trusted identity and org context after the platform has accepted the request.

Credentials stay platform-side. The app runtime gets scoped context through the sidecar proxy — never raw tokens.
Dispatch is the public entrypoint for deployed apps
Authn/authz is enforced before generated app code executes
App runtime receives scoped context instead of secrets or raw account tokens
Denied requests stay outside the generated app surface
Route auth first · App runtime second · Scoped context only
Environments & Promotion

Promote releases through
DEV, TEST, and PROD.

Every environment is an isolated scope with its own tables, data, and access. Apps deploy and run in DEV and TEST, not only PROD, and releases promote forward as pinned bundles. Promotion is gated: TEST requires one approval, PROD requires two with separation of duties.

01
Isolated environments

DEV, TEST, and PROD each get their own tables and data. Nothing bleeds across a scope.

02
Deployed in every environment

Apps deploy and run in DEV and TEST, not only PROD — preview real behavior before promoting.

03
Approval-gated promotion

TEST requires one approval, PROD requires two with separation of duties. The requester cannot self-approve, and approvals bind to the exact artifact hash.

Promotion path
DEV

Deploy, run, and preview with isolated data

TEST

Validate against representative data

PROD

Serve verified members only

pinned · deterministic · isolated
Gates
Environment isolation
Active
Per-environment access
Active
Pinned release promotion
Active
Approval gates · separation of duties
Active
DEV, TEST, and PROD are isolated scopes, each with its own tables and data
Apps deploy and run in every environment, not only production
Access to each environment is controlled by membership and role; orgs can define custom roles with pattern-based permission grants
Promotion is approval-gated: one approval for TEST, two for PROD, bound to the exact artifact hash
Isolated environments · Approval-gated promotion · Separation of duties · Hash-bound approvals
Use Cases

Internal software that stays internal.

Governance applies the same way across the tools teams actually ship — wherever access, environment, and identity have to be provable.

REGULATED

Compliance-bound tools

Internal tools handling regulated data stay behind verified org membership and scoped access.

EXTERNAL

Contractor & partner access

Grant scoped, role-based access to outside collaborators without exposing a public surface.

ADMIN

Customer-data consoles

Admin tools that read and write production data run behind capability checks, not shared logins.

OPS

Approval & triage queues

Ops and finance workflows scope who can act, with environment-aware access on every step.

STAGING

Environment-scoped previews

DEV and TEST builds stay reachable only to the members assigned to that environment.

AUDITED

Privileged admin actions

Sensitive actions sit behind role-based capabilities so the right people hold the right keys.

Regulated · External access · Admin consoles · Environment-scoped
Governed Apps

Build internal software
that stays internal.

Relpin gives teams the speed of code-first app creation while keeping deployed apps behind account, organization, and environment boundaries.

Start building Explore the platform

Private by default · Org-scoped access · Dispatch authorization

Account required. Organization checked. App access scoped.