Was VULK hinter einer Full-Stack-App baut: Datenbank, Anmeldung und API, live geprüft

Geprüft am 10. Oktober 2026, am Code, den VULK heute ausführt, und an Live-Endpunkten.

Wenn du VULK um eine App bittest, die sich Dinge merken muss, etwa einen Shop, ein Buchungstool oder ein CRM, bleibt es nicht bei den Screens. Dahinter baut VULK drei Dinge: eine eigene Datenbank für das Projekt, ein Anmeldesystem für die Menschen, die die App nutzen werden, und eine REST-API, mit der die Screens sprechen. Alle drei laufen auf dem verwalteten Backend von VULK unter api-backend.vulk.dev, und du richtest weder einen Server noch eine Datenbank noch einen Auth-Anbieter ein.

Dieser Beitrag zeigt jeden Teil so, wie er tatsächlich funktioniert. Jede Zahl unten stammt aus einer von drei Quellen: dem Code, der diese Apps generiert und ausliefert (gelesen am 10. Oktober 2026), dem öffentlichen Health-Endpunkt des Backends und Live-Anfragen an einen Shop, der öffentlich im VULK-Showcase steht. Nichts davon ist ein Benchmark, den wir am Produkt eines anderen gefahren haben.

Das Frontend, das VULK schreibt

Eine Web-App entsteht als React-Projekt, gebaut mit Vite. Die Versionen sind im Generator festgelegt, statt frei mitzuwandern, damit das Projekt in der Vorschau genau das Projekt ist, das du exportierst:

Braucht eine App Daten, fügt VULK dem Projekt eine typisierte Client-Datei hinzu. Die Screens bauen nie selbst URLs oder Tokens zusammen; sie rufen diesen Client auf, und der Client ruft das Backend auf.

Eine Datenbank pro Projekt

Das Backend gibt jedem Projekt eine eigene PostgreSQL-Datenbank, erkennbar an einer kurzen ID: proj_, gefolgt von den ersten acht Hexadezimalzeichen der Unterhaltung, in der die App entstanden ist. Die ID bleibt bei jeder Änderung gleich, deshalb behält deine App ihre Daten, wenn du eine Änderung anforderst.

Das Backend veröffentlicht einen Health-Endpunkt, den jeder lesen kann. Am 10. Oktober 2026 um 22:34 UTC antwortete er:

{
  "status": "ok",
  "service": "vulk-api-engine",
  "database": "connected",
  "projects": 1440
}

Das sind 1.440 bereitgestellte Projektdatenbanken auf der Engine zu diesem Zeitpunkt.

Wie eine generierte Tabelle aussieht

VULK legt die Tabellen danach fest, was deine App braucht (Produkte, Bestellungen, Termine), und fügt drei eigene Spalten hinzu:

• id, ein Text-Primärschlüssel
• created_at, ein Zeitstempel, den die Datenbank ausfüllt
• user_id in Tabellen, in denen jede Zeile einer angemeldeten Person gehört

Jede andere Spalte hat einen von fünf Typen: text, number, integer, boolean oder datetime. Tabellen- und Spaltennamen bestehen aus Kleinbuchstaben, Ziffern und Unterstrichen, beginnen mit einem Buchstaben und sind höchstens 48 Zeichen lang. Die API antwortet in camelCase, created_at kommt in deinen Screens also als createdAt an.

Schemaänderungen fügen immer nur hinzu. Braucht eine Änderung eine neue Tabelle oder Spalte, legt das Backend sie an. Eine Spalte zu löschen oder ihren Typ zu ändern, passiert nie automatisch, denn genau diese Änderung löscht Daten.

Die REST-API, Route für Route

Jede Tabelle bekommt dieselben Routen unter der Adresse des Projekts:

Listen kommen in einer einheitlichen Hülle zurück, { data, meta: { total, page, perPage, totalPages } }. Der generierte Client liest 100 Zeilen pro Seite und hört bei 1.000 auf, und Massen-Inserts schickt er in Paketen zu je 1.000. Jedes Projekt nimmt 100 Anfragen pro Minute von jeder Client-Adresse an, und das Backend sagt das in jeder Antwort mit einem X-RateLimit-Limit: 100-Header.

Wer was lesen und schreiben darf

