Lo que VULK construye detrás de una app full-stack: base de datos, inicio de sesión y API, comprobados en vivo

Verificado el 10 de octubre de 2026, contra el código que VULK ejecuta hoy y contra endpoints en vivo.

Cuando le pides a VULK una app que tiene que recordar cosas, como una tienda, una herramienta de reservas o un CRM, no se queda en las pantallas. Construye tres cosas detrás de ellas: una base de datos propia del proyecto, un sistema de inicio de sesión para las personas que van a usar la app y una API REST con la que hablan las pantallas. Las tres corren en el backend gestionado de VULK, en api-backend.vulk.dev, y no tienes que montar ningún servidor, ninguna base de datos ni ningún proveedor de autenticación.

Este artículo muestra cada parte tal como funciona de verdad. Cada número de abajo sale de uno de tres sitios: el código que genera y sirve estas apps (leído el 10 de octubre de 2026), el endpoint público de salud del backend y peticiones en vivo contra una tienda que es pública en el showcase de VULK. Nada de esto es un benchmark que hayamos corrido sobre el producto de otro.

El frontend que escribe VULK

Una app web sale como un proyecto React construido con Vite. Las versiones están fijadas en el generador en lugar de dejarse flotar, así que el proyecto que previsualizas es el proyecto que exportas:

Cuando una app necesita datos, VULK añade al proyecto un archivo de cliente tipado. Las pantallas nunca construyen URLs ni tokens a mano: llaman a ese cliente, y el cliente llama al backend.

Una base de datos por proyecto

El backend da a cada proyecto su propia base de datos PostgreSQL, identificada por un id corto: proj_ seguido de los ocho primeros caracteres hexadecimales de la conversación que construyó la app. El id se mantiene igual en cada edición, así que tu app conserva sus datos cuando pides un cambio.

El backend publica un endpoint de salud que cualquiera puede leer. El 10 de octubre de 2026 a las 22:34 UTC respondió:

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

Son 1.440 bases de datos de proyecto aprovisionadas en el motor en ese momento.

Cómo es una tabla generada

VULK decide las tablas a partir de lo que necesita tu app (productos, pedidos, citas) y añade tres columnas propias:

• id, una clave primaria de texto
• created_at, una marca de tiempo que rellena la base de datos
• user_id en las tablas donde cada fila pertenece a una persona con sesión iniciada

Cualquier otra columna toma uno de cinco tipos: texto, número, entero, booleano o fecha y hora. Los nombres de tablas y columnas usan letras minúsculas, dígitos y guiones bajos, empiezan por una letra y no pasan de 48 caracteres. La API responde en camelCase, así que created_at llega a tus pantallas como createdAt.

Los cambios de esquema solo añaden. Cuando una edición necesita una tabla o una columna nueva, el backend la añade. Eliminar una columna o cambiar su tipo nunca se hace automáticamente, porque ese es el cambio que borra datos.

La API REST, ruta por ruta

Cada tabla recibe el mismo conjunto de rutas bajo la dirección del proyecto:

Las listas vuelven en un mismo sobre, { data, meta: { total, page, perPage, totalPages } }. El cliente generado lee 100 filas por página y se detiene en 1.000, y envía las inserciones masivas en bloques de 1.000. Cada proyecto acepta 100 peticiones por minuto de cada dirección de cliente, y el backend lo indica en cada respuesta con una cabecera X-RateLimit-Limit: 100.

Quién puede leer y escribir qué

Esta es la parte que los backends generados fallan más a menudo, así que conviene ser exactos. Una tabla sin una política de acceso declarada está cerrada. VULK primero da a toda la app una de cuatro formas:

• Cuentas privadas: cada persona inicia sesión y solo ve sus propias filas.
• Cuentas de equipo: un equipo trabaja sobre las mismas filas, y la gente entra por invitación.
• Pública: sin cuentas.
• Panel del propietario: visitantes, más un área que solo puede abrir el propietario.

Después configura cada tabla por separado. Una tabla puede leerse públicamente, con la clave de API del proyecto, por un usuario con sesión iniciada o solo por el propietario, y las escrituras tienen las mismas opciones más "cualquiera", para cosas como un formulario de contacto. Las escrituras anónimas tienen un tope de 20 por minuto por dirección. Los campos son privados salvo que el plan de la app diga otra cosa.

Así se ve esa política en una app en vivo. LUMA es una tienda de moda del showcase que corre sobre este backend en proj_266b7c3c. Enviamos estas peticiones sin iniciar sesión, el 10 de octubre de 2026:

El catálogo es público, porque una tienda tiene que mostrar sus productos. Los pedidos necesitan un cliente con sesión iniciada. La tabla de cuentas no se expone como tabla en absoluto.

Inicio de sesión para las personas que usan tu app

Cada app full-stack tiene sus propias cuentas de usuario, separadas de tu cuenta de VULK. El cliente generado cubre el registro, el inicio de sesión, "quién soy" y el restablecimiento de contraseña. El backend tiene además rutas para la renovación, el cierre de sesión y el cambio de contraseña:

• Las contraseñas se guardan con un hash PBKDF2-SHA256, 100.000 iteraciones y una sal aleatoria de 16 bytes.
• La sesión vive en el navegador y se envía como bearer token. Cualquier 401 la borra, así que la app nunca conserva una sesión que el servidor ya ha rechazado.
• Quien es dueño del proyecto es el administrador; todo el que se registra es un usuario normal.
• El registro puede ser abierto, o solo por invitación con códigos que funcionan una vez y caducan a los siete días.

En el estudio, el panel de cada proyecto tiene una pestaña Backend con un resumen, la base de datos, los usuarios de la app, la API y sus secretos.

Claves y secretos

Cada proyecto recibe una clave de API con la forma vk_ seguida de 64 caracteres hexadecimales, guardada cifrada con AES-256-GCM. El bundle publicado no lleva ninguna clave: la dirección del backend se inyecta en la página al cargarla, y al navegador no llega nada que permita a un visitante actuar como el propietario. Los secretos que necesita tu app, como el token de una API de terceros, son de solo escritura. Puedes definir uno o sustituirlo, pero nadie puede volver a leerlo, y cada uno tiene un límite de 8 KB.

Publicar y llevarte el código

Publicar es un clic. VULK construye la versión de producción dentro de la misma máquina aislada que ejecutó tu vista previa y la sirve en <name>.vulk.space por HTTPS. El nombre que eliges sigue siendo tuyo. Si despublicas, el sitio se desconecta y la dirección se reserva para ese proyecto. La dirección del backend queda fijada tanto en la vista previa como en el build publicado, así que la app publicada habla con la misma base de datos que probaste.

El código también es tuyo. Todos los planes de pago pueden descargar el proyecto entero como ZIP o subirlo a un repositorio nuevo de GitHub, privado o público. La exportación a GitHub nunca hace force-push, y admite hasta 1.000 archivos y 8 MB por push.