Cosa costruisce VULK dietro un''app full-stack: database, accesso e API, verificati dal vivo

Verificato il 10 ottobre 2026 sul codice che VULK esegue oggi e su endpoint live.

Quando chiedi a VULK un'app che deve ricordarsi le cose, come un negozio, uno strumento di prenotazione o un CRM, VULK non si ferma alle schermate. Dietro costruisce tre cose: un database tutto per il progetto, un sistema di accesso per le persone che useranno l'app e una REST API con cui le schermate comunicano. Tutte e tre girano sul backend gestito di VULK su api-backend.vulk.dev, e non devi configurare né un server, né un database, né un provider di autenticazione.

Questo articolo mostra ogni parte per come funziona davvero. Ogni numero qui sotto viene da una di tre fonti: il codice che genera e serve queste app (letto il 10 ottobre 2026), l'endpoint pubblico di health del backend e richieste live a un negozio pubblico nella vetrina di VULK. Niente di quello che leggi qui è un benchmark fatto sul prodotto di qualcun altro.

Il frontend che scrive VULK

Un'app web esce come progetto React costruito con Vite. Le versioni sono fissate nel generatore invece di essere lasciate libere di cambiare, così il progetto che vedi in anteprima è lo stesso che esporti:

Quando un'app ha bisogno di dati, VULK aggiunge al progetto un file client tipizzato. Le schermate non costruiscono mai URL o token a mano: chiamano quel client, e il client chiama il backend.

Un database per progetto

Il backend dà a ogni progetto il suo database PostgreSQL, identificato da un id breve: proj_ seguito dai primi otto caratteri esadecimali della conversazione che ha costruito l'app. L'id resta lo stesso a ogni modifica, quindi la tua app conserva i suoi dati quando chiedi un cambiamento.

Il backend pubblica un endpoint di health che chiunque può leggere. Il 10 ottobre 2026 alle 22:34 UTC ha risposto:

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

Significa che in quel momento sul motore c'erano 1.440 database di progetto creati.

Com'è fatta una tabella generata

VULK decide le tabelle in base a ciò che serve alla tua app (prodotti, ordini, appuntamenti) e aggiunge tre colonne sue:

• id, una chiave primaria di tipo testo
• created_at, un timestamp compilato dal database
• user_id nelle tabelle in cui ogni riga appartiene a una sola persona che ha effettuato l'accesso

Ogni altra colonna ha uno di cinque tipi: testo, numero, intero, booleano o data e ora. I nomi di tabelle e colonne usano lettere minuscole, cifre e underscore, iniziano con una lettera e non superano i 48 caratteri. L'API risponde in camelCase, quindi created_at arriva alle tue schermate come createdAt.

Le modifiche allo schema possono solo aggiungere. Quando una modifica richiede una nuova tabella o colonna, il backend la aggiunge. Eliminare una colonna o cambiarne il tipo non avviene mai in automatico, perché è proprio la modifica che cancella i dati.

La REST API, rotta per rotta

Ogni tabella riceve lo stesso insieme di rotte sotto l'indirizzo del progetto:

Gli elenchi tornano in un unico involucro, { data, meta: { total, page, perPage, totalPages } }. Il client generato legge 100 righe per pagina e si ferma a 1.000, e invia gli inserimenti in blocco a gruppi di 1.000. Ogni progetto accetta 100 richieste al minuto da ciascun indirizzo client, e il backend lo dichiara in ogni risposta con un header X-RateLimit-Limit: 100.

Chi può leggere e scrivere cosa

È la parte che i backend generati sbagliano più spesso, quindi vale la pena essere precisi. Una tabella senza una policy di accesso dichiarata è chiusa. Per prima cosa VULK dà all'intera app una di quattro forme:

• Account privati: ogni persona accede e vede solo le proprie righe.
• Account di team: un team lavora sulle stesse righe, e le persone entrano su invito.
• Pubblica: nessun account.
• Pannello del proprietario: visitatori, più un'area che solo il proprietario può aprire.

Poi imposta ogni tabella singolarmente. Una tabella può essere letta pubblicamente, con la chiave API del progetto, da un utente che ha effettuato l'accesso oppure solo dal proprietario, e le scritture hanno le stesse opzioni più "chiunque", per cose come un modulo di contatto. Le scritture anonime sono limitate a 20 al minuto per indirizzo. I campi sono privati, salvo diversa indicazione nel piano dell'app.

Ecco quella policy su un'app live. LUMA è un negozio di moda della vetrina che gira su questo backend con proj_266b7c3c. Abbiamo inviato queste richieste senza accedere, il 10 ottobre 2026:

Il catalogo è pubblico, perché un negozio deve mostrare i suoi prodotti. Gli ordini richiedono un cliente che abbia effettuato l'accesso. La tabella degli account non è esposta affatto come tabella.

L'accesso per le persone che usano la tua app

Ogni app full-stack ha i propri account utente, separati dal tuo account VULK. Il client generato copre registrazione, accesso, "chi sono" e reimpostazione della password. Il backend ha anche le route per il rinnovo della sessione, l'uscita e il cambio password:

• Le password sono salvate come hash con PBKDF2-SHA256, 100.000 iterazioni e un salt casuale di 16 byte.
• La sessione vive nel browser e viene inviata come bearer token. Qualsiasi 401 la cancella, così l'app non tiene mai una sessione che il server ha già rifiutato.
• La persona proprietaria del progetto è l'amministratore; chiunque si registri è un utente normale.
• La registrazione può essere aperta, oppure solo su invito, con codici che funzionano una sola volta e scadono dopo sette giorni.

Nello studio, la dashboard di ogni progetto ha una scheda Backend con una panoramica, il database, gli utenti dell'app, l'API e i suoi segreti.

Chiavi e segreti

Ogni progetto riceve una chiave API nella forma vk_ seguita da 64 caratteri esadecimali, salvata cifrata con AES-256-GCM. Il bundle pubblicato non contiene alcuna chiave: l'indirizzo del backend viene iniettato nella pagina al caricamento, e al browser non arriva nulla che permetta a un visitatore di agire come il proprietario. I segreti di cui la tua app ha bisogno, come il token API di un servizio esterno, sono di sola scrittura. Puoi impostarne uno o sostituirlo, ma nessuno può rileggerlo, e ciascuno è limitato a 8 KB.

Pubblicare e portarti via il codice

Per pubblicare basta un clic. VULK costruisce la versione di produzione dentro la stessa macchina isolata che ha eseguito la tua anteprima, poi la serve su <name>.vulk.space in HTTPS. Il nome che scegli resta tuo. Se annulli la pubblicazione, il sito va offline e l'indirizzo resta riservato a quel progetto. L'indirizzo del backend è legato sia all'anteprima sia alla build pubblicata, quindi l'app pubblicata parla con lo stesso database che hai provato.

Anche il codice è tuo. Con ogni piano a pagamento puoi scaricare l'intero progetto come ZIP o inviarlo a un nuovo repository GitHub, privato o pubblico. L'esportazione su GitHub non fa mai force push e accetta fino a 1.000 file e 8 MB per push.