Das ist der Teil, den generierte Backends am häufigsten falsch machen, deshalb lohnt es sich, genau zu sein. Eine Tabelle ohne festgelegte Zugriffsregel ist gesperrt. Zuerst gibt VULK der ganzen App eine von vier Formen:

• Private Konten: Jede Person meldet sich an und sieht nur ihre eigenen Zeilen.
• Team-Konten: Ein Team arbeitet mit denselben Zeilen, und neue Leute kommen per Einladung dazu.
• Öffentlich: überhaupt keine Konten.
• Inhaber-Panel: Besucher, dazu ein Bereich, den nur der Inhaber öffnen kann.

Danach stellt VULK jede Tabelle einzeln ein. Eine Tabelle kann öffentlich lesbar sein, mit dem API-Schlüssel des Projekts, für angemeldete Nutzer oder nur für den Inhaber. Für Schreibzugriffe gibt es dieselben Optionen und zusätzlich „jeder“, etwa für ein Kontaktformular. Anonyme Schreibzugriffe sind auf 20 pro Minute und Adresse begrenzt. Felder sind privat, solange der Plan der App nichts anderes vorsieht.

So sieht diese Regel in einer Live-App aus. LUMA ist ein Mode-Shop im Showcase, der auf diesem Backend unter proj_266b7c3c läuft. Diese Anfragen haben wir am 10. Oktober 2026 ohne Anmeldung gesendet:

Der Katalog ist öffentlich, weil ein Shop seine Produkte zeigen muss. Bestellungen brauchen einen angemeldeten Kunden. Die Kontentabelle ist gar nicht erst als Tabelle erreichbar.

Anmeldung für die Menschen, die deine App nutzen

Jede Full-Stack-App bekommt eigene Benutzerkonten, getrennt von deinem VULK-Konto. Der generierte Client deckt Registrierung, Anmeldung, „Wer bin ich“ und Passwort-Reset ab. Das Backend hat außerdem Routen für Refresh, Abmeldung und Passwortänderung:

• Passwörter werden mit PBKDF2-SHA256 gehasht, mit 100.000 Iterationen und einem zufälligen 16-Byte-Salt.
• Die Sitzung liegt im Browser und wird als Bearer-Token gesendet. Jede 401 löscht sie, damit die App nie eine Sitzung behält, die der Server schon abgelehnt hat.
• Die Person, der das Projekt gehört, ist Admin; alle, die sich registrieren, sind normale Nutzer.
• Die Registrierung kann offen sein oder nur auf Einladung laufen, mit Codes, die einmal gelten und nach sieben Tagen ablaufen.

Im Studio hat das Dashboard jedes Projekts einen Backend-Tab mit Übersicht, Datenbank, den Nutzern der App, der API und ihren Secrets.

Schlüssel und Secrets

Jedes Projekt bekommt einen API-Schlüssel der Form vk_, gefolgt von 64 Hexadezimalzeichen, verschlüsselt gespeichert mit AES-256-GCM. Das veröffentlichte Bundle enthält keinen Schlüssel: Die Adresse des Backends wird beim Laden in die Seite eingesetzt, und nichts, womit ein Besucher als Inhaber auftreten könnte, wird an den Browser ausgeliefert. Secrets, die deine App braucht, etwa ein API-Token eines Drittanbieters, sind nur beschreibbar. Du kannst eines setzen oder ersetzen, aber niemand kann es wieder auslesen, und jedes ist auf 8 KB begrenzt.

Veröffentlichen und den Code mitnehmen

Veröffentlichen ist ein Klick. VULK baut die Produktionsversion in derselben isolierten Maschine, in der deine Vorschau lief, und liefert sie dann unter <name>.vulk.space über HTTPS aus. Der Name, den du wählst, bleibt deiner. Nimmst du die Veröffentlichung zurück, geht die Seite offline, und die Adresse bleibt für dieses Projekt reserviert. Die Backend-Adresse ist sowohl in die Vorschau als auch in den veröffentlichten Build eingebunden, deshalb spricht die veröffentlichte App mit derselben Datenbank, die du getestet hast.

Auch der Code gehört dir. In jedem bezahlten Plan kannst du das ganze Projekt als ZIP herunterladen oder in ein neues GitHub-Repository pushen, privat oder öffentlich. Der GitHub-Export macht nie einen Force-Push und nimmt bis zu 1.000 Dateien und 8 MB pro Push.