Plattform für interne Tools Offene Beta

Interne Tools liefern
mit Produktions-Governance.

Deterministische, versionierte Releases mit org-spezifischer Zugriffskontrolle, audit-gestützten Operationen und DEV/TEST/PROD-Promotion-Pfaden deployen.

Jetzt starten So funktioniert es
StockLevels.tsx
AlertService.ts
relpin.config.ts
1import { useQuery } from '@app-builder-platform/data'
2import { Badge, TableView } from '@app-builder-platform/ui'
3
4export function StockLevels() {
5 const { data, isLive } = useQuery(
6 'inventory.stock_levels',
7 { where: { quantity: { lt: 100 } } }
8 )
9
10 return (
11 <TableView
12 rows={data}
13 pinned={isLive}
14 columns={[
15 { key: 'sku', header: 'SKU' },
16 { key: 'name', header: 'Product' },
17 { key: 'qty', header: 'Qty' },
18 { key: 'status', render: (r) => (
19 <Badge variant={r.qty < 20
20 ? 'critical' : 'warning'}>
21 {r.status}
22 </Badge>
23 )},
Der Wandel

Jetzt baut jeder Apps.
Niemand kontrolliert sie.

KI-Tools und Low-Code-Plattformen haben jedes Team zu App-Entwicklern gemacht. Das Risiko ist nicht das Bauen selbst, sondern Produktionsdatenzugriff ohne klare Release-, Audit- und Zugriffskontrollgrenzen.

42%
der Enterprise-Apps sind Schatten-IT
Productiv, 2023
75%
der Wissensarbeiter nutzen KI bei der Arbeit
Microsoft Work Trend Index, 2024
78%
bringen eigene KI-Tools zur Arbeit mit
Microsoft Work Trend Index, 2024
275
SaaS-Apps pro Unternehmen im Durchschnitt
Zylo SaaS Management Index, 2025
Builder-Tools
  • – UI aus einem Prompt generieren
  • – An eine öffentliche URL deployen
  • – Einzelnutzer-Bearbeitung
  • – Keine Umgebungstrennung
  • – Kein Audit Trail
Was Governance erfordert
  • RBAC pro Umgebung und Ressource
  • Unveränderliche, versionierte Releases
  • Vollständiges Mutations-Audit-Logging
  • Serverseitige Secrets mit beschränktem Zugriff
  • Promotion-Gates: DEV → TEST → PROD
Governance-Posture · Auditierbarkeit · Zugriffsgrenzen
Das Problem

Interne Tools fallen aus.
Jedes. Einzelne. Mal.

bash — ~/ops
$
FRI 16:42 DEPLOYsarah.ops pushed query update to production
FRI 16:43 WARNINGResponse time degraded to 8.2s on /api/metrics
FRI 16:51 ERROROOM killed — dashboard loading 847,291 rows client-side
FRI 17:02 OUTAGECEO dashboard down — 23 active users affected
SAT 09:15 ESCALATECTO requests rollback — no release history exists
SAT 09:47 BREACHRaw PII exposed via unscoped API response
MON 08:30 AUDITCompliance: who approved this change? No trail found.
MON 11:00 LEGALAudit response required — review window started FRI 16:51
$ ▌

Eine ungeprüfte Änderung kann zum Ausfall, Datenqualitätsproblem oder Audit-Gap werden.

Kontrollierte Releases

Gepinnt. Promoted. Auditiert.

Jede Veröffentlichung ist content-addressiert: Das Bundle wird kanonisiert und mit SHA-256 gehasht, dann an exakte Schema-Versionen gepinnt. Promotion bringt dasselbe Artefakt durch Umgebungen hinter Approval-Gates, und jedes governed Deployment sowie jede Lifecycle-Änderung wird aufgezeichnet.

01
Content-addressierte Releases

Jedes Publish wird kanonisiert, mit SHA-256 gehasht und an exakte Schema-Versionen gepinnt — der getestete Build ist Byte für Byte das, was ausgeliefert wird.

02
Approval-Gates

TEST erfordert eine Freigabe, PROD zwei mit Funktionstrennung — Freigaben sind an den exakten Artefakt-Hash gebunden, sodass erneutes Planen sie ungültig macht.

03
Promotion-Gates

DEV → TEST → PROD klont dasselbe Artefakt und schlägt bei Schema-Drift fehl, beim Apply erneut verifiziert als Tenant-Audit-Einträge.

Releases
Release History
v2.1.0DEPLOYED
Schema migration #47
Mar 12 · 14:32 · 14 tables · 0 pending
v2.1.1PINNED
Hotfix: filter reset
Mar 14 · 09:15 · 14 tables · 0 pending
v2.2.0STAGING
New bulk actions
Mar 18 · 11:03 · 15 tables · 1 pending
Content-addressierte Releases gepinnt an exakte Schema-Versionen
Approval-Gates: TEST braucht eine, PROD zwei mit Funktionstrennung
Promotion klont dasselbe Artefakt und schlägt bei Schema-Drift fehl
Release- und Deployment-Aktivität als Tenant-Audit-Events
Content-addressierte Artefakte · Schema-Versions-Pinning · Approval-gesteuerte Promotion
Governance

Privat per Default.
Keine öffentlichen App-Ausreißer.

Jede deployte App bleibt hinter Relpin Authn/Authz. Account, Organisation, App und Umgebung werden geprüft, bevor die App-Runtime Traffic erhält.

01
Private Routen

Deployte Apps bleiben hinter Relpin-Authn — keine App-URL ist ohne authentifizierte Session erreichbar.

02
Org-Mitgliedschaft

Organisations-Checks laufen an der Routengrenze, bevor die App-Runtime einen einzigen Request sieht.

03
Serverseitige Secrets

Connector-Credentials und Secrets bleiben serverseitig — nie durch den Browser proxied.

Governance
Roles
4
Users
17
Policies
12
Violations
0
Role-Based Access Control
RoleDeploySecretsAuditUsers
Admin✓✓✓1
Developer✓—✓4
Viewer——✓12
Relpin-Account vor Zugriff auf deployte Apps erforderlich
Organisationsmitgliedschaft wird an der Routengrenze geprüft
Fähigkeitsbasierte Zugriffskontrolle pro App und Umgebung
Secrets und Connector-Credentials bleiben serverseitig
Private Routen per Default · Org-Mitgliedschaft geprüft · Secrets serverseitig · Fail-closed-Pfade
Datenarchitektur

Ihre Datenbank. Ihre Regeln.
Ihre Geschwindigkeit.

Relpin baut auf einer DB-per-Org-Datenebene auf. Tenant-Abfragen laufen serverseitig mit SQL-Pushdown, während Connector-Arbeit governed und serverseitig bleibt.

01
Serverseitiges SQL

Filter, Sort und Pagination kompilieren zu Postgres. Publish schlägt fehl, wenn die Query im Browser ausgewertet würde.

02
DB-per-Org

Jede Organisation erhält ein dediziertes Postgres mit umgebungs-scoped Schemas und Ownership.

03
Governed Connectors

Externe Connector-Calls laufen serverseitig, capability-gated und auditiert über denselben Trail.

Data Architecture
Query Time
47ms
Rows Scanned
100,000
Returned
25
Cache Hit
94%
Query Execution Pipeline
PARSE2ms
SELECT * FROM orders WHERE status = 'active'
FILTER8ms
B-tree index scan on status
SORT12ms
ORDER BY created_at DESC
PAGINATE3ms
LIMIT 25 OFFSET 0
RETURN22ms
25 rows serialized → JSON
Total execution47ms
SQL-Level-Filterung — Sortierung und Paginierung direkt in Postgres
DB-per-Org-Baseline mit Umgebungsschemas und Enterprise-Pfad zu DB-per-Env
Tenant-DB-Zugriff bleibt serverseitig und env-basiert
Connector-Ausführung ist serverseitig, capability-gated und auditiert
Serverseitige Abfragen · Mandanten-isoliert · Env-basierter DB-Zugriff · Governed Connectors
Die Plattform

Coden. Liefern. Kontrollieren.

Code-first-Entwicklung mit deterministischen Releases und kontrollierter Ausführung. Echtes TypeScript schreiben, jedes Artefakt an einen Schema-Snapshot pinnen und Ihrem Team eine vertrauenswürdige Steuerungsebene geben.

Platform
OrderTable.tsx
export function OrderTable({ data }) {
const filtered = data.filter(
row => row.status === "active"
)
return <Table rows={filtered} />
}
Echte TypeScript-Komponenten — keine Canvas-Widgets oder Config-Dateien
Code-first-Entwicklung mit governed SDK — Abfragen laufen serverseitig
Jedes Release content-addressiert und an exakte Schema-Versionen gepinnt
Gates bei der Veröffentlichung — keine stille clientseitige Auswertung
Code-first · Deterministische Deploys · Kontrollierte Ausführung · Serverseitige Abfragen
Jetzt starten

Schluss mit Tools,
die Sie nicht betreiben können.

Die Geschwindigkeit von Low-Code. Die Governance eines Plattform-Teams. Schnell bauen, sicher deployen, im großen Maßstab betreiben.

Jetzt starten Plattform erkunden

Offene Beta · Demo-Workspace enthalten · Governance-fokussiert

Gepinnte Releases. Kontrollierte Ausführung. Gebaut für den Betrieb